Re: About USB hard drives and errors
On 20100410_162445, Paul E Condon wrote:
> On 20100410_092044, Clive McBarton wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Paul E Condon wrote:>
> > > dumpe2fs -b <device> is supposed to print the bad blocks that have
> > > been marked on a device. When I run it, it prints nothing. I find it
> > > hard to believe that a 500GB HD contains ZERO bad blocks.
> >
> > Every HD that is even remotely close to being usable will always have
> > zero bad blocks when seen from outside the HD. All HDs have error
> > recognition and error correction and automatic replacement of faulty
> > sectors with spare ones. A HD will only show bad blocks after all of its
> > remapping area is used, at which point it is far beyond being usable.
> >
> > In other words, scanning for bad blocks on a HD cannot work.
>
> Thanks Clive. Your post has been invaluable in fixing some faulty thinking
> on my part, and in provoking other useful posts. But I want more ...
>
> The errors that I am experiencing are all similar. The first
> indication of a problem is a message from the kernel (I think). An
> example is:
>
> kernel: [78454.939948] journal commit I/O error
>
> This appears on all xterm windows on the affected machine. On the
> xterm that is controlling a process that is using one of the USB
> drives, there follows a long sequence of error messages about the
> drive being read-only, which stops after a while. Or sometimes I stop
> it by typing ^C on that xterm.
>
> When this happens, all the USB drives (3 of them) disappear from
> /dev/disks/by-label (they are all labeled by me). I have not
> discovered any to make them re-appear, short of rebooting the
> computer. After reboot, I run e2fsck on all of them, and always get a
> longish delay on each while e2fsck commits (or whatever) the
> journal. This can take a few seconds or up to half a minute. Then
> I manually mount them using pmount, and all data upto the point
> where the crash happened seems to be present.
>
> I have installed smartmontools, but I think there is some
> incompatibility between the installed version and the installed
> docs. The README.Debian makes reference to editing some lines in the
> config file that are not present in the default, package installed,
> config file. There is (apparently) some incompatibility between using
> the daemon and using smartctl. The problem host is running Lenny, but
> the docs seem to be the same as on a different host that is running
> Squeeze.
>
> I would very much appreciate some help in understanding the docs.
> What is a safe thing for a nubie to type as a first command to
> smartctl?
I'm answering my own post in order to bring some closure on this issue.
If anyone has suggestions, please come forward. But here is where things
stand with me:
I got a little less timid and tried running smartctl even though I was
quite unsure of what to expect. It ran. Each of the three USB HD gave
somewhat different output, but none gave output that claimed there was
a working SMART on the drive. These drives are Western Digital (WD).
The WD web site mentions SMART and also uses the words Smart Drive to
mean something else that is a proprietary marketing thing, AFAICT. I
was unable to find a list of part #s for drives that support S.M.A.R.T.
I think I should be in the market for a better class of drives, but not
this weekend. Thanks for the help.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: