Re: Btrfs is amazing! (a lack-of-bug report)

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

On 2015-08-17 15:18, Tyler Bletsch wrote:
> 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.
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.
>
> 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.
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).



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]