On Jan 9, 2014, at 6:31 PM, George Mitchell <geo...@chinilu.com> wrote: >> > Jim, my point was that IF the drive does not successfully resolve the bad > block issue and btrfs takes a write failure every time it attempts to > overwrite the bad data, it is not going to remap that data, but rather it is > going to fail the drive.
If the drive doesn't resolve a bad block on write, then the drive is toast. That's how md handles it. That's even how manufacturers handle it. The point at which write failures occur mean there are no reserve sectors left, or the head itself is having problems writing data to even good sectors. Either way, the drive isn't reliable for rw purposes and coming up with a bunch of code to fix bad drives isn't worth development time in my opinion. Such a drive is vaguely interesting for test purposes however, because even though the drive is toast, we'd like the system to remain stable with it connected first and foremost. And maybe we'd want it as a source during rebuild/replacement. > In other words, if the drive has a bad sector which it has not done anything > about at the drive level, btrfs will not remap the sector. It will, rather, > fail the drive. Is that not correct? I've skimmed for this in the code, but haven't found it, so I'm not sure what the handling is. It's probably easier to take a drive I don't care about, and use hdparm to cause a sector to be flagged as bad, and see how Btrfs handles it. (The hdparm command should be clearable, but I'd rather not screw up a drive I like.) Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
