On Sat, Jun 27, 2020 at 1:38 PM Gerald B. Cox <gb...@bzb.us> wrote:
> I was an early adopter and used BTRFS for many years, singing its praises.  I 
> was particularly interested in the RAID capabilities.  Then in 2016 the bomb 
> was dropped that:
> "It turns out the RAID5 and RAID6 code for the Btrfs file-system's built-in 
> RAID support is faulty and users should not be making use of it if you care 
> about your data."

The more recent threads that are relevant:

The proposal has nothing to do with raid56, let alone by default. The
installer doesn't offer it as an option. And it's not relevant to the
desktop. We're talking about single device btrfs file systems.

I'd say questions about the multiple device aspects of btrfs are
relevant and on-topic but not as a criticism of the proposal. If some
folks want to take that particular toy out of the toy box, they are
advised that btrfs raid is different than what they're used to, and
they shouldn't make assumptions about it.

> So, BTRFS is great, ready for prime time... many people are using it, etc. 
> etc. etc. until something goes wrong and then you get... well, it's 
> experimental and not intended for production.  Sucks to be you.

The raid56 criticism is relevant to raid56 use cases. What you're
doing above is an association fallacy.

> At some point you have to fish or cut bait.  I was under the impression that 
> Redhat had done exactly that with the announcement and direction of Stratis.
> Why are we not concentrating on Stratis and XFS?

This is partly addressed in the device-mapper section of the proposal,
as it depends on dm-thin. Integration with the desktop represents
non-trivial work to get both CLI and GUI apps to report thin pool
values, which is necessary because only it knows the truth of free and
used space. There is no compression, integrity, or cgroup2-IO
isolation support either, all of which are features we think are
useful to users now and in the near future.

Also, Stratis specifically it's not supported as system root, and has
no installer support.

Chris Murphy
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to