Am 01.06.2011 04:59, schrieb Gerardo Exequiel Pozzi: >>>>> Yes, but there are at least one downside: since is not an union-fs, >>>>> there is no concept of layers. We are currently using "overlay" thats >>>>> overlap some files on the layer "root-image". >>>> This is not problematic. >> OK. >> >> Maybe if we want to maintain an original root-image we can do this >> using a snapshot with all changes. >> This make the build process a bit more complex.
I don't think we should. Just copy the overlay over the root image and get on with it. >>>> However: With an ext4 loopback inside the squashfs image you loose one >>>> squashfs feature: metadata compression. I don't know how bad that will >>>> be though. >> Yes. But the difference is small. >> >> # du -sh /tmp/archbase* >> 398M /tmp/archbase (1) >> 456M /tmp/archbase.ext4 (2) >> 148M /tmp/archbase.ext4.sfs (3) >> 145M /tmp/archbase.sfs (4) That seems fine. >>> # echo "0 $(blockdev --getsize /dev/loop0) snapshot /dev/loop0 >>> /dev/loop1 N 8" | dmsetup create snapshottest >>> (8 ist the "chunk size" here, which is now 8 sectors. no idea what a >>> good value might be) >> I think that 8 is the optimal 8*512 = 4096, that is the size of block >> of ext4 image and the block size of loopback device. 4KB was my thought as well. Let's do 8 then. >>> This seems fairly easy to implement on the mounting side. Creation of >>> the ext4 should be pretty straightforward, too. >> There are others downside, only notable when you work inside the "live >> medium": Create/modify a file and delete it, the space is not released >> at "physical level" (on tmpfs), like now where new/modify files are >> written directly on tmpfs. The downsides of aufs2 or another unionfs implementation are worse: They are all unstable and unmaintained. >> So go ahead? Yes, sounds nice. >> What do you think: support of both modes if aufs come again(*) or >> change all code and simply keep this mode (if all people are happy) Depends on how difficult this will be. I think tpowa will be happy to never have to maintain aufs again. Our image would work with a kernel that is completely vanilla, this makes me happy as well. >> Thanks for your feedback. >> >> (*) or something official union layer in Linux 100.0 :P. I was still hoping for union-mounts, but they are not being developed anymore. > before I start, I am thinking in some others areas: > > * core-iso: I think we need (If I don't remember bad) write access to > /src (where core pkgs is mounted), implies we need to mount core-pkgs > indirectly via dm-dev w/snapshot like root-img. Why would we need that? I don't like the idea of doing this snapshot stuff with more than one device. We should just mount the packages as a mount point, no hacks. > * dual images (depending on profile [-T] ) > ** core-any-pkgs.sqfs, will dissapear (no more union-fs trick), yes this > can be done via symlinks... (about 16MB saved) Symlinks it is - do it like we do on the mirrors. > ** usr-share.sqfs, should be done in the same way that root-image, > otherwise update is not posible. > ** lib-modules.sqfs, idem usr-share and root-image. > * net-iso, no issues. So, we'll need 3 of those snapshot systems for the split ISO? I don't like it, but if we can really save space, I suppose it's a good thing. We could also have one big ext4 with everything inside it, in subdirectories, then bind-mount. This is probably easier. For less overhead, we should also create the ext4 without journal. We don't need it as everything is in RAM anyway. > mkarchiso can take a optional parameter when creating the "fs.img" thats > add some percent to be "free space". """ USED=$(du -sh directory) .... > dd ..... of="fs.img" seek=$((USED*PERCENT_FREE)) """ You can also vary the size of the snapshot file (it can be smaller than the fs).
signature.asc
Description: OpenPGP digital signature
