On 2015-08-17 15:18, Tyler Bletsch wrote:
So far, that's been my use case for btrfs raid6, and (barring one bug I found involving an interaction between btrfs and thinly provisioned storage that shouldn't be an issue for you if you're not using LVM thin pools) I have yet to hit any bugs, although based on the lists, I've probably been _very_ lucky in that respect. If you're willing to take a marginal performance hit (about 1-3% in my experience, which is notably less than the performance difference between MD-RAID5 and MD-RAID6), and have at least four disks, I'd suggest using btrfs's raid6 profile instead of raid5, they use exactly the same code, it's just that raid6 has one more calculation involved and provides better protection against data corruption due to the double parity.Thanks. I will be trying raid5 in production, but "production" in this case just means my home file server, with btrfs snapshot+sync for all data and appropriate offsite non-btrfs backups for critical data. If it hoses up, I'll post a bug report.
Understandable, my main reasons for having LVM are storing virtual machine disk images and the fact that MD/DM raid is still ridiculously fast compared to btrfs raid (many of my btrfs raid volumes are themselves on top of LVM managed software raid0 or raid1 volumes).Going to try to avoid LVM, since half the appeal of btrfs for me is getting away from the multiple duct-taped layers of indirection that I you get currently with ext4/MD/LVM setups.
smime.p7s
Description: S/MIME Cryptographic Signature
