technical question about harddisks

My problems with HDs have been worn out spindle bearings and head crashes. The worn out bearings most of the time. After about 4 or 5 years of use. Head crash twice in 30 years.When the drive spins up the heads bounce off the surface when first loaded. The loading is done in a non data area.

Bob Bob

On a sunny day (Fri, 19 Jun 2009 08:34:06 -0700) it happened wrote in :

Thank you BOB, well I think 4 to 5 years is a reasonable time, by that time time for a new bigger disk, those will likely become available then. 'bouncing the heads' against anything sounds bad to me. So I will leave it on...

I'll have a word with our Seagate reps about this, the next time they ask me to qualify a drive (the product I work on is Linux-based).

Yeah, the Seagate USB drives have some known behaviors which cause problems with/for the Linux USB kernel stack. If I recall correctly, the FreeAgent drives not only spin down, but also drop their USB 2.0 high-speed connection when they do so. This *may* be a technical violation of USB specs - I'm not sure. In any case, when the user (or kernel) accesses the drive again, the drives and Linux don't manage to re-enable a USB 2.0 connection, and the drives are accessed at the older USB 1.1 speed. This may not be fast enough for proper media access.

I *think* there may have been a Linux kernel patch issued to work around this quirk in the Seagate drives.

From talking this issue over with various drive-vendor reps over the past year or so, I've concluded that... well, it depends. There are a bunch of different factors.

Modern hard drives generally use fluid-dynamic (or even magnetic- dynamic?) bearings. There should be no metal-to-metal contact at all while the platter is spinning... and hence little wear in the spindle bearing assembly. However, when the drive is spun down, a spindle-to-bearing contact can occur... and this generates a small amount of metal wear (and, potentially, metal contamination of the lubricant). For this reason, spinning these drives up and down a

Also, when one of these drives spins down, the "flying head" ceases to fly, and (in most drives) actually lands on the surface of the platter (there's often a reserved "landing zone" used for this). This also causes some amount of wear / stiction. Some of the newer 3.5" drives (and many smaller drives such as 2.5" ones used in laptops) have a "head lifter" mechanism, which actually retracts the heads away from the platter at power-down time... these don't have the landing-zone wear problem.

As you say, thermal cycling can also be an issue... especially if your environment gets down to near-freezing!

One compromise (for the spindle-wear and landing-zone issues at least) is to set a relatively high spin-down time - say, 30 minutes or so. Since you're using Linux, you might want to manage this disk with the automounter, mounting its filesystem only when accessed, and dismounting it after an amount of inactivity that's close to but less than the spin-down time (say, 20 minutes). With this combination of settings, the drive will keep spinning for as long as you're actually using it, and for a reasonable period thereafter... but will be dismounted and then spin down once you "take your hands off" for a while. For a home media storage medium this might be an effective combination.

(ATM at least).

like to know.

temperature

From my experience keeping hard drives working is a matter of proper cooling and no fibration. I have hard drives that have been powered on every day for years and I have hard drives that have been on 24/7 for over 10 years straight.

On a sunny day (Fri, 19 Jun 2009 11:23:35 -0700) it happened snipped-for-privacy@radagast.org (Dave Platt) wrote in :

What happened is that if I configure it to spin down (I have to do that in xp, as there is no Linux utility for that), then when it is accessed again, the kernel reports an I/O error, and then it remounts read-only. Somebody gave me a fix for that that may be useful to you: echo 1 > /sys/class/scsi_disk/0:0:0:0/allow_restart

Well, I think I will pass on that one, and keep it on 24/7.

AS there is no Linux utility to control spin down time, I did a USB data dump in MS xp, and found what commands are send to the drive to control the spin down time and the LED on front... Maybe one day I could write a Linux utility for that, using libusb. For now I have set it to 'spin down never' using the xp utility that came with it.

I want to thank you for some good technical info, it would have made sense if Seagate had given it to me, but I am glad I have it now :-)

Regards Jan

The Linux "sdparm" utility can manipulate a lot of the mode page information on many drives... I saw mention of it when I googled for "Linux FreeAgent" this morning.

Quite welcome!

It is not an HD question. It is an electrical question.

Since most failures occur at power up or power down transient events, leaving nearly any electrical/electronic device on 100% duty would yield the longest life average. Some devices do not apply of course, like a light bulb or other device that has a limited hours of operation lifespan.

The Seagate USB drives typically have a sleep utility built into the SATA to USB circuit inside the drive base. That has a default sleep time and you can set it... in Windows. It keeps the setting, however, and will sleep just fine, even under Linux, and uses standard SMART monitoring and wake calls, etc.

So you do not have to do anything other than determine what it is currently set to, and getting a Windows box up with the utility installed, so you can set/control what the timeout period is.

I hate the damned "feature". The drives only use a couple of Watts, and if you are not actually planning on accessing the drive remotely, you can simply unplug it between usage session. Problem solved.

The other wat is to have bought a drive enclosure/interface, which typically have a power switch. Most also give a choice of interface options.

