On Sat, Jan 2, 2021 at 11:55 AM Richard Shaw <hobbes1069@xxxxxxxxx> wrote: > > From what I've been able to find online it doesn't look like RAID 5 is well supported by btrfs currently. Anyone have any data to the contrary? There are caveats. If you can live with them, then it's OK. But obligatory reading: https://lore.kernel.org/linux-btrfs/20200627032414.GX10769@xxxxxxxxxxxxxx/ You definitely want metadata raid1, and use free space tree (space_cache v2) for this setup. A top use case and expectation is the uptime in the face of a device failure. If you're able to quickly do a 'btrfs replace' (another requirement, don't use 'dev add' + 'dev remove') then it might be OK. > I have a 4TB media drive that's filling up and I'd like to add two more disks to both increase capacity and add some redundancy. My understanding is that if I did a 3 drive btrfs RAID 1 that I would just have 3 copies of the same data and zero increased capacity. No. Btrfs raid1 is exactly two copies no matter how many drives are in the pool. There's raid1c3 for three copies, and raid1c4 for four copies. A three device btrfs raid1 is valid. Btrfs does not do raid at a block level like md raid. It's at the block group level. A block group is a ~1G contiguous region of extents. You could consider the block group a super extent, similar to how an extent is a collection of blocks. Like extent size, the block group size isn't fixed, but generally it appears in 1G amounts. The block group "profile" is what determines the number and behavior of chunks that get allocated to various devices. A chunk is the physical manifestation of a block group on actual devices. The single profile means 1:1 block group to chunk. The dup profile means 1:2 block group to chunk *on the same device*. The raid1 profile also is 1:2 block group to chunk but on different devices. And how this gets allocated depends mainly on free space remaining. So it is possible for a block group with raid1 profile to be allocated with mirror chunks on drive A and B, and for the very next block group allocated will be chunks on drives B and C. This is why free space reporting on Btrfs can be confusing. Even number of same sized drives with raid1 is OK, but then odd number of drives or mix and match drive sizes and it gets screwy, even though it's valid and Btrfs will use Tetris technique to fill in the free space wherever it is. https://github.com/kdave/btrfs-progs/issues/277 https://carfax.org.uk/btrfs-usage/ -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
