On Sat, Jun 27, 2020 at 1:23 PM Chris Murphy <li...@colorremedies.com> wrote:
> > 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: 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/devel@lists.fedoraproject.org
