No. This depends on the vendor defaults for the specific mode-pages
(or how do you changed them).
So Alan's "it does transparent block remapping" should be more
"it can do transparent block remapping".
> - There is a limit to how many bad sectors that can be remapped
yes, it's more complicated because you may have multiple remapping
areas, so a block is remapped to a place where the seek-time is low.
> - There can be a number of sectors already remapped when you buy the drive new
yes. For SCSI level there exists three defect lists. One is for vendor
dedected defects and one is for grown defects.
> - There are very few drives out there that are totally error free - if there
> were, you'd be paying a lot more for drives
I've never seen a drive without vendor defects. But they may exist.
Hint: Maybe you don't pay much more for a low error drive, you pay just for
the fact that vendors do not track the vendor errors in the vendor
defect list....
> - Consequently, most drives aren't error-free when they come out of the box
Yes.
> 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.
Yes. Let's try a definition:
A drive is really bad if linked write-read requests
over the whole "READ CAPACITY" LBA space fails more than 0 times
with transparent remapping on write enabled.
For conservative people a drive is bad after the first entry in the grown
defect list or the first ECC read error, what ever comes first.
(except if the drive supports WRITE LONG and you wrote bad ECC by
yourself which may be good for testing. Too bad that I've never seen a
SCSI drive that supports READ/WRITE LONG.)
--ciao - Stefan
"you have moved your mouse, please reboot to make this change take effect"
Stefan Traby Linux/ia32 fax: +43-3133-6107-9 Mitterlasznitzstr. 13 Linux/alpha phone: +43-3133-6107-2 8302 Nestelbach Linux/sparc http://www.hello-penguin.com Austria mailto://st.traby@opengroup.org Europe mailto://stefan@hello-penguin.com
- 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/