Once, long ago--actually, on Mon, Oct 29, 2012 at 08:57:12AM CDT--Alan Cox
With all due respect, no it isn't. It was simplistic, because I didn't
want to go into an entire tutorial on the mailing list. Go read about
P-lists, G-lists, and about the variation in how SMART information is
generated and used. This is generally because there was no industry-wide
agreement on exactly what should be reported, and how, for SMART, as well
as some proprietary protectionism from drive manuafacturers.
You see a bad sector on some devices after a sudden power fail
the sector was partially written when the power failed. It's not bad in
any permanent sense it's just got incomplete data on it so cannot be read
back properly until rewritten.
Some devices, and some drivers. It depends on how the driver interpreted
the failure, how it was reported by that disk and that controller, etc.
This particular scenario comprises a vanishingly small number of the total
number of errors a drive encounters in its life.
Similarly btw any case where a sector reports as "bad" on a
read does not
mean you've used up all the spare sectors or anything of the sort, it
means you've got a sector which failed to read.
Report of a single bad read depends very much on the driver. Most driver
authors will try to re-read a failed sector in the driver (no, I haven't
gone to look at the current Linux drivers. I was writing drivers for
Unix a long, long time ago, however, and we wouldn't report a bad read
until something like three internal retries.) However, the firmware will
do remapping of sectors _it_ determines are failing, and the probability is
that if you are seeing errors consistently, it's because it can't remap.
Some drives also (quite validly) report the number of sectors that
failed during the production of the device, which completely throws most
of the rather weak drive reporting stuff software.
Not at all valid. There are two lists in the drive--the P-list, which
contains sectors remapped during drive production, and the G-list, which
contains remaps instantiated by the drive firmware. IF the firmware
reports remapped sectors from both lists, it should most assuredly
segregate them. Granted, it's quite possible the author(s) of drive
reporting software have conflated or misinterpreted the data.
What really matters is whether the drive itself thinks on its smart
whether it is likely to be failing not some joke heuristic.
*Shrug*. The actual number of sectors in the G-list isn't a joke
heuristic. Whether or not you can get that out of the firmware is
vendor-specific. The bottom line is that there _is_ firmware in the
drive that attempts to prevent sectors going bad from being used by
preemtively remapping to spare sectors, and this will, in general,
mean that you won't know about them until and unless you look at the
stats on sector remapping. Whether you, as an administrator, go out
to try to find that, or the driver proactively does it, or whatever,
by the time you're getting real, persistent and increasing numbers of
errors visible at the OS interface, you've probably been having problems
internally for a while. It's not worth it today to go to excessive
lengths to repair a disk reporting errors.