On 05/22/2013 05:23 PM, Samuel Sieb wrote: > On 05/22/2013 01:45 PM, John Reiser wrote: >> On 05/22/2013 01:24 PM, drago01 wrote: >>> Which means you'd be better off with file system level compression. >> >> Yes, if you have administrator privileges and strategic planning, >> and if you can tolerate a read-only fs (or your fs can handle overwrites), >> then compression of the filesystem itself often saves more space. >> (Sometimes UPX still wins because of the 128KiB window in squashfs; >> the UPX window is often larger, and sometimes infinite.) >> > Since the context here was Live images, wouldn't it be a good idea to use a > filesystem that allows compression? The image is going to be read-only > anyway. It would allow more content and probably faster loading.
"Live images" is *some* of the context. Live images today are ext4 inside squashfs compressed with the internal equivalent of "xz -9" using 128KiB fixed-size input blocks. UPX sometimes produces tighter compression because its --lzma uses a trailing window instead of a fixed-size block, and the default window is larger than 128KiB, and can be the whole file. UPX must decompress the whole program at execve(), and cannot share RAM, either among simultaneous processes, or demand-paged between RAM and the filesystem. Thus UPX tends to have larger indirect space overhead at runtime, although from the viewpoint of the process itself the memory image is identical. Depending on how much a Live image "re-"pages from the compressed blocks, it will take more CPU because UPX decompresses only once (and requires swap space if memory becomes that tight.) Current Live images (ext4, squashfs, xz -9, 128KiB blocks) are a good choice for several reasons. UPX offers different properties which may be more valuable to some people in some cases. -- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
