On Wed, Jul 1, 2020 at 5:06 PM Eric Sandeen
> On 7/1/20 11:53 AM, Michael Catanzaro wrote:
>> On Wed, Jul 1, 2020 at 4:25 pm, Nicolas Mailhot via devel
>>> 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
>> 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
> It's another cake eating-and-having option which is a pretty trivial
> thing to implement.
This does not solve the "Anaconda will blow away /home because it's
technically part of /" problem, though. Btrfs subvolumes do.
Directory quotas only protect against space contention, and while
Btrfs quotas do the same thing, we're deliberately not proposing
setting those up because we want space allocation to be flexible.
I was not proposing directory quotas as any protection against mkfs of the
root device, of course. Changing that behavior in Anaconda would be another
rather minor change as well, i.e. the equivalent of "rm -rf /usr /var/ ..."
instead of mkfs at reinstall time.