On 7/1/20 11:53 AM, Michael Catanzaro wrote:
On Wed, Jul 1, 2020 at 4:25 pm, Nicolas Mailhot via devel
<devel(a)lists.fedoraproject.org> 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