Re: How does btrfs handle bad blocks in raid1?

[George Mitchell <george@chinilu.com>]

On 01/14/2014 11:13 AM, Chris Murphy wrote:
> On Jan 9, 2014, at 6:31 PM, George Mitchell <george@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
Chris,  Please don't misunderstand me.  I am not advocating that btrfs 
or any other filesystem should be dealing with bad blocks.  I believe 
very strongly that if the drive firmware can't deal with that 
transparently the drive is, indeed, toast, and should be tossed.  And 
the key to monitoring hard drive health, in my opinion, is SMART and 
what we are lacking at this point is a SMART capability to provide 
visual notifications to the user when any hard drive starts to seriously 
degrade or suddenly fails.  This would ideally be mediated by journal 
daemon which desperately needs to be enhanced to provide visual and 
ideally audible pop up warnings to the user in such cases.  It would be 
nice to have those notifications from btrfs as well, also mediated by 
journal daemon, but this is really a SMART specialty and SMART should be 
our first line defense.  Where we need btrfs to move is toward automated 
resiliency, automatically dropping the bad drive(s) and automatically 
following up with a rebalance and return to sanity.  If SMART were 
capable of launching pop up warnings, btrfs would not have to worry so 
much about arrays going simplex undetected.   And it should really be 
the user's responsibility to be running SMART and providing sufficient 
number of drives AND sufficient additional free space to accommodate 
potential drive failure and still retain desired level of redundancy 
extra drives in their RAID arrays.  That is where I stand on this.