vgoyal added a new comment to an issue you are following:
When hosted in the cloud, isn't it typical to charge for
allocated space whether it's actively used or not?
Not sure, what this has to do with how we partition the storage between rootfs and
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.
I think server variant also adds all space to a VG and then carves out a LV for rootfs and
leaves rest of the space free in VG. Now docker-storage-setup can use this space for
image/container storage. For now devicemapper makes use of it and going forward by default
it will be used for overlay2.
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.
Asking users to either grow existing disk or add more disks in VG to make space for
devicemapper might not always be feasible. For example if somebody gives me a VM to work
with and I have no control on management of that VM and I am supposed to work with
resources provided in that VM. I think we need to provide option of being able to go back
to devicemapper without requiring to add more disk space to VM.
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.
So this is image generation part? So we will generate and ship two kind of images and
users will download one of these based on the default storage driver they want to use?
To reply, visit the link below or just reply to this email