On Sat, Jun 27, 2020 at 2:53 PM Gerald B. Cox <gbcox@xxxxxx> wrote: > 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? This is a really good point. The installer does let you choose multiple drives and apply default partitioning scheme. The last time I tested this ages ago, the result is a simple linear/concat of the drives, using LVM. For btrfs, it is either 'single' or 'raid0' profile for data, but 'raid1' for metadata (the file system itself). I need to test it or maybe someone beats me to it by looking at the code. But either way it's equal to or better than the current default. > Why would we be installing something by default that has widely known broken functionality? Because the default configuration we're using isn't broken and is better than the alternatives being evaluated. > 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. And they're going to get into trouble with raid56 how? Are you going to tell them they should convert to raid56? How is it even relevant? > 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? Literally none of this is correct. >> > 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? I don't know. Why aren't you working on that? By all means put together a competing proposal. I'm working on what I'm working on. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
