chrismurphy added a new comment to an issue you are following:
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
When hosted in the cloud, isn't it typical to charge for allocated space whether
it's actively used or not?
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.
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.
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