-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docker storage limited to 2TB by sfdisk #114
Comments
If we defaulted to --force, would this cause issues? IE other badly confined systems errors being ignored? |
I have no idea what issues will be caused if we use --force. I am wondering should we switch to "parted" instead of sfdisk or use a different type of partition table or something else which allows partitions bigger than 2TB. |
So this seems to come from MBR as there maximum partition size can be 2TB. (for 512 byte sector). Should we consider using GPT. I am not sure if there are any issues with usage of GPT. |
--force seems to have me hitting this:
The partition, pv, and vg look OK, but the lv never shows up and so it sits there waiting until it times out (60 seconds). |
I can't think of a reason not to use GPT. Related to that, one thing that might be interesting is to allocate a GUID in https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ - basically "if the GUID is X, automatically format it as a PV and add it to the VG backing |
@cgwalters Why do we need to partition the disk at all? Why can't we add it directly to volume group. |
As for why we use partitions at all...I suspect it was done for the cloud case where we have one disk that gets magically expanded. I also can't think of a reason not to skip partitions for raw disks. |
Actually even with raw disks, we might add it to root volume group (if VG= was not specified) and over next reboot we might have to grow that partition using growpart. Right now we are assuming that every pv in root volume group is partitioned and I guess that's the reason we are partitioning disks before we add them to volume group. |
"raw" but non-virtual disks will never grow right? I am not sure we need to support a scenario where secondary virtual disks are magically grown. A virt user can just as easily add a new disk. It is however critically important to support adding partitions inside the root (first) disk for the IaaS case on first boot. |
I tried to use docker-storage-setup on a disk that was larger than 2TB:
It failed to start and threw an error that comes from the sfdisk utility used to create partitions.
As suggested in the error, I added --force to /usr/bin/docker-storage-setup:
And then it was able to create the partition:
The text was updated successfully, but these errors were encountered: