Can btrfs track / avoid bad blocks?

Question

I have a HDD which I don't entirely trust, but still want to use (burstcoin mining, where if I get a bad block in a file, I'll only lose a few cents).

How can I tell btrfs to mark certain blocks as bad (eg from badblocks output)?

If I can't pre-mark blocks as bad, will any bad blocks identified by btrfs scrub be avoided in future if the file using them is deleted?

Answer 1

Sadly, no.

btrfs doesn't track bad blocks and btrfs scrub doesn't prevent the next file from hitting the same bad block(s).

This btrfs mailing list post suggests to use ext4 with mkfs.ext4 -c (this "builds a bad blocks list and then won't use those sectors"). The suggestion to use btrfs over mdadm 3.1+ with RAID0 will not work.

It seems that LVM doesn't support badblock reallocation.

A work-around is to build a device excluding blocks known to be bad: btrfs over dmsetup.

---

The btrfs Project Ideas wiki says:

Not claimed — no patches yet — Not in kernel yet

Currently btrfs doesn't keep track of bad blocks, disk blocks that are very likely to lose data written to them. Btrfs should accept a list in badblocks' output format, store it in a new btree (or maybe in the current extent tree, with a new flag), relocate whatever data the blocks contain, and reserve these blocks so they can't be used for future allocations. Additionally, scrub could be taught to test for bad blocks when a checksum error is found. This would make scrub much more useful; checksum errors are generally caused by the disk, but while scrub detects afflicted files, which in a backup scenario gives the opportunity to recreate them, the next file to reuse the bad blocks will just start getting errors instead. These two items would match an ext4 feature (used through e2fsck).

Please comment if the status changes and I will update this answer.

Answer 2

This is how I'm thinking to workaround this limitation. An imperfect solution.

1. Create ext4 without journaling as the filesystem (with bad blocks marked)
2. Create a btrfs file image on top of the ext4.
3. Mount the btrfs image with loop device.

There may be some slight extra overhead to be expected.