Can someone please explain to me why we can't just use a compressed tarball as a filesystem? especially if its read only? I'm sure this could be done. then we would not need any special tools to create it because the tools already exist and if we don't have drivers we could always use the standard tools to decompress it. Or would this make it to slow?
The big problem with tarballs specifically is that they're inherently not random-access (tar stands for Tape ARchive, remember?). In other words, to hit a file 50% of the way through the tarball, you have to read 50% of the tarball first, which makes for ridiculously lousy performance when files (and blocks thereof) are randomly accessed.
ZIP and other archival formats don't have this problem, but may have other problems with regard to accessing an arbitrary page within the a file. Or there are problems reading metadata without undue problems. Or their method of metadata storage doesn't behave in a way that's terribly VFS friendly, or isn't convenient to get to.
The closest thing to this that we can get is the initramfs and zlib-compressed initrd mechanisms in Linux. Or specialty filesystems like cramfs and squashfs :-).
Hope that answers your question.
Whoa! I see the OP had to wait a year for a reply. Anyway, I use squashfs for backup and it's vastly faster than a compressed archive. Loopback mounting a squashfs and doing a copy takes a few seconds, extracting from a bz2-compressed archive takes tens of minutes. Squashfs wins hands down for speed and convenience.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.