"I'm pleased to announce another release of Squashfs. This is the 22nd release in just over five years. Squashfs 3.3 has lots of nice improvements, both to the filesystem itself (bigger blocks and sparse files), but also to the Squashfs-tools Mksquashfs and Unsquashfs," stated Phillip Lougher about the latest release of the compressed read-only Linux filesystem. He noted that he still needed to fix filesystem endianness, then he was going to focus on getting Squashfs into the mainline kernel. New features found in this latest release include:
"1. Maximum block size has been increased to 1Mbyte, and the default block size has been increased to 128 Kbytes. This improves compression.
"2. Sparse files are now supported. Sparse files are files which have large areas of unallocated data commonly called holes. These files are now detected by Squashfs and stored more efficiently. This improves compression and read performance for sparse files."
From: Phillip Lougher <phillip@...>
Subject: [ANN] Squashfs 3.3 released
Date: Nov 5, 7:13 am 2007
Hi,
I'm pleased to announce another release of Squashfs. This is the 22nd
release in just over five years. Squashfs 3.3 has lots of nice improvements,
both to the filesystem itself (bigger blocks and sparse files), but
also to the Squashfs-tools Mksquashfs and Unsquashfs.
The next stage after this release is to fix the one remaining blocking issue
(filesystem endianness), and then try to get Squashfs mainlined into the
Linux kernel again.
The list of changes from the change-log are as follows:
1. Filesystem improvements:
1.1. Maximum block size has been increased to 1Mbyte, and the
default block size has been increased to 128 Kbytes.
This improves compression.
1.2. Sparse files are now supported. Sparse files are files
which have large areas of unallocated data commonly called
holes. These files are now detected by Squashfs and stored
more efficiently. This improves compression and read
performance for sparse files.
2. Mksquashfs improvements:
2.1. Exclude files have been extended to use wildcard pattern
matching and regular expressions. Support has also been
added for non-anchored excludes, which means it is
now possible to specify excludes which match anywhere
in the filesystem (i.e. leaf files), rather than always
having to specify exclude files starting from the root
directory (anchored excludes).
2.2. Recovery files are now created when appending to existing
Squashfs filesystems. This allows the original filesystem
to be recovered if Mksquashfs aborts unexpectedly
(i.e. power failure).
3. Unsquashfs improvements:
3.1. Multiple extract files can now be specified on the
command line, and the files/directories to be extracted can
now also be given in a file.
3.2. Extract files have been extended to use wildcard pattern
matching and regular expressions.
3.3. Filename printing has been enhanced and Unquashfs can
now display filenames with file attributes
('ls -l' style output).
3.4. A -stat option has been added which displays the filesystem
superblock information.
3.5. Unsquashfs now supports 1.x filesystems.
4. Miscellaneous improvements/bug fixes:
4.1. Squashfs kernel code improved to use SetPageError in
squashfs_readpage() if I/O error occurs.
4.2. Fixed Squashfs kernel code bug preventing file
seeking beyond 2GB.
4.3. Mksquashfs now detects file size changes between
first phase directory scan and second phase filesystem create.
Regards
Phillip Lougher
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: maximilian attems <max@...>
Subject: Re: [ANN] Squashfs 3.3 released
Date: Nov 5, 7:56 am 2007
On Mon, Nov 05, 2007 at 11:13:14AM +0000, Phillip Lougher wrote:
> I'm pleased to announce another release of Squashfs. This is the 22nd
> release in just over five years. Squashfs 3.3 has lots of nice
> improvements,
> both to the filesystem itself (bigger blocks and sparse files), but
> also to the Squashfs-tools Mksquashfs and Unsquashfs.
>
> The next stage after this release is to fix the one remaining blocking issue
> (filesystem endianness), and then try to get Squashfs mainlined into the
> Linux kernel again.
>
that would be very cool!
with my hat as debian kernel maintainer i'd be very relieved to see it
mainlined. i don't know of any major distro that doesn't ship it.
thanks
--
maks
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Phillip Lougher <phillip@...>
Subject: Re: [ANN] Squashfs 3.3 released
Date: Nov 7, 12:32 pm 2007
maximilian attems wrote:
> On Mon, Nov 05, 2007 at 11:13:14AM +0000, Phillip Lougher wrote:
>
>> The next stage after this release is to fix the one remaining blocking issue
>> (filesystem endianness), and then try to get Squashfs mainlined into the
>> Linux kernel again.
>>
>
> that would be very cool!
Yes, it would be cool :) Five years is a long time to maintain
something out of tree, especially recently when there's been
so many minor changes to the VFS interface between kernel releases.
> with my hat as debian kernel maintainer i'd be very relieved to see it
> mainlined. i don't know of any major distro that doesn't ship it.
>
I don't know of any major distro that doesn't ship Squashfs either
(except arguably Slackware). Putting my other hat on (one of the
Ubuntu kernel maintainers) I don't think Squashfs has caused
distros that many problems because it is an easy patch to apply
(it doesn't touch that many kernel files), but it is always good
to minimise the differences from the stock kernel.org kernel.
Phillip
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
No one in their right mind would merge this
Nobody in their right mind would blow CPU cycles on this junk. Hard drives cost pennies per gig, and all large media file formats are already compressed, giving the possibility of wasting more cycles for no gain. If the kernel team won't merge ReiserFS they should even touch this thing. I'd rather have compressed ethernet.
This project is perfect for
This project is perfect for live cds, and embedded applications.
you seem to know a lot about filesystems...
You seem to know a lot about filesystems, but you surely missed one simple fact that it is a read-only fs, used mainly for live CD/DVDs, but also on flash in embedded devices.
And just where...
And just where is that pennies per gig HD in your portable music/media player? In your wireless router? In your cell phone? Do you really want spinning rust in these applications?
--
Program Intellivision and play Space Patrol!
The point seems to be
The point seems to be installation packages. I think it would be nice to blow CPU while saving IO (which is *much* slower).
Exactly my thought. Although
Exactly my thought. Although I don't think I will use it, because I would much rather see my data written out in it's 'native' 'raw' format, but that would have definitly been my reason to choose it.
the kernel team won't merge
Ironically ReiserFS was merged in January 2001, 10 months before ext3.
Nitpicking aside, the merge of reiser4 has absolutely nothing to do with its technical goals or merits; the code simply never got into good enough shape to have it merged.
But you have to admit that
But you have to admit that ReiserFS was merged so quickly because the kernel developers felt like they needed a journaling filesystem as quickly as possible. I remember Alan Cox pointing out that this was a mistake after all (ReiserFS kinda bit-rotted, for example the ext3 devs purged all lock_kernel calls during the 2.5 development phase, while the namesys guys didn't. That's one of the reasons SuSe switched to ext3 lately.)
ReiserFS4 not "good enough"
After 4 years of flawless performance on one of my machines one wonders what "good enough shape" means for code on the kernel team. For me those words are code for "not invented here". I sometimes wonder why the Linux kernel is as successful as it is given the extent of cronyism in the development team.
Good enough != works for
Good enough != works for me.
Besides, code quality is more than performance, it's also maintainability, cleanliness (two sides of the same thing), and (code) interface.
So, if it works for you it
So, if it works for you it will work for everybody???
Lets close all bugs with WORKSFORME, and say that the code is Stable...
Lucky of us, that you are not responsible for decisions like this...
Re: ReiserFS4 not "good enough"
You must have been luck then as personally I've only ever encountered filesystem corruption on 2 systems (out of 000's that I have worked on) and both of those systems used Reiser4 as their filesystem, so I'm glad this never made it into the kernel.
You seem to have no clue at all.
You seem to have no clue at all.
SquashFS in fact is ONE of the (admittedly "smaller") killer features for a community.
SLAX used it for a long long time (and still does so, I think... they only exchanged
unionfs with aufs).
There are myriads of other projects that use it.
If you attack the "quality of the code" by stating the WHOLE PROJECT sucks, after 5 years,
I do NOT BELIEVE you a single second. I think you dont want SquashFS to succeed instead, and
thus I conclude you are T-R-O-L-L-I-N-G.
And trolls must die.
Have a nice time dying!
what about lzma ?
One even better information would be to get squashfs+lzma both mainlined (http://www.squashfs-lzma.org/) !
The gain in terms of space with lzma compression is really impressive, see the stats on their site
good luck to you developpers, thanks and go on !
karm
Yes, please
Please include lzma in the squashfs integration. It blows away every compression scheme out their for compression size and uncompression speed. I don't think compression speed is a big concern for initial firmware creation. ;)
Is lzma patent-free?
Is lzma patent-free?
Yes, I would think so; 7-zip
Yes, I would think so; 7-zip guys have been using it for years and I haven't heard any allegations of patent infringement.