On 7/1/20 11:53 AM, Michael Catanzaro wrote: > On Wed, Jul 1, 2020 at 4:25 pm, Nicolas Mailhot via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: >> Actually this split is a godsend because you can convince anaconda to >> leave your home alone when reinstalling, while someone always seems too >> invent a new Fedora change that justifies the reformatting of /. >> >> Good luck dealing with user data the next time workstation (or any >> other group) feels the / filesystem should change, once you've put user >> data on the same mount point > > So for the avoidance of doubt: if the btrfs change is rejected, we are almost certain to put everything on the same mount point. We haven't approved this yet, but odds are very high IMO. The options we are seriously considering for our default going forward are (a) btrfs, (b) failing that, probably ext4 all one big partition without LVM, (c) less-likely, maybe xfs all one big partition without LVM. This is being discussed in https://pagure.io/fedora-workstation/issue/152 > > We have a high number of complaints from developers running out of space on / with plenty of space left on /home (happens to me all the time). The opposite scenario is a problem too. Separate mountpoints by default is just not a good default, sorry. Ensuring users don't run out of space due to bad partitioning is more important than keeping /home during reinstall IMO. But with btrfs, then /home will just be a subvolume so we can have our cake and eat it too. This can be mitigated with directory (project) quotas, btw. On XFS, exceeding a directory tree quota even yields ENOSPC. (on ext4, it's EDQUOT right now.) So one big / partition including /home, with a directory quota set on /home at 20G, will yield ENOSPC when home contains 20G and will now allow / to get filled with user files. It's also trivial to adjust the directory quota on /home up or down, as needed. It's another cake eating-and-having option which is a pretty trivial thing to implement. -Eric _______________________________________________ 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
