Date: Wed, 12 Apr 2000 11:46:53 -0500
From: Ed Carp <erc@pobox.com>
Feel free to correct me, but it is my understand that:
- Bad sectors are automatically remapped to another track
- There is a limit to how many bad sectors that can be remapped
- There can be a number of sectors already remapped when you buy the drive new
- There are very few drives out there that are totally error free - if there
were, you'd be paying a lot more for drives
- Consequently, most drives aren't error-free when they come out of the box
Now, the question is, what happens when that remap track gets full?
The drive reports an error back to the OS, and that's where the
problem starts. So this idea that "toss the drive if you have one
bad block" is dumb, because they *all* have bad blocks, and getting
an error on a block is no guarantee that your drive is failing -
drives generally have an advertised error rate - and while it's close
to zero, it's not zero, and even if it's 10E33, you're going to hit
that sooner or later.
Disk come with some number of bad blocks "from the factory". This is
the same when you buy a laptop, the usual standard is that up to 5
pixels can be bad, and the manufacturer will still call it a "good"
screen.
However, it's not the case that disks should in normal operation
randomly start to lose blocks, which they then automatically remap.
It's good that they can do this, but remember that you are potentially
*losing* *data* when this happens. It's one thing when you have defects
from the manufacturing process; it's quite another thing to have blocks
go bad after the disk has been placed into service. While it does
happen, it's very rare, and if it happened as often as you seem to think
it does, then files would be getting corrupted all the time --- and
that's not the case.
In most production houses that I've seen, if a disk starts reporting
soft errors (which is where the block was ultimately readable, but the
disk had to retry several times), that's generally the cue to replace
the disk. That's because it's generally the case that the data on the
disk is far more valuable than the cost of replacing the disk (heck the
cost in people time of having restore from backup tapes is probably more
than the cost of the disk), and after 2-3 years of hard service in a
fileserver, the disk probably doesn't have much more life in it anyway.
There are exceptions to this rule, of course ---- if you're in a country
like Russia where disks are extremely expensive, then maybe the
cost/benefit ratio changes. Or if you're a poor student, or if the
server is in a location which is very hard to get to. However, I don't
buy the "7x24" argument. If a service is so critical that it has to be
up 7 days a week, 24 hours a day, it's also probably so critical that
unscheduled downtime is far more disastrous than a planned downtime.
Also, if there is a requirement that it be up 7x24, why aren't there
redundant servers (never mind redundant disks in a RAID array)?
Anyway, we've started straying off topic. In answer to your question
--- it may be worth doing, but it's too close to 2.4, and I have other
higher priority projects --- and when/if it gets implemented, if you
depend on it too much, IMO you're probably trying to do things on the
cheap, and you WILL regret it someday. :-)
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:19 EST