Drew Scott Daniels wrote:
This falls into the area of block allocation/placement strategy in filesystems design. Most filesystems place blocks on disk to minimise seek time or to minimise fragmentation when running with the 'typical' filesystem workload. I'm not aware of any fs that places blocks to maximise block compression ratio when compressing the entire filesystem as a whole - though that would make sense for an initrd.The order of the files in the initrd file can make a difference if the run length or context of the compressor can span multiple files (large block sizes). I don't know how one could change the order of files in an initrd file, but I suspect it's like tar, just pass them in a different order.
A general purpose filesystem like ext2 would probably scatter files around the filesystem partition in clusters - each cluster will probably contain files from the same directory or directory tree - this helps to reduce fragmentation, and works on the assumption that files in the same directory will be accessed together.
Romfs and squashfs compact the filesystem, and write the files to disk in the order that the source directory is returned by readdir. Cramfs orders the entries in each directory in alphabetical order, as this potentially speeds up directory lookup. Because directories and the inode table are the same thing in cramfs, this means the inodes in each directory will be in alphabetical order, and so the file data is likely to be written likewise. Of course for cramfs and squashfs this is not much of an issue because they're already compressed.
The order of files would make no difference if files are compressed independently like squashfs does.
You're right.
I'd like to get squashfs accepted as part of the Debian Linux kernel, though I daresay it's completely out of my control.Phillip Lougher: I'm also not subscribed to debian-boot thus I can't get the threading right, but you did. I read the mailing list at http://lists.debian.org/debian-boot and several others on lists.debian.org. Would you be willing to try to get squashfs to be made part of the standard Debian Linux kernel? I'm not sure how, or what the reaction would be.
That would be good - if anyone else reads this who is involved in this process, then i'm happy to help.I've submitted a request for packaging which you can see at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179672 It's likely that the Debian Linux kernel maintainers would not include squashfs, but would suggest that it be made a patch package. If the boot system team finds it useful enough then maybe that would be enough to have squashfs include in the Debian Linux kernel.
Phillip
Drew Daniels
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]