On Mon, Jul 3, 2017 at 2:57 PM, Owen Taylor <otaylor@xxxxxxxxxx> wrote: > I don't have any problem with switching to XFS or getting rid of the /home split. The former should be pretty invisible to users, and split home is more of a trap for users than a help. > > But switching to leaving most of the disk unpartitioned seems wrong. With the move to overlay2 for Docker storage, everything you want to do with disk space is inside / - the OS image, your overlay RMs, your docker storage, your home directory. Yes, early adopters of the Atomic Workstation can deal, but long term, we don't want Atomic Workstation to be for the adventurous - we want it to just work. > > Yes, it's easier to grow partitions then shrink them, but I don't think that can excuse leaving users out of the box with a less-than-useful partitioning setup. Short version: I'd say ideal scenario for Workstation-ostree is two partitions: one big XFS volume, and one appropriately sized swap. /boot and /home are directories. But due to an obscure bug [1] this practically means ext4 /boot, XFS for / and /home, and swap; or three partitions. I'd leave LVM out of it because it doesn't really bring anything to the table, but whatever. Long version: Unpartitioned space The way this is done now for Server and Atomic Host makes sense for those use cases. It doesn't make sense for Workstation-ostree. Right now Workstation and Workstation-ostree make root fs 50G, and the rest to /home. That needs revisiting for Workstation or Workstation-ostree, it's just more necessary for Workstation-ostree because platform libraries and flatpaks are bigger than traditional counterparts. Partitions v quotas It's better to use quotas as a limiter, rather than carving things up with multiple partitions (or LVs). Quotas achieve the same goal, but can be changed anytime and not having to worry if the user is going to get wedged into an overfull root fs or home with wasted space on the other. Of course the UIs for each filesystem's quota management are children of satan, but that's a separate convo. /home as separate partition I'm skeptical that ostree installations are less fragile than conventional installs, and obviate separate /home file systems, until Joe User is doing weird and crazy shiat with it. Anaconda enforces a reformat for ext4 and XFS root fs. So if /home is a directory, and a reinstall becomes necessary, it means /home isn't salvageable, it'll have to be restored from backups. Anaconda exempts reformat on Btrfs, instead enforcing the creation of a new subvolume for the root filesystem. Also separate root and home come in handy on Btrfs for snapshotting them separately, and using btrfs send/receive (directly or with btrbk) for home only backup and restore. Shrinking Btrfs has online only, atomic grow and shrink, and uses the same allocation code path for normal reads/writes and balancing, i.e. it's highly exercised code and integral to its design. XFS can't shrink, and ext4 only has offline shrink and while ostensibly safe (or else it's a big bug) it comes with its own risks and inefficiencies in the resulting layout. [1] Due to a combination of long delayed allocation on XFS flushing journal contents to fs metadata, and Plymouth making itself kill exempt, and systemd being unable to remount-ro, or umount the volume; when /boot is a dir on rootfs it's possible for bootloader configuration file changes to only hit the journal and not file system metadata at reboot time. And the bootloaders do not know how to read a dirty journal, so they don't see the updated bootloader file at all, it's missing, so reboot from updates can fail entirely. If you merely boot some other installation or live media and mount this root fs, the kernel reads the dirty journal and flushes its contents to fs metadata, and now everything is fine and the system will boot normally, xfs_repair isn't even needed. Merely a mount and umount. https://bugzilla.redhat.com/show_bug.cgi?id=1227736 Technically all file systems are susceptible to this problem when /boot is a directory and thus remount-ro fails and umount doesn't happen. But only XFS seems to manifest with a problem. ext4 and Btrfs must just flush to disk faster (or something). -- Chris Murphy _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
