About USB hard drives and errors
in [Debian]
|
Prev: ditching mutt
Next: Ubuntu vs Debian forums (was recompiling the kernel with a different version name)
From: Florian Kulzer on 10 Apr 2010 12:10 On Sat, Apr 10, 2010 at 08:45:26 -0500, Ron Johnson wrote: > On 2010-04-10 02:20, Clive McBarton wrote: [...] > >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. > > > >You can see the internal count of the remapped sectors with SMART, as > >others have already pointed out here. > > Interesting. So what is /badblocks/ for, I would say it is useful to make the drive access every single block; afterwards you can check in the SMART log if that caused any remappings. > and should it be removed > in order to remove useless complexity? I would not consider a command-line utility that can simply be ignored to be useless complexity. -- Regards, | Florian | -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100410154659.GA11210(a)isar.localhost
From: Clive McBarton on 10 Apr 2010 13:10 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Kulzer wrote: >> Interesting. So what is /badblocks/ for, > > I would say it is useful to make the drive access every single block; > afterwards you can check in the SMART log if that caused any remappings. That's a good idea. Another application is if you suspect that part of the HD surface is bad (old age, you dropped the HD, etc.) but the HD does not know it yet because it has not accessed the damaged sectors yet. Then badblocks (or dd) will force it to do so, probably bricking the HD in the process (sometimes with audible clicking noises or such) which, if you think about it, can be very useful if you intended to store valuable data on it later. >> should it be removed >> in order to remove useless complexity? > > I would not consider a command-line utility that can simply be ignored > to be useless complexity. Indeed, and that is true for thousands of CLI commands. ImageMagick alone installs dozens which add complexity to your system if unused. Back to the topic of HDs, I even remember seeing a unix program for low-level formatting them, though formattable HDs probably have ceased to be sold a long time ago. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvAsE0ACgkQ+VSRxYk440/yowCgj8/SSjj3PtgHVdq3BWuUG6MF txMAn3HMUtUM+tTnZ0PyYhzx6qUy0V2p =D76w -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BC0B04D.3090900(a)web.de
From: Tony Nelson on 10 Apr 2010 14:00 On 10-04-10 03:20:44, Clive McBarton wrote: > 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. Not quite true. If the data in a sector was not readable, the sector will be listed as "Pending". Pending sectors are much worse than Reallocated sectors, as Pending sectors mean lost data (if the sector was in actual use, which SMART does not know -- and figuring out which file might have been affected is, umm, tedious). I keep SMART's Offline Surface Scan enabled on my drives, to have the best chance that any failing sectors will be noticed early while they can still be recovered. I don't mind if there are a few Reallocated sectors, as long as there are never any Pending sectors. I'd mind if the number of Reallocated sectors kept increasing. Of course, I also keep backups. > In other words, scanning for bad blocks on a HD cannot work. Or at least normally won't, unless Data Has Been Lost. > You can see the internal count of the remapped sectors with SMART, as > others have already pointed out here. Agree. Use smartctl. -- ____________________________________________________________________ TonyN.:' <mailto:tonynelson(a)georgeanelson.com> ' <http://www.georgeanelson.com/> -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/1270922015.29981.0(a)localhost.localdomain
From: Clive McBarton on 10 Apr 2010 15:00 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Nelson wrote: > If the data in a sector was not readable, the sector > will be listed as "Pending". Pending sectors are much worse than > Reallocated sectors, as Pending sectors mean lost data (if the sector > was in actual use, which SMART does not know -- and figuring out which > file might have been affected is, umm, tedious). OK. Usually (during regular use) the internal errors probably increase more slowly. If a single sector is already really unreadable, then every last one of the internal error correction mechanisms has already tried and failed. Such many errors probably indicate that either the HD is terminally worn out, or that a sector got damaged due to external influences. Either way, I would not use such a HD any more. > I keep SMART's Offline Surface Scan enabled on my drives, to have the > best chance that any failing sectors will be noticed early while they > can still be recovered. I don't mind if there are a few Reallocated > sectors, as long as there are never any Pending sectors. I'd mind if > the number of Reallocated sectors kept increasing. Of course, I also > keep backups. Good practice. But I believe that HDs always try to recover failing sectors whenever possible, with or without offline surface scan. Presumably sectors are remapped when the number of errors is still way below the maximum of correctable errors. The world outside the HD never hears anything about it unless they ask the HD to report the SMART tables. >> In other words, scanning for bad blocks on a HD cannot work. > > Or at least normally won't, unless Data Has Been Lost. Yes, that's what I meant. It does work for proving for sure that the HD is broken. And to push a HD over the edge which is about to break (useful particularly for people with backups). I was assuming that the HD does not contain data, since the write test of badblocks deletes everything anyway and does not restore the original. Speaking of, does anybody know why the programmers of badblocks left out the ability to write the original content back after a read-write scan? That makes no sense to me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvAybYACgkQ+VSRxYk4408JNgCg59NgXTrJd+LbdzS+x/1QgAJm 6WIAoI66+djV1dAA7aVCe1VbLsdHn8U8 =g2yo -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BC0C9B6.8090704(a)web.de
From: Stefan Monnier on 10 Apr 2010 16:20
> will be listed as "Pending". Pending sectors are much worse than > Reallocated sectors, as Pending sectors mean lost data (if the sector Indeed. OTOH "Pending sectors" can be eliminated by turning them into Reallocated sectors (just write to the corresponding sector), whereas Reallocated sectors will stay forever. Stefan -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/jwvfx3312sd.fsf-monnier+gmane.linux.debian.user(a)gnu.org |