Nick - 2007-07-21

As well as embedded applications, where the storage medium would likely be low latency (eg Flash), SquashFS is now widely used as a compressed CD-Rom file system, for example, as the filesystem on the Ubuntu Linux live CD.

CD Rom drives give a fair data throughput (around 5Mb/Sec) which uncompressed could equate to 15-20Mb/Sec. Latency, however, is very high, with an average (1/3rd stroke) latency of around 90ms, full stroke around 150ms. Latency is much higher, and therefore a bigger issue for slimline laptop CD-Rom drives.

Clearly, to have good performance on a CD rom drive, it is important to minimise the head travel, and eliminate seeks where possible.

When booting from a CD, files are usually read in almost an un-changing sequence. Just a few differing hardware driver loads will break a sequence which would otherwise be the same on any system.

I suggest it would make sense to sequence files on the media in exactly the same sequence as they are read in a typical boot sequence. Then sequence files in the order the heaviest applications (eg openoffice) will load.

I suggest this could be practically achieved by setting a kernel boot parameter, read by the squashfs driver at load-time. This parameter enables logging of each file read through the driver, writing the output to the specified path.

That same list of output files might be fed into mksquashfs to provide a hint to mksquashfs of an optimal sequence files should appear on the media. Integrating such a function into the squashfs driver and mksquashfs would simplify the process of optimal re-mastering, so that it could be part of a standard mastering process.

It appears someone has tried re-mastering CDs with file sequence optimisation strategies in mind, and has apparently achieved a boot time reduction from 3:44s to 1:40s.

It appears these tests were performed with a hacked version of the squashfs driver, without a view to integrating functionality into the mainstream driver, and relies on external code modules.