1

Since btrfs doesn't maintain a list of badblocks, I'm looking for a work-around at a lower layer.

(I'm mining burstcoin and don't mind losing a few blocks here and there.)

It seems that LVM doesn't maintain a badblocks list also.

There is a ingenious work-around with dmsetup: creating a table avoiding current bad blocks with an unallocated pool of spare good blocks to fill in for bad ones as they occur. However, I want something more set-and-forget.

This btrfs mailing list post suggested it may be possible to use btrfs over mdadm 3.1+ (which supports badblocks) with RAID0.

How would one use mdadm with the intent of providing a badblocks "layer"?

Tom Hale
  • 28,728
  • 32
  • 139
  • 229
  • `mdadm` metadata 1.0 and later natively track bad blocks on component devices, but I don’t know if an “array” would survive a bad block if there is no way of reconstructing the missing data (I guess that’s the real question). – Stephen Kitt May 02 '17 at 11:17
  • If you have read errors you should get a new drive... mdadm's bad block log is only 4K in size so it can't deal with extensive list of bad blocks. It's a bandaid for keeping RAIDs running a little longer, the goal is still a disk replacement. – frostschutz May 02 '17 at 12:00
  • Also mdadm does nothing to make the filesystem happier, it still runs into read errors. md will even cause read errors even after the drives got replaced, if the bad block list propagated to more than one drive during rebuild. – frostschutz May 02 '17 at 12:07
  • @frostschutz Assuming 32-bits are used for storing a bad block that would allow for 1024 bad blocks... – Tom Hale May 02 '17 at 13:17
  • @frostschutz isn’t the bbl stored per drive (or component device)? (`mdadm --examine-badblocks` only works on component devices...) How would it end up being copied during a rebuild? – Stephen Kitt May 02 '17 at 13:31

1 Answers1

2

I asked on the linux-raid mailing list if this were possible, and the answer was "no".

Tom Hale
  • 28,728
  • 32
  • 139
  • 229