Douglas McClendon wrote:
patch#1: add --container-size flag
Using this flag, one can cause the os.img that sits in the squashfs.img,
to be a larger sparse file than the filesystem contained in it. By
default, the old behavior happens. One somewhat unrealistic, but real
justification for this, would be booting a livecd on a system with 16G
of ram. Without this flag, you would be limited to only writing 2G of
data (given the existing f7-livecd-i686 choice of a 4G
uncompressed-size, and about 2.1G of data). With this flag and a
container of say 1T or 100G, there would be no negative consequences,
but the livecd user would be able to online resize2fs their root
filesystem upward if they liked.
> The more realistic usefulness comes if through a persistence
> implementation, the overlay file is not a 512M file stored in tmpfs, but
> an 8G file stored on an ipod. Everything mentioned above applies.
>
Ok, so there is a negative consequence of a large container. As I alluded to
before, mksquashfs apparently does not give any special consideration to sparse
files. Naturally it can compress a file containing huge blocks of 0s pretty
well, but it still appears to be going to an aweful lot of work to do that.
Short of adding more intelligent handling of sparse files to squashfs
(feasible?), another alternative which satisfies the above resizing scenarios
would be this-
Instead of having a larger container, at runtime before the resize, reload the
device mapper table for live-rw. Instead of the os.img loop device being the
base of the snapshot device, create a new device which is a dm linear addition
of os.img and a dm-zero device. This will add a penalty for the extra dm-layer,
but given that this use-case is pretty obscure, it should be sufficient.
Given this line of reasoning, I can no longer think of any need for the
--container-size patch. New patch coming soon, with the other changes as well.
-dmc
--
Fedora-livecd-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
