[sf-lug] semi-OT: help with dying disk

[jim stockford]

    if you're having the same problems on the same
machine, verify that your power supply is okay.
    if the power supply intermittently goes out, even
briefly, the system attempts to write to the drive
get flaky, sometimes very flaky, with results such
as you've described.

    it's a good idea to use the -c option to mke2fs
when you're putting an ext{2,3} filesystem on a
partition.
# mke2fs -c <device_name>
the -c option checks for bad blocks before putting
the filesystem on the partition.



On Mar 13, 2008, at 7:49 PM, matt.price at utoronto.ca wrote:

> hi folks,
>
> i htink i may have asked a similar question before, since this is the
> second time in 3 months that i've had a disk drive die, and no, i
> apparently still haven't learned my lesson.
>
> the hard drive in my laptop is dying, with messages of this ilk:
>
> -----------
> root at ubuntu:~# tail /var/log/messages
> Mar 14 02:28:55 ubuntu kernel: [17232.876000]         08 21 3f e0
> Mar 14 02:28:55 ubuntu kernel: [17232.876000] sd 0:0:0:0: [sda] Add.
> Sense: Unrecovered read error - auto reallocate failed
> Mar 14 02:28:55 ubuntu kernel: [17232.876000] end_request: I/O error,
> dev sda, sector 136396768
> Mar 14 02:28:55 ubuntu kernel: [17232.876000] ata1: EH complete
> Mar 14 02:28:55 ubuntu kernel: [17232.876000] sd 0:0:0:0: [sda]
> 195371568 512-byte hardware sectors (100030 MB)
> Mar 14 02:28:55 ubuntu kernel: [17232.876000] sd 0:0:0:0: [sda] Write
> Protect is off
> Mar 14 02:28:55 ubuntu kernel: [17232.880000] sd 0:0:0:0: [sda] Write
> cache: enabled, read cache: enabled, doesn't support DPO or FUA
> Mar 14 02:28:55 ubuntu kernel: [17232.880000] sd 0:0:0:0: [sda]
> 195371568 512-byte hardware sectors (100030 MB)
> Mar 14 02:28:55 ubuntu kernel: [17232.880000] sd 0:0:0:0: [sda] Write
> Protect is off
> Mar 14 02:28:55 ubuntu kernel: [17232.880000] sd 0:0:0:0: [sda] Write
> cache: enabled, read cache: enabled, doesn't support DPO or FUA
> -----------
>
> i'm currently at this point:
> i've dug up an ubuntu live cd & managed to run fsck on the root
> partition on this machine.  there were lots of errors but i just said
> yes to everything it wanted to do and in the end, when i mounted the
> repaired partition, there were only a couple of dozen files in the
> lost+found.  so i immediately started rsyncing to my backup (too
> late!! i know)& have found that in general, i can go for about a
> gigabyte before getting these errors, at which point rsync eventually
> dies.  i have this feeling (likely wrong) that it doesn't always stop
> in the same places -- that is, that it's not necessarily that the disk
> has a hole where the file's supposed to be, but that it's just tired.
>    so as regards recovery, i wanted to know whether there is some kind
> of strategy for reducing the strain on the disk -- it feels to me as
> though it's slowly dying but it might last longer if i treat it gently
> (i have no idea whether this is remotely true or even possible).
>
> that's the most important question.
>
> then i have a second one, regarding a new disk.  from the looks of it,
> $150 will now buy either 200 gigs of 7200 RPM  2.5" disk, or 250 gigs
> of 5400 RPM.  any idea how the speed difference is likely to affect
> both speed and power consumption on my laptop?  this is a dell d820
> laptop with a core duo cpu, so it's fairly quick by my standards, but
> of course i wouldn't mind it being faster; however, it's also a
> terrible power hog under linux, currently (with what i believe is a
> 5400 rpm disk) barely staying up for an hour on battery power.
>
> so i wondered, any comments on the likely speed/power tradeoff, and
> also any hints about increasing disk lifetime?  this is the first
> laptop drive that's failedo n me, and i'm wondering whether it's just
> bad luck, a bad manufacturer, or possibly some defect in the way that
> disk access is managed under recent versions of ubuntu.
>
> so thanks much!!
>
> matt
>
>
>
>
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
>