WTF? Squash FileSystem?
Has no one yet heard of Squashfs? This is the first post about it on this entire message board! Not only that, I did a google search for squashfs and it didn't even come up with 100 relative matches. We gotta get the word out about Squashfs people! For anyone that doesn't know, squashfs is a "highly compressed, read-only, filesystem" for linux. True, read-only access can't be used for a lot of files, BUT there are a lot of other files that it can be used for! Think about all the files on your linux that haven't changed in the last 6 months. Do any of these ring a bell: /sbin, /bin, /lib, /boot, /root, /usr/bin, /usr/lib, or my favorite /usr/doc? Plus, you can store and mount the squashfs to/from a single file instead of a separate partition! Do you agree with me that this is a great thing? Am I insane? Please respond people!
What is so great about this fs? /usr/doc is usually compressed with gzip anyway. I would hate to have to uncompress files in /bin, /sbin, /lib, /usr/lib, /usr/bin, /usr/sbin to use them all the time. Storage is so cheap now, like $1 per gigabyte that I don't see a reason to use this. This reminds me of doublespace for dos that was a compressed drive. Really didn't find a use for it except if you had like a 20MB hd installed. Also if the filesystem is read-only, how do you write the files to the fs that you want to store on it? I find it would be difficult to apply patches/upgrade software with those directories that you listed read-only. BTW, what compression algorithm does this use?
I don't really see the use for it either. Sure, you don't write to those directories very often, but if you'd want to, it would take much longer. In that case, I prefer not having the overhead of using nested filesystems and compression, especially for mmap'ed files. It's just not worth it.
Hmmm, my distro didn't come with /usr/doc gzip'd. Is that a netscape thing? I heard something about Netscape browsing gzip files in my search for a compressed fs. :)
To answer your questions:
"I would hate to have to uncompress files in /bin, /sbin, /lib, /usr/lib, /usr/bin, /usr/sbin to use them all the time"?
>It's a filesystem. Decompression is done on the fly. :)
"Also if the filesystem is read-only, how do you write the files to the fs that you want to store on it?"
>It comes with a tool called mksquashfs. The following syntax could be used to make a squashfs backup of your entire computer:
./mksquashfs / /tmp/root.sqsh -e proc /tmp/root.sqsh
(The syntax:./mksquashfs source1 source2 ... dest [options] [-e list of exclude dirs/files])
"I find it would be difficult to apply patches/upgrade software with those directories that you listed read-only"
>You're absolutely correct. I do not recommend converting any directory that you write to more often than once every half year. The directories I listed were just a few for example purposes.
"BTW, what compression algorithm does this use?"
>Well... it isn't gzip... :)
Actually, I'm not the creator of it so I'm not completely certain, but from going over the readme several times... I can tell you that it's complex and powerful. Here is a snippet from the readme:
1. Data, inodes and directories are compressed.
2. Squashfs stores full uid/gids (32 bits), and file creation time.
3. Files up to 2^32 bytes are supported. Filesystems can be up to
2^32 bytes. (2^32 ~= 4Gb)
4. Inode and directory data are highly compacted, and packed on byte
boundaries. Each compressed inode is on average 8 bytes in length
(the exact length varies on file type, i.e. regular file, directory,
symbolic link, and block/char device inodes have different sizes).
5. Squashfs can use block sizes up to 32K (the default size is 32K).
Using 32K blocks achieves greater compression ratios than the normal
4K block size.
6. File duplicates are detected and removed.
7. Both big and little endian architectures are supported. Squashfs can
mount filesystems created on different byte order machines.
Lastly, yes I know that harddrive prices have gone down, but there are a few of us that still have our old little harddrives. I'm on a laptop with a 6gb hd. I do have an 100gb external drive, but I'm always moving my laptop so it's a hassle for me to always get out and put back my external. So, I'm trying to make the most of what I've got. ;)
I hope this answers a few of the questions. Tell us what you think.
With today's HDD prices, it's just not worth the CPU overhead for having nested filesystems and decompression on-the-fly. There is also always a chance that you'll patch these dirs. Also, you don't get atime updated, which could be useful for different reasons.
I find it virtually useless for "real" systems. It could have uses, but very few such. A filesystem such as that can only be useful for eg. boot disks, as I see it. There, on the other hand, it might very well be very useful, depending on how much it compresses. If gzip is better, you'd be better off gzipping an initrd, especially since they are rw.
The odds are good that it compresses as well as gzip if not better. There are reports of people fitting 1.8gb of fully operational linux on a cd through the use of squashfs. My only contention is that we might be able to use it for something other than cd's.
I am going to agree this is probably a bad idea. It is trying to solve a problem (storage space) by comprimising a bigger, nastier problem. Namely the bottleneck of response latency. All people complain about is how it takes 30 seconds to start netscape on linux, or how it takes 1 minute or more to boot the computer. This is bad to the point that IBM is looking at invesing millions into magnetic RAM that would drop the boot time of computers from (present day) 8 second boots (at best) to like 1.5 seconds. Also, even GNOME has gotten the message that the user needs "instant satisfaction" by popping up a static image or something as soon as it starts to happen. Take Mozilla, have you seen that new "instant pop-up thing" at the very first second you click the button? To uncompress these files might only add another second to our waiting, but those seconds add up. This would be good on a small server though. To compress the /sbin, /usr/sbin, etc on a wireless router running on a 486 that has 99% of it's used programs loaded into memory anyway, would be great.