The current partitioning layout - separate file systems for /home and / with no space sharing between them - is problematic. Depending on the amount of physical storage the user is willing to allocate to Fedora, the competition for free space between /home and / increasingly leads to one of them running out of free space.
Two schools of thought:
Ideas to avoid the problem, that are ready now:
/usr /etc
/var /home
~/
For the purposes of this issue, /boot and swap are ignored: (a) they aren't the source of the problem, nor part of the solution (b) such details are best addressed in the specific proposals.
This issue obsoletes #54. What's needed now are proposals to fix the problem.
For me,
Btrfs
+CoW +Native encryption in future (with possibility to convert online) +Easy and cheap backups +Transparent compression +-Has bad reputation about stability, though was improved a lot lately (+ default FS in SUSE) -Not supported by RHEL
XFS
+reflinks +-somewhat stable -Not possible to preserve /home during reinstallation in simple way -No snapshots -Not shrinkable
Ext4
+Stable -No snapshots -Not possible to preserve /home during reinstallation in simple way
LVM Thin Provisioning
-Overcomplicated for average user +-Backups are possible, but slow
/usr /etc on partition A, /var /home on partition B
I think this is too complicated and does not make much sense, though the easiest.
Flatpaks and mock should use space in ~/
There will always be some tools that want to write into a system directories, so I think this is wrong way to approach it.
My vote is to do "one big file system."
The exact choice of filesystem is not so important for resolving this issue. Based on recent discussions, btrfs seems preferable and ready for prime time. Otherwise, ext4 has served us well for a long time. Switching to xfs at this point would be strange.
My view is that if we just change to the default configuration for Btrfs in Anaconda, that is enough to fix this issue.
There's a roadmap of interesting items that I definitely think we could take advantage of, and that would be worthy of separate proposals, but for this issue, just switching from the lvm+ext4 configuration to the Btrfs configuration that Anaconda does by default would be sufficient to solve this issue.
Metadata Update from @chrismurphy: - Issue tagged with: installation, meeting
"one big filesystem" has a major design flaw, you will loose /home on a os change or reinstall ( done by a ui guided system ). Having a Boot partition is also a good idea and necessary for FDE.
"LVM" too complex for most users. I have no idea, why this is the current default.
"btrfs or ext4" hmm.. ext4 is known to most users, stable, easy to fix. btrfs not so known to many users, stable, but i can't say anything about fixability.
With regard to btrfs fixability, see @josef reply at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/F5FYHGND4DHLN5R5ZIT2DF3VYI6TIAUR/
Metadata Update from @chrismurphy: - Issue untagged with: meeting
LVM Thin Provisioning -Overcomplicated for average user +-Backups are possible, but slow
I'm a Qubes user (based on Fedora w/ LVM), who has only a small stake in this decision, as it's only a change to the defaults in Anaconda.
However, I felt I had something to contribute to the discussion.
Just wanted to note that LVM thin backups can be fast, please see the wyng-backup project on github, which parses LVM thin volume metadata to quickly find changes between backups: https://github.com/tasket/wyng-backup
Some of the issues run into with LVM (over in the Qubes community) are due to poor LVM defaults. E.g. default maximum metadata storage percentage tended to not be appropriate for hosting many multiply cloned VM volumes, leading to some users running out of metadata storage room which could corrupt storage and/or cause inability to boot. This can be addressed by more sane metadata storage values and changes to the volume layout in Anaconda (e.g. as in Qubes 4.1)
B
In case anyone cares, I'm using a small /boot partition and a LUKS-encrypted / (XFS) since many years. Absolutely no problems at all.
Ideas to avoid the problem, that are ready now: "One big file system" concept. Plain partition, no LVM. Btrfs (has its own volume manager) XFS Ext4
"One big file system" concept. Plain partition, no LVM. Btrfs (has its own volume manager) XFS Ext4
What about NILFS? Would it aid in solving the issue? The NILFS supports many of the same features as btrfs such as snapshots but is known for better reliability and stability among its users. It's also as fast if not faster than Ext4 based on what I've read.
I think that NILFS should get at least a consideration as an alternative to btrfs because btrfs is quite controversial file system. And I have to say that I personally don't like btrfs at all based on my experiences with it. Fedora already supports NILFS but not many Fedora users aren't aware of it or don't know that this file system exists.
https://nilfs.sourceforge.io/en/index.html
What about NILFS?
https://nilfs.sourceforge.io/en/pkg_fedora.html says that SELinux needs to be put in permissive mode or disabled otherwise write access will fail.
My vote is to do "one big file system." The exact choice of filesystem is not so important for resolving this issue. Based on recent discussions, btrfs seems preferable and ready for prime time. Otherwise, ext4 has served us well for a long time. Switching to xfs at this point would be strange.
I'd like to request a vote on this please. We switch to one big filesystem, with no LVM. If the btrfs change goes through, it will be btrfs; otherwise, ext4.
Metadata Update from @catanzaro: - Issue tagged with: meeting-request
I'm stuck on the fall back position, because I see equal merit and knock on effects of reverting to LVM+ext4 or one big ext4. And that is the loss of /home reuse in the installer: (a) my own bias, because I use this often in QA testing over the years and see it used by others; (b) at least one Anaconda developer recommends sticking with LVM+ext4 or going with Btrfs. (c) it's some extra churn to do switch to ext4 for F33, and then switch again to Btrfs for F34.
I'd say if Btrfs proposal fails, one big ext4 is a reasonable fallback (even though I'm on the fence.)
But the Btrfs proposal contingency should probably remain LVM+ext4 to avoid the extra change for just one cycle.
If #153 is not approved, then the proposal to switch to "one big ext4" is on the table. But does it require a change proposal? We can ask FESCo for a late arrival?
It really isn't applicable as a contingency to #153. I discussed that on #fedora-qa and @bcotton said: cmurf: i'd be worried about throwing in what's essentially another change as the contingency plan of a change. granted plain ext4 is not as different from ext4 on lvm as btrfs is, but it still seems like it could be a crunch.
With my FESCo hat on: Yes, it is definitely requires separate change proposal.
the "one big fs" approach has a big disadvantage for any filesystem used, as you will destroy the home parition on a reinstall of "a" os, which can be avoided if /sys and /home are keep away from each other.
You already mentioned that. It won't be a problem if we switch to btrfs. With ext4 or xfs, we have to either accept that downside or not fix this issue. I think we will fix it, because fixing this issue by default is more important IMO, and people who want to be able to reuse home will have to use custom partitioning. But it probably won't be a problem, because btrfs. :)
Hello, I thought I should put in my 2cents. I'm a proficient linux user/administrator. I am responsible for ~20 servers and a handful of linux desktops. Its not huge but I've been doing this for decades. I just wanted to provides some context.
I never used LVM, mostly because I found configuring it and the terminology confusingly similar. I realize had I given it a chance and really delved in I probably wouldn't have had that experience. I know I've had a few servers over the years provisioned by a data center that had LVM and I had to search up how to do what I wanted to with a CLI.
The reason I say this is because, it seems to me that this problem hits people that are perhaps like me or less experienced. If they are like me, adjusting/dealing with the filesystem is a one off operation when necessary. I partition and don't run out of space because I know what the partitions are for and what space I kinda need. I have run out of space but its rare. When I do I can run the arcane low level stuff to change partitions and restore data to a newly enlarged one etc. But that's still like the first issue outlined. But if they are less adept, are just dipping their toes, its a laptop with more space constrained. Then what I would say is this. If you switch to BTRFS then you may not solve the problem for this class of users because like LVM or low level partitioning you need nice easy graphical ways to fix the problem. Because you want /home separate for upgrade purposes.
Basically what I'm trying to get across is that there are already solutions for resizing partitions, or volume groups or whatever they are called or whatever BTRFS uses. The problem you identified is that resizing partitions or groups is low level, complex and hard (+scary since resizing the FS often has warnings about make sure you backup first etc). So to me I don't care if its BTRFS or something else. If the goal is to make it easy to resize, then the tooling has to be easy and the ability to find the solution and guides etc.
Metadata Update from @chrismurphy: - Issue untagged with: meeting-request - Issue tagged with: meeting
This is intended to be solved with the adoption of Btrfs for Fedora 33 (tracked as #153).
Metadata Update from @ngompa: - Issue untagged with: meeting
I don't think we need to continue tracking this separately anymore now that we have agreement to proceed on #153.
Metadata Update from @catanzaro: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
What about NILFS? https://nilfs.sourceforge.io/en/pkg_fedora.html says that SELinux needs to be put in permissive mode or disabled otherwise write access will fail.
This was outdated information according to developers when asked about it and they've have since removed that particular line from their website.
Log in to comment on this ticket.