Re: How does btrfs handle bad blocks in raid1?

[Roman Mamedov <rm@romanrm.net>]

[-- Attachment #1: Type: text/plain, Size: 1765 bytes --]

On Tue, 14 Jan 2014 14:05:11 -0700
Chris Murphy <lists@colorremedies.com> wrote:

> 
> On Jan 14, 2014, at 12:37 PM, Roman Mamedov <rm@romanrm.net> wrote:
> > 
> > I vaguely remember having some drives that were not able to remap a single
> > block on write, but doing that successfully if I overwrote a sizable area
> > around (and including) that block, or overwrite the whole drive. And after
> > that they worked without issue not exhibiting further bad blocks.
> 
> Presumably the SMART self-assessment for this drive was FAIL? 

No of course not, why? SMART goes to FAIL only if one of the attributes falls
below threshold, in this case that would be Reallocated Sector Count having
too much sectors. But nope, it either had zero, or in single-digit numbers.

I don't ever remember seeing a SMART FAIL drive that would function in any
usual sense of that word. Whereas such pecularities (bad sectors /
unremappable sectors / not wanting to remap until you overwrite large area and
perhaps even multiple times at that), all with SMART = PASS, are seen left
right and center.

> And if so what's the point of the work around when we only have a pass/fail
> level granularity for drive health?

Not sure what you're referring to here. As said above, the FAIL/PASS status is
largely useless, and the more important indicators are the values and dynamics
in Reallocated sector count, Current pending sectors, Reported uncorrectable,
etc.

> a way to send a command to the firmware to persistently increase the reserve
> sectors at the expensive of available space - in effect it reduces the LBA
> count by e.g. 10MB, thereby increasing the reserve pool by 10MB.

Yes please that, and also a pony. :)

- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]