I'm starting to experiment with btrfs on some of my servers, I really like some of its features, especially the data and metadata CRCs.

 

By default btrfs uses the DUP profile for metadata on single devices (except if an SSD is detected since it would basically be a waste of space), and from what I've read this can be very useful at the expense of very little extra space used, e.g., 1TB of data, mostly medium size files, 300MB to 1.5GB:

 

btrfs fi df /mnt/disk9
Data, single: total=997.01GiB, used=987.37GiB
System, DUP: total=32.00MiB, used=128.00KiB
Metadata, DUP: total=2.00GiB, used=1.09GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

 

 

An extra 2GB allocated for every TB of data for a little extra protection seems like a good deal to me, and for now I'm converting the metadata to DUP after the disk is formatted by unRAID.

 

I believe that unRAID redundancy should make it unnecessary in most cases, but it's not that uncommon to have disk go unmountable when it red balls, so unless there's some reason I'm missing why not use metadata DUP by default on array data disks?

 

 

 

why not use metadata DUP by default on array data disks?

Probably a good idea.

Wanted to bump this in case it fell through the cracks, as it seems a simple change and IMO an important one, was just today reading a post on the btrfs mailing list where one of the developers writes:

 

Quote

raid0 and single profiles are not a good idea for metadata if you want a filesystem that can persist across reboots (some use cases don't require persistence, so they can
use -msingle/-mraid0 btrfs as a large-scale tmpfs).

 

I manually convert all my disks to DUP metadata after formatting, but most users will be unaware of this.

 

Can someone ELI5 this? What makes this DUP profile in particular great?

It adds error recovery for filesystem metadata.

Yes, say a disk gets a bad sector where a metadata chunk is, it will use the other copy to recover, if there's metadata corruption you can lose the whole disk.