Description of problem: Now that we have a lot of usage of Docker and Flathub, our default disk partitioning layout is problematic - having a separate home and a small root means running out of disk much more quickly. This has hit me on every single one of my machines. :( Things are a lot different since we made the decision to have the current default disk layout - we have much more reliable upgrades in addition to a lot of new technology that eats up root disk space. Can we revisit our current default disk layout and consider not having a separate /home?
(In reply to Máirín Duffy from comment #0) > Description of problem: > > Now that we have a lot of usage of Docker and Flathub, our default disk > partitioning layout is problematic - having a separate home and a small root > means running out of disk much more quickly. This has hit me on every single > one of my machines. :( Are the flatpacks system side ? Could the flatpack repository not be stored in the user home directory somewhere ? > > Things are a lot different since we made the decision to have the current > default disk layout - we have much more reliable upgrades in addition to a > lot of new technology that eats up root disk space. > > Can we revisit our current default disk layout and consider not having a > separate /home? There are various issues with not having a separate /home, for example: - user data can exhaust root filesystem space, leading to various serious resulting issues - Anaconda has a long standing policy to always wipe the root filesystem during installation to prevent leftover bits and pieces of the old system interfering with the installation and the resulting system, if home is on the same filesystem it will be wiped as well and can't be easily reused like a separate home filesystem can A possibly more radical solution that keeps (some of) the current guarantees would be to place the root and home filesystems on thin volumes sharing the underlying storage pool. That way space can be efficiently shared between the root and home volumes + some extra features on top (efficient CoW snapshots, possible to create new thin volumes when needed, can use XFS without worrying about shrinking, etc.). Of course there are also various downsides of this configuration, such as: - the notion of free space could be confusing due to over-provisioning and snapshots - it's not clear what should happen if free space is exhausted when over-provisoning is used & if a normal user can react properly to that In any case, this is a call for the Workstation Working group in the end, so adding Mathias Classen and Jirka Eishmann to CC.
(In reply to Martin Kolman from comment #1) > (In reply to Máirín Duffy from comment #0) > > Description of problem: > > > > Now that we have a lot of usage of Docker and Flathub, our default disk > > partitioning layout is problematic - having a separate home and a small root > > means running out of disk much more quickly. This has hit me on every single > > one of my machines. :( About Docker I think when a user is skilled enough to use Docker or other similar container technology then he/she should be skilled enough to do it's own partitioning in that sense. This is of course not true about Flatpak which is created to be easy to use, however I would argue that the situation shouldn't be that different from the old DNF packages. You have to install runtimes for your applications but those runtimes are deduplicated on binary level so it shouldn't be much more than we have now. Although those bundled libraries could make a it bigger... > Are the flatpacks system side ? Could the flatpack repository not be stored > in the user home directory somewhere ? Flatpaks can be installed into home or system wide. User can chose where to install package if he/she has root privileges.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
I'll actively argue against making LVM thin volumes the default for Workstation's average user. I'd push really hard on Btrfs by default first. - The installer disallows over provisioning. Therefore initially, the root and home volumes must have fixed sizes, the total of which can't exceed thinpool size. - That means later on, the user must recognize they're short on free space, and know they can over provision storage, and that in fact the proper action is *not* to shrink home volume first, but to just grow root using blivet-gui or CLI. - Once over provisioned, it's possible to exhaust the pool. All the free space tools in the GUI and commonly used on CLI will lie. In the narrow but still possible case of exhausting the metadata pool, they're probably going to have complete data loss. And it will be so abrupt, a regular user won't be able to distinguish it from hardware failure. This is estoteric knowledge. And it's why Stratis exists. Combining root and home, one big root with /home as a directory on it, is very familiar to most users. It's the way macOS and Windows, and a few common Linux distros are setup. And while I personally find the backup user directory, (re)install, restore user data from backup, super annoying and easily avoided by having a separate home volume, it's not annoying enough that I'd actively argue against it. By the way, the installer has an exception for Btrfs, reformat not required on existing volumes. It only enforces a new subvolume for the new root, existing subvolumes are preserved and can even be assigned mount points, e.g. home on /home.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.