I just simply bought a "kingwin" EZ-Connect multi interface, which does standard form factor SATA, the old IDE and UDMA IDE, and the mini-laptop IDE connector. It has an inline PS for it, and the device itself is only about one IDE connector long by about 1.25" wide, not including the wires, of course.So I can hot swap nearly any drive, at any time. I wish they had a remote ISA interface slot, so I could hook up my really old drives. That would be cool.

I would like to see what I was up to back then, compared to now.

Question: Do these also run old 5-1/4 floppy drives? That would allow me to scrap the old NT 'puter.

Hard drives cannot fib. They can only give out what data they have. No fibbing allowed. :-)

No. Not to my knowledge.The floppy interface is a different animal. The chip was a multi chip, IIRC that had a few items in it for PCs in the early days. Pretty sure there are USB floppy drives out there though. Even 2.88MB drives, which are far more reliable

(ATM at least).

like to know.

temperature

• That noise is the arm holding the heads moving to the park position to keep both the HD and the heads safe (more resistant to shocks). Better worry if you do *not* hear it when powering down...

happening to the USB too:

ehci_hcd and address 6

ehci_hcd and address 6

ehci_hcd and address 6

that disk...

disk...

hdparm -S [timeout] [device]

See hdparm man page for details of timeout values.

Sorry, I was wrong. Just tried it:

-S isn't supported for SCSI disks, and there appears to be no analogous command in sdparm. At least I can't find it.

On a sunny day (Fri, 19 Jun 2009 15:26:04 -0700) it happened snipped-for-privacy@radagast.org (Dave Platt) wrote in :

Hey, that works, spin down: grml: ~ # sdparm --command=stop /dev/sda /dev/sda: Seagate FreeAgent 102D

spin up again: grml: ~ # sdparm --command=start /dev/sda /dev/sda: Seagate FreeAgent 102D

Saves me re-inventing the wheel :-) Thanks!

On a sunny day (Sat, 20 Jun 2009 02:41:50 -0700) it happened Fred Abse wrote in :

Not all hdparm commands work on USB SCSI. hdparm -t and hdparm -T work to get the speed however.

You need to do this, I just found out: spin down: # sdparm --command=stop /dev/sda /dev/sda: Seagate FreeAgent 102D spinup: # sdparm --command=start /dev/sda /dev/sda: Seagate FreeAgent 102D

Yes, that was it! Did a cold start of the PC and the Seagate drive, and now speed is much better. on a copy from one partition to the next on that Seagate.

It was down to about 630 kByte / second, now I get 14314834932 bytes in 1560 seconds, makes about 9 MB / second, multiply by 2 as it both goes over the same USB link, makes 18 MB / second, add reiserfs overhead for a huge full destination partition, and we get close to the USB 2 maximum.

cat /proc/cpuinfo: model name : AMD Duron(tm) Processor cpu MHz : 959.485 cache size : 64 KB

fdisk: /dev/sda3 80145495 157290987 38572746+ 83 Linux /dev/sda8 158461243 1953525167 897531962+ 83 Linux

df: /dev/sda3 38571552 32840 38538712 1% /mnt/sda3 /dev/sda8 897504508 598244044 299260464 67% /mnt/sda8

ls -rtl /mnt/sda3:

-rw-r--r-- 1 root root 14314834932 2009-06-20 05:50 recording.ts

Test command: date ; mv recording.ts /mnt/sda8/video/movies/satellite/ ; date Sat Jun 20 16:14:41 CEST 2009 mv recording.ts 3.55s user 326.16s system 21% cpu 26:06.54 total Sat Jun 20 16:40:48 CEST 2009

I put the numbers here for other readers so they can verify some things if they run into the same problems.

'recording.ts' was a DVB-S (satellite) recording that ran all night (in USB 1 mode it seems !) until 5:50 in the morning, completed OK on time, but then reported a buffer overflow in my xdipo... that never happened before, made me very suspicious. It seems now that there was just enough speed to write to the disk, but closing the file in the huge reiserfs (version 3.6) sda8 partition took so long the DVD input buffer overflowed.... Maybe I should close the DVB-S stream first...

I am running kernel 2.6.21, maybe I should try a later one, but who knows what breaks then, 2.6.30 and 31 are totally reworked Iv heard .... the DVB driver was rewritten...

As I stated before: Linux is not for the normal point and click MS software user. OTOH that sort of user might have upgraded his PC to try to increase the speed... ;-)

On a sunny day (Sat, 20 Jun 2009 14:59:39 GMT) it happened Jan Panteltje wrote in :

input buffer overflowed....

Should be almost empty sda3 ... new theory needed to explain buffer overflow...

LOL

See

sdparm --clear STANDBY -6 /dev/sdWHATEVER

Thanks. That's one to remember.

-- "Electricity is of two kinds, positive and negative. The difference is, I presume, that one comes a little more expensive, but is more durable; the other is a cheaper thing, but the moths get into it." (Stephen Leacock)