chrismurphy added a new comment to an issue you are following: `` >vgoyal >IIUC, you are saying that use a thin LV for rootfs to work around xfs shrink issue? People have tried that in the past and there have been talks about that many a times. There are still issues with xfs on top of thin lv and how no space situation is handled etc. Bottom line, we are not there yet. You mean thin pool exhaustion? Right now the atomic host default uses the docker devicemapper driver which is XFS on a dm-thin pool. So I don't understand why one is OK and the other isn't. >So if we can't use rootfs on thin LV and if xfs can't be shrinked, then only way to flip back to devicemapper is don't allow rootfs to use all free space. When hosted in the cloud, isn't it typical to charge for allocated space whether it's actively used or not? >jberkus >If that reason is invalid, we should again consider making "one big partition" the default for Overlay2 installations. Yes. It's the same effort to add more space (partition, LV, raw/qcow2), make it an LVM PV, and add to the VG and then let docker-storage-setup create a docker-pool thin pool from that extra space. >dwalsh >We have tools that allow you to switch back to devicemapper if their is partioning, which is why we want to keep partitioning. If this was easy to switch from no partioning to partitioned, then I would agree with just default to overlay without partitions. My interpretation of jberkus "one big partition" is a rootfs LV that uses all available space in the VG, reserving nothing. But it's still possible to add a PV to that VG and either grow rootfs for continued use of overlay2; or to fallback to devicemapper. I don't interpret it literally to mean dropping LVM. You'd probably want some way of doing online fs resize as an option, and that requires rootfs on LVM or Btrfs, not a plain partition. I think it's a coin toss having this extra space already available in the VG, vs expecting the admin to enlarge the backing storage or add an additional device, which is then added to the VG, which can then grow rootfs (overlay2) or be used as fallback with the Docker devicemapper driver. >dustymabe >I would like to also point out that one other benefit would be to prevent containers from cannibalizing your root partition. Not possible by making /var a separate file system, you'd have to use quotas. Ostree owns /var, it must be a directory on rootfs at present. >I prefer overlay2 and would like to see there be only one option so that we can have less confusion in the future. However, giving users the choice is nice as well. Maybe there is a way to achieve both on startup. You could have two kickstarts: overlay2 and devicemapper, and each kickstart is specified using a GRUB menu entry on the installation media. The devicemapper case uses the existing kickstart and depends on the existing docker-storage-setup "use 40% of VG free space for a dm-thin pool"; the overlay2 kickstart would cause the installer to use all available space for rootfs, leaving no unused space in the VG. `` To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/186 _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
