Comments on: SquashFS: Not Just for Embedded Systems http://www.linux-mag.com/id/7357/ Open Source, Open Standards Sat, 05 Oct 2013 13:48:18 +0000 hourly 1 http://wordpress.org/?v=3.1 By: Liam http://www.linux-mag.com/id/7357/#comment-944883 Liam Thu, 16 May 2013 15:16:36 +0000 http://www.linux-mag.com/id/7357/#comment-944883 Tiny Core Linux uses a combination of symlinks and mountable sqashfs images in its package management system to provide fast booting and an installation that is always clean. Tiny Core Linux uses a combination of symlinks and mountable sqashfs images in its package management system to provide fast booting and an installation that is always clean.

]]> By: x95tobos http://www.linux-mag.com/id/7357/#comment-6522 x95tobos Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7357/#comment-6522 Nice article, I enjoyed it. As a former Computer Engineering major (in a galaxy far far away, ahemm, Kalamazoo MI, many many years ago..) with no clue about SquashFS, my guess is it is necessary/useful only when the actual "overhead" of the FS structures is significant- you have a lot of small files with really long path names: mp3 players anyone?<br /> <br /> Otherwise why not just use tar gzip or bzip? Lately file managers are really good at using these just as regular directory files- you can browse web pages, play movies/songs, etc. And I am saying this, because why in the world would you want to do compression on sensitive data such as inodes and such, if you do not absolutely have to? In this light, examples 1 and 2 are a bit contrived: you always can mount a partition read-only in the Unix world ! And if the user insists on online data access, the problem is completely different, rather a moral debate: if he is willing to pay for that, he should have that and he should have it with no "strings attached". There is always a tradeoff between redundancy and space, sometimes you want one, sometimes the other. Nice article, I enjoyed it. As a former Computer Engineering major (in a galaxy far far away, ahemm, Kalamazoo MI, many many years ago..) with no clue about SquashFS, my guess is it is necessary/useful only when the actual “overhead” of the FS structures is significant- you have a lot of small files with really long path names: mp3 players anyone?

Otherwise why not just use tar gzip or bzip? Lately file managers are really good at using these just as regular directory files- you can browse web pages, play movies/songs, etc. And I am saying this, because why in the world would you want to do compression on sensitive data such as inodes and such, if you do not absolutely have to? In this light, examples 1 and 2 are a bit contrived: you always can mount a partition read-only in the Unix world ! And if the user insists on online data access, the problem is completely different, rather a moral debate: if he is willing to pay for that, he should have that and he should have it with no “strings attached”. There is always a tradeoff between redundancy and space, sometimes you want one, sometimes the other.

]]> By: sysadmn http://www.linux-mag.com/id/7357/#comment-6523 sysadmn Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7357/#comment-6523 One advantage a compressing fs has over .tgz or .bz2 is memory footprint. It's probably more of a factor in embeded systems. Letting the fs driver manage the data means that all consumers (file managers, mp3 clients, etc) share the cached, uncompressed data and metadata. One advantage a compressing fs has over .tgz or .bz2 is memory footprint. It’s probably more of a factor in embeded systems. Letting the fs driver manage the data means that all consumers (file managers, mp3 clients, etc) share the cached, uncompressed data and metadata.

]]> By: m0n0 http://www.linux-mag.com/id/7357/#comment-6524 m0n0 Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7357/#comment-6524 hmm.. its mistake at write about of:<br /> <br /> SquashFS 2.0 448.58 GB<br /> SquahsFS 2.1 448.58 MB<br /> <br /> It's really 448.58 ¿GB?, must be MB also. hmm.. its mistake at write about of:

SquashFS 2.0 448.58 GB
SquahsFS 2.1 448.58 MB

It’s really 448.58 ¿GB?, must be MB also.

]]> By: leepatrick http://www.linux-mag.com/id/7357/#comment-6525 leepatrick Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7357/#comment-6525 It's also a good FS for SSD since it can save space for relatively small size SSD and it's readonly. For the writing, create the unionfs in ramdisk and write the update back to SSD periodically to reduce write cycles. It’s also a good FS for SSD since it can save space for relatively small size SSD and it’s readonly. For the writing, create the unionfs in ramdisk and write the update back to SSD periodically to reduce write cycles.

]]> By: dwolsten http://www.linux-mag.com/id/7357/#comment-6526 dwolsten Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7357/#comment-6526 It's a good thing they released SquashFS v2.1, as 2.0 obviously had very poor performance, turning 1.3GB of uncompressed data into a whopping 448GB! Luckily, v2.1 achieves a 1000-fold improvement over this figure. It’s a good thing they released SquashFS v2.1, as 2.0 obviously had very poor performance, turning 1.3GB of uncompressed data into a whopping 448GB! Luckily, v2.1 achieves a 1000-fold improvement over this figure.

]]> By: vonchilliman http://www.linux-mag.com/id/7357/#comment-6527 vonchilliman Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7357/#comment-6527 Puppy Linux use SquashFS and UnionFS to incredibly good effect. Puppy Linux use SquashFS and UnionFS to incredibly good effect.

]]> By: rexterd http://www.linux-mag.com/id/7357/#comment-6528 rexterd Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7357/#comment-6528 SquashFS is in most of every distro ubuntu,slax,puppylinux,slitaz etc. Puppylinux and slax uses the layered filesystem unionfs or aufs. Layered filesystems + squashfs combined with lzma compression will make system secured because of a read only squashfs, a layered system where we can easily add and delete branches and compression that will save as memory/storage space. SquashFS is in most of every distro ubuntu,slax,puppylinux,slitaz etc. Puppylinux and slax uses the layered filesystem unionfs or aufs. Layered filesystems + squashfs combined with lzma compression will make system secured because of a read only squashfs, a layered system where we can easily add and delete branches and compression that will save as memory/storage space.

]]> By: laytonjb http://www.linux-mag.com/id/7357/#comment-6529 laytonjb Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7357/#comment-6529 Well the first two examples are contrived but the point is that I can mount any combination of directories or files read-only without having to mount the entire partition as read-only. There are some advantages in this. The one I think is interesting is to run a cron job periodically that scans a user's directory for files that have not been accessed on months. Then you move them to an "ARCHIVE" subdirectory in their account leaving symlinks behind so the user retains the directory structure. Then you use SquashFS on the ARCHIVE directory and remount it for the user. With the symlinks the user finds the files where they expect but you also save some space.<br /> <br /> You have a couple of choices on mounting the SquashFS image as well. You can mount it read-only so that if the user wants to actually edit the data, they will have to copy the data to a new directory to work on it. While this uses more space, it also keeps a copy of the data (which hasn't been used in a while) in case the user screws something up (I'm quite good at that).<br /> <br /> The other option is to use a union mount with the SquashFS image so the user can "change" the data. But the changes are written to the r/w part of the union so you still retain a copy of the data :)<br /> <br /> The second option is the most transparent from a user perspective, but I kind of like the first approach (partly because it's a little bit easier :) ).<br /> <br /> Kind of cool isn't it? I really like this idea and I'm getting ready to hack up some scripts to do this (both options). Just need to get the editor off my back for a week or so :)<br /> <br /> BTW - thanks for the comments and compliments. Glad it helped.<br /> <br /> Jeff Well the first two examples are contrived but the point is that I can mount any combination of directories or files read-only without having to mount the entire partition as read-only. There are some advantages in this. The one I think is interesting is to run a cron job periodically that scans a user’s directory for files that have not been accessed on months. Then you move them to an “ARCHIVE” subdirectory in their account leaving symlinks behind so the user retains the directory structure. Then you use SquashFS on the ARCHIVE directory and remount it for the user. With the symlinks the user finds the files where they expect but you also save some space.

You have a couple of choices on mounting the SquashFS image as well. You can mount it read-only so that if the user wants to actually edit the data, they will have to copy the data to a new directory to work on it. While this uses more space, it also keeps a copy of the data (which hasn’t been used in a while) in case the user screws something up (I’m quite good at that).

The other option is to use a union mount with the SquashFS image so the user can “change” the data. But the changes are written to the r/w part of the union so you still retain a copy of the data :)

The second option is the most transparent from a user perspective, but I kind of like the first approach (partly because it’s a little bit easier :) ).

Kind of cool isn’t it? I really like this idea and I’m getting ready to hack up some scripts to do this (both options). Just need to get the editor off my back for a week or so :)

BTW – thanks for the comments and compliments. Glad it helped.

Jeff

]]> By: laytonjb http://www.linux-mag.com/id/7357/#comment-6530 laytonjb Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7357/#comment-6530 LOL!!! I'm sorry I missed that. But you are correct - it's MB instead of GB.<br /> <br /> Thanks!<br /> <br /> Jeff LOL!!! I’m sorry I missed that. But you are correct – it’s MB instead of GB.

Thanks!

Jeff

]]> By: laytonjb http://www.linux-mag.com/id/7357/#comment-6531 laytonjb Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7357/#comment-6531 Cool idea. I never thought about using a ramdisk and write back to the SSD. How would you do the writeback part? There were some patches floating around from Daniel Phillips called Ramback that did this. I want to test these patches at some point - pretty cool idea.<br /> <br /> Thanks!<br /> <br /> Jeff Cool idea. I never thought about using a ramdisk and write back to the SSD. How would you do the writeback part? There were some patches floating around from Daniel Phillips called Ramback that did this. I want to test these patches at some point – pretty cool idea.

Thanks!

Jeff

]]> By: laytonjb http://www.linux-mag.com/id/7357/#comment-6532 laytonjb Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7357/#comment-6532 Cool idea! I didn't think about using a ramdisk and writing back to the SSD. Talk about really fast write performance!<br /> <br /> How would you do the write back?<br /> <br /> One thing I want to try is a set of patches from Daniel Phillips called Ramback. They do exactly what you say - write back from a ramdisk to device such as spinning disk, usb, or SSD. I just need to find some time to actually test it :)<br /> <br /> Thanks!<br /> <br /> Jeff Cool idea! I didn’t think about using a ramdisk and writing back to the SSD. Talk about really fast write performance!

How would you do the write back?

One thing I want to try is a set of patches from Daniel Phillips called Ramback. They do exactly what you say – write back from a ramdisk to device such as spinning disk, usb, or SSD. I just need to find some time to actually test it :)

Thanks!

Jeff

]]> By: laytonjb http://www.linux-mag.com/id/7357/#comment-6533 laytonjb Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7357/#comment-6533 LOL Mea Cupla. I screwed up the measurement. It should have been MB instead of GB. LOL Mea Cupla. I screwed up the measurement. It should have been MB instead of GB.

]]> By: laytonjb http://www.linux-mag.com/id/7357/#comment-6534 laytonjb Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7357/#comment-6534 Good observations. Thanks!<br /> <br /> Jeff Good observations. Thanks!

Jeff

]]>