![]() * Running a squashfs using compression xz, blocksize 16384 * Running a squashfs using compression xz, blocksize 8192 * Running a squashfs using compression xz, blocksize 4096 * Running a squashfs using compression lzo, blocksize 16384 * Running a squashfs using compression lzo, blocksize 8192 * Running a squashfs using compression lzo, blocksize 4096 * Running a squashfs using compression gzip, blocksize 16384 * Running a squashfs using compression gzip, blocksize 8192 * Running a squashfs using compression gzip, blocksize 4096 You should see output that look something like this, with all the resulting data in the. I keep all the results for inspection, but I’ll probably adapt/fix the script to be more friendly to disk space usage some time. With the default values in that file, you’ll end up with 18 squashfs images taking up about 18GB of disk space. How to Run ItĬreate a directory and place the filesystem you’d like to test as filesystem.squashfs, then: $ apt-get install squashfs-tools If you don’t have any significant bottleneck (like slow disks, slow CPU, running out of RAM, etc) then your results should more or less correspond in scale to mine for the same image. The results of the squashfs testing script will differ greatly based on the CPU cores, core speed, memory speed and storage speed of the computer you’re running it on, so it shouldn’t come as a surprise if you get different results than I did. I’m testing this on a dual core Core i7 laptop with hyper-threading (so squashfs will use 4 threads) and with 16GB RAM apparently transferring around 21GB/s. mksquashfs is SMP aware and will use all available cores by default. If you have a slow storage, the results of the larger images (with smaller block sizes) may be skewed unfavourably.Īs Bernhard mentioned on his post, testing the speed of your memory can also be useful, especially when testing on different kinds of systems and comparing the results: # dd if=/dev/zero of=/dev/null bs=1M count=100000ġ04857600000 bytes (105 GB) copied, 4.90059 s, 21.4 GB/sĬPU is likely to be your biggest bottleneck by far when compressing. The SSD seems fast enough not to have any significant effect on the tests. I’m compressing the data back to SSD and extracting from there for read speed tests. I’m extracting it to RAM since I want to avoid having disk performance as a significant factor. It’s a complex image that contains a large mix of different kinds of files. ![]() My Testing Environmentįor this post, I will try out my script on the Ubuntu Desktop 14.04.2 LTS squashfs image. So, I put together a quick script that takes a squashfs image, extracts it to tmpfs, and then re-compressing it using it all the specified compression techniques and block sizes… and then uncompressing those same images for their read speeds. I’d rather be able to gather compression ratio/times for a specific image rather than for one that was used for testing purposes once-off. Each squashfs is different and it makes a big difference whether it contains already compressed information or largely uncompressed information like clear text. Even if such a table existed, I probably wouldn’t be satisfied with it. I was surprised to not find a more complete table elsewhere either. Bernhard Wiedemann and the Squashfs LZMA project have posted some results before, and while very useful I want more information (especially compress/uncompress times). I’m not the first person to have done some tests on squashfs performance and reported on it. My Experiment: Test effects of squashfs compression methods and block sizes In most cases the defaults will probably be sufficient, but if you want to find a good balance between performance and space saving, then you’ll need some more insight. It also supports block sizes from 4K up to 1M.Ĭompression technique as well as block size can have major effects on both performance and file size. It supports gzip, lzo and xz(lzma) as compression back-ends. It has plenty of other use cases too but for the purposes of this entry we’ll stick with those use cases in mind. Typically, a system like tmpfs, unionfs or aufs is mounted over this read-only system to make it usable as a root filesystem. Squashfs is a read-only compressed filesystem commonly used on embedded devices, Linux installation media and remote file systems (as is done in LTSP). I like the concept of trying out all kinds of different things and reporting back to the community on how it works. I’ve been meaning to do more of that myself so this is me jumping in and reporting back on something I’ve been poking at this weekend. It reminds me of the Debian Experiments community on Google+. ![]() Last week I discovered The Fan Club’s Experiments page.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |