FireWire hard drives

[Paul Higgins]

Hi again, Derick: 

Thanks for all your good advice.  (Comments in line):

On Sunday 24 December 2006 02:40, Derick Centeno wrote:
> > my niece is getting my G3 iBook to
> > replace her cheapo eMachines PC that my brother bought her about a
> > year ago, which just blew up. Yes, I'm putting YDL on it.  : )
>
> Great!

Yeah, and a brief, unsolicited word of advice: avoid those eMachines like the 
plague.  They're just terrible computers, and basically can't be fixed once 
they blow up--and they do blow up, almost literally.  The entire motherboard 
on my niece's is fried. 

> Paul, I've been creating partitions and formats on all kinds of
> hard-drives destroying, resurrecting and recovering data of all kinds
> of complexity since the 70's.  Please believe me, if your system is
> guessing and running through a laundry list of conflicting messages as
> you've described something is not well.

Well, "you're the man" when it comes to Unix/Linux, that's for sure, so I 
won't second-guess you except to say that I followed the directions I was 
given religiously.  Here's the link again: 

http://www.idevelopment.info/data/Unix/Linux/LINUX_InstallingIEEE1394FireWireHardDriveLinux.shtml

(See below FFI).

> The way it (Linux) should work, is one clear output displaying exactly
> what you have once and only once.  No "figuring" or maybe this or that.

My experience with Debian (x86) and YDL has been that many USB/FW peripherals 
cause problems.  I've watched what happens using "tail -f /var/log/messages" 
as well as "dmesg | grep -i [sda*, scsi, etc.]" and in most cases there isn't 
one clear output, unfortunately.  This is with several brands of flash drives 
and now with my FW drive, too.

That link I gave lists several modules that are supposed to be loaded for 
things to work properly (ohci1394, ieee1394, sbp2) and they're all there 
according to lsmod.  It's a pretty good article in that it's quite 
thorough--good for really dense newbies like me.

> * the hard-drive may not be recording bits of data properly.
> * the Linux OS may not understand what the hard-drive is actually
> reporting to it because the hard-drive hardware settings are not
> standard or the firmware controlling the hard-drive is not talking
> Linux in a standard manner.

I think it's the latter case.  This is a new Maxtor HD in a new case (made by 
Bytecc).  I have another FW kit identical to this one that I built recently 
for OS X, so I know that I put this one together right.  Maybe there's an 
hardware problem, but I doubt it's my fault.  The only hardware setting for 
the FW box is on the HD: you need to jumper it correctly.  However, the box 
came with no instructions for connecting the drive--just lots of instructions 
for installing the (Windoze) drivers!  Anyway, the last FW box I got (same 
model) said to jumper the drive as master.  The drive came from Maxtor 
jumpered for cable select, but I changed it to master.  These boxes are 
really simple, though--you either get it right or they don't work at all.

I've checked to make sure the files actually exist on the external HD, and so 
far they appear OK.  I'm going to use md5sum to make sure they're not getting 
corrupted in some subtle way.  But I transferred over a big picture file and 
a couple GB of audio stuff with no apparent problems.  Maybe the FW enclosure 
needs new firmware?  (I haven't checked yet).  How much do you want to bet 
that if there's a firmware update from Bytecc, it'll only be for MacOS or 
Windoze?  Meaning I'll probably have to wipe the drive again (I doubt OS X 
can read ext3). 

> force all the data on that drive to be zeroed or destroyed and
> rebuild the data on that drive exclusively from within Linux using
> fdisk and then mkfs.  

The directions at the link are in fact to fdisk the HD and then to use mkfs to 
make a proper ext3 FS.  Did so on my iBook G4, YDL 4.1.

> Check all
> hardware settings within the firewire enclosure and on the hard-drive
> itself.  Make sure that there are no punctures or scratches that look
> like they don't belong there.  There are many legitimate vendors, but
> many more illegitimate ones unfortunately.

Been there, done that.  These boxes are really simple: FW-to-ATA bridge board, 
power supply, and aluminum enclosure.  They all look the same to me 
regardless of manufacturer.  The HD was bought at CompUSA a couple months 
ago; I just opened it yesterday.  Nothing appears defective on either the FW 
box or HD; fdisk and mkfs reported all blocks OK.

> A large drive gotten at a "steal" of a price may be just too good to be
> true.  The advantage to paying attention to all these nitty-gritty
> details is that as you're experience grows you'll be less likely to
> miss visible hints of something awry with the hardware and you'll get
> more skilled in understanding what fdisc and parted and other similar
> tools are telling you about these devices.

Yes, I'm certainly learning a lot more than I did with OS X, despite that also 
being "a Unix OS".  I'm pretty confident that the FW box and HD are OK.  I 
bought them from *supposedly* reputable vendors (CompUSA and a local 
"whitebox" store catering to Linux people).

> Another annoying but still possible scenario is that it is still
> possible to have unwrapped a completely new drive from a vendor who
> received it pristinely wrapped from a manufacturer and it is still a
> lemon, or non-working drive.

I hope not...had good luck so far with Maxtor.

> A drive which "mostly" works is really of no use to anyone.  I'm
> assuming that you are rewarding, and not punishing, your niece in a
> creative Addams Family manner. 

Well, my Windoze-addled brother would say that I'm punishing her in the 
old-style Addams Family manner by giving her an iBook running Linux!  But 
anyway, she's not getting the FW drive; that's just for me to get all the 
files off the machine so I can wipe it and install YDL 4.1 for her.

> The wonderful and powerful side of Linux is exactly what you are
> mastering.  If this era were the 50's or 60's we'd be discussing
> modifying our cars, instead.  No one would have thought it odd to have
> detailed knowledge of axles, spark plugs, etc.  It was a fellow's job
> to know what was going on with whatever one owned, and to know enough
> how to use or repair it or what needed to get repaired.  Linux, is more
> complex, granted, but the onus remains on the individual.

Yes, I totally agree.  People need to spend about a month really learning how 
to use something as complex as a computer and OS.  I for one am interested in 
Linux multimedia.  PPC Linux really ought to be *the* Linux/Unix platform for 
content creation, especially since so much creative work is done on Apple 
machines. 

> Suggestion:  Keep a notebook and record there exactly each step you do,
> why and how.  Always cross-check against it, until you can do them
> while you dream.  Get away from being "sure" about anything -- KNOW.

Well, I work in a biology lab (U of M), so some might say I do record-keeping 
to a fault!  Anytime I see a new command I need to know, I print it out ("man 
-t [command] | lp".  My Debian notebook is several hundred pages now, with an 
A-Z tab index.  Anyway, I printed out the article before I started, and 
cross-checked the output from fdisk and mkfs with the print version--they 
were exactly the same.

> If after all that, the drive is not reliable -- it just may be that
> drive.  One test which will isolate the difficulty further is to apply
> the exact same above steps to a different drive placed into the same
> "cheesy" enclosure, and see if Linux reports the drive's existence in
> the same confusing way.  If Linux reports the drive's existence without
> any of the "funny stuff" or "guesses"; the problem is unique to that
> drive.

See above; USB/FW peripherals seem to always be cursed, at least on my systems 
(Debian x86 3.1r4 and YDL 4.1).  Using tail and dmesg | grep commands always 
shows the system thrashing for a while.  But I've never had a problem moving 
files from Debian/YDL to OS X (flash drive formatted as vfat32).  So things 
"work", but in a non-ideal manner.

> The difference is that the modification necessary within YDL 4.0 fstab
> file is not necessary within YDL 4.1.  Why?  Improvements to the Linux
> kernel are such that the Linux OS can make more assessments

But--the article at the link says "YDL 4.0", not 4.1:
http://www.terrasoftsolutions.com/support/solutions/ydl_general/firewire.shtml

Apparently by adding /mnt/firewire and then "mount /dev/sda1 /mnt/firewire" 
you don't need to add anything to /etc/fstab in YDL 4.0 *or* 4.1.  Whereas it 
looks as though by adding an entry to fstab you mostly save yourself some 
typing ("mount /dev/sda1").  Do I understand this correctly? 

> > It would be nice if Linux could get plug-n-play working a bit more
> > reliably when it comes to FireWire and Flash drives.

> As our individual sophistication grows, our projects and interests, as
> well as what Linux can accomplish also grows.  However, like all such
> human endeavors successful and complete coverage will be spotty. 

OK, but it's hard not to get laughed at when I tell people that you often have 
to mount a flash drive in a terminal.  It's not any real trouble to do so, 
but it's seen as really old-school.  GUI automounting is pretty much expected 
out of a modern OS.

> It is very difficult to design an open source gui which addresses
> everyone's needs which is why the really powerful opportunity of open
> source in my view is the potential to contribute to these various
> desktop projects by letting them know what's important to you.

Again, my Windoze-using colleagues in the lab are laughing at me...why can't 
you set up a GUI to do easy drag 'n drop of files for backup?  I'm not 
CLI-phobic, but drag 'n drop to external storage is also expected of a modern 
OS.  I'd much rather be able to back things up in a brain-dead manner (GUI) 
than have to think about it (CLI).  Especially at the end of the day when I 
have to hurry to the bus stop.

Thanks again for your help!

-PRH