Allow writing sparse disk images

[Michaelhobo]

I'm trying to generate sparse disk images where I write a partition table, but the data I write into the partitions is much smaller than the partition size. Unfortunately, when I tried this with go-diskfs, the WriteContents function in gpt's partiton.go file checks that the written data matches the partition size. Can we relax this check so it checks that written size <= partition size?

[deitch]

I assume you are talking about this here? Where it writes the entire partition from a stream, and thus assumes it should fill it up, else error?

In principle, I don't object to it. I want to make sure we are supporting sparse images correctly, though. Is it valid to have a GPT on a disk (or disk image) where the actual size is less than the size listed in the partition table? How does GPT handle that? What happens if we try to read from that disk in the future?

E.g. part1 is listed in the table as 1024MB, but you only write 512MB. When someone comes to read the partition, it is the entry in the partition table that tells it the size, i.e. where it starts and ends, represented by this struct.

I haven't looked extensively at how gpt handles sparse volumes. If this is a legitimate usage of gpt partitions, and there is a way to handle this correctly according to spec, then we should add it.

[Michaelhobo]

Yes, that's the location I'm referring to. I'm writing a filesystem into the partition, and when mounting the disk, the available space reflects the size of the filesystem, not the partition (e.g. df). I use resize2fs or systemd's growfs option in /etc/fstab to expand the filesystem.
I haven't read the gpt spec, but gpt must have a way to handle contents that don't fill the entire partition, because resizing a partition doesn't resize its contents. So after every resize, there's a state where the size of the content is incorrect.

[deitch]

when mounting the disk, the available space reflects the size of the filesystem, not the partition

Correct, because it is reading filesystem information, not the partition table. Other tools would give you that (like fdisk, etc.)

I haven't read the gpt spec, but gpt must have a way to handle contents that don't fill the entire partition, because resizing a partition doesn't resize its contents.

Usually there are links to the various specs in the directories in the source, but the gpt/ dir doesn't have any, which is surprising.

Do post here what you find in the spec. I am good with removing that constraint check (or at least making sure it is not bigger), if we can be safe with it.

So after every resize, there's a state where the size of the content is incorrect.

I didn't understand this.