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 docker. > > 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. 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. > > 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. 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 https://pagure.io/atomic-wg/issue/186 _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
