On 2018-10-14 07:08, waxhead wrote:
In case BTRFS fails to WRITE to a disk. What happens?
Does the bad area get mapped out somehow? Does it try again until it
succeed or until it "times out" or reach a threshold counter?
Does it eventually try to write to a different disk (in case of using
the raid1/10 profile?)
Building on Qu's answer (which is absolutely correct), BTRFS makes the
perfectly reasonable assumption that you're not trying to use known bad
hardware. It's not alone in this respect either, pretty much every
Linux filesystem makes the exact same assumption (and almost all
non-Linux ones too), because it really is a perfectly reasonable
assumption. The only exception is ext[234], but they only support it
statically (you can set the bad block list at mkfs time, but not
afterwards, and they don't update it at runtime), and it's a holdover
from earlier filesystems which originated at a time when storage was
sufficiently expensive _and_ unreliable that you kept using disks until
they were essentially completely dead.
The reality is that with modern storage hardware, if you have
persistently bad sectors the device is either defective (and should be
returned under warranty), or it's beyond expected EOL (and should just
be replaced). Most people know about SSD's doing block remapping to
avoid bad blocks, but hard drives do it to, and they're actually rather
good at it. In both cases, enough spare blocks are provided that the
device can handle average rates of media errors through the entirety of
it's average life expectancy without running out of spare blocks.
On top of all of that though, it's fully possible to work around bad
blocks in the block layer if you take the time to actually do it. With
a bit of reasonably simple math, you can easily set up an LVM volume
that actively avoids all the bad blocks on a disk while still fully
utilizing the rest of the volume. Similarly, with a bit of work (and a
partition table that supports _lots_ of partitions) you can work around
bad blocks with an MD concatenated device.
