On Sat, Jun 27, 2020 at 1:23 PM Chris Murphy <li...@colorremedies.com>

> 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.

Isn't the proposal talking about BTRFS as a default for workstations?  Are
you saying that Anaconda is just going to check to see if a PC has only one
hard drive and then install BTRFS there, but if it has two devices use
something else?  Why would we be installing something by default that has
widely known broken functionality?  I would think it would be more
appropriate to have people who specifically want to use BTRFS functionality
and are aware and knowledgeable of the risks to seek it out rather than
have it be some sort of selective default.  The target audience you're
aiming at by making it the default doesn't know FAT from NTFS from EXT4
from XFS from BTRFS or do they care.   Neither are they aware or even care
about purported benefits.

> > 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.

Actually no, this doesn't apply to just raid56.  I haven't seen where BTRFS
has been declared production ready.  It's always been this or that feature
is OK, another feature is mostly OK, or don't use this feature.  Then when
something goes wrong, the response is it's still experimental and not
intended for production workloads.  People then mention Facebook uses it...
but my understanding is that Facebook is "testing it in production".  They
don't RELY on it in production.  Why do we want to push something out like
that as a default?

> 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.

Ok, then why aren't we working on that?
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