public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Phillip Lougher <phillip@lougher.demon.co.uk>
To: Dave Jones <davej@redhat.com>,
	Phillip Lougher <phillip@lougher.demon.co.uk>,
	maximilian attems <max@stro.at>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [ANN] Squashfs 3.3 released
Date: Wed, 21 Nov 2007 14:02:43 +0000	[thread overview]
Message-ID: <47443A83.2020607@lougher.demon.co.uk> (raw)
In-Reply-To: <20071120235048.GA15764@redhat.com>

Dave Jones wrote:

> 
> The biggest problem we've seen with it (asides from having to rediff
> it every time we rebase when there isn't a newer upstream)

Yes, this is mainly my fault.  There was a gap of 10 months between the 
3.2 release in January this year, and the latest in November. With the 
rate of new kernel releases this wasn't really acceptable because the 
January release was stuck with a patch for kernels no newer than 2.6.20. 
I received numerous complaints about it.

Some of you may be aware that I started work at Canonical, and this left 
almost no spare-time to work on Squashfs for 9 months.

>is complaints
> along the lines of "my Fedora 7 kernel can't unpack squashfs images
> from Fedora 5"
> (s/Fedora 5/other random older distros/ )
>

Squashfs has backwards compatibility with older versions, and it should 
mount all older versions back to 2.0 (released May 2004). Unfortunately 
RedHat grabbed a CVS version of Squashfs just before the 3.0 release. 
This was development code, and release testing showed it
had a bug where it couldn't mount older versions. It was fixed for
release.

> If the format is now stable however, it would be great to get it upstream.
> 

The move from the 2.0 format to the later 3.0 format was mainly forced 
by the demands of the Linux kernel mailing list when I first submitted 
it early 2005.  There was no other way to incorporate demands for larger 
than 4GB filesystems, and provide support for "." and ".." in readdir 
without modifying the filesystem format.

Unfortunately the move to fixed little endian filesystem will involve 
another filesystem layout change.  The current filesystem layout still 
uses packed bitfield structures, and it is impossible to swap these 
using the standard kernel swap macros.  Removal of my routines that can 
properly swap packed bitfield structures is another change demanded by 
the Linux kernel mailing list.

Once the little endian work has been done, and hopefully once it is in 
the kernel, I don't anticipate any further layout changes.

Phillip


  reply	other threads:[~2007-11-21 14:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-05 11:13 [ANN] Squashfs 3.3 released Phillip Lougher
2007-11-05 11:56 ` maximilian attems
2007-11-07 16:32   ` Phillip Lougher
2007-11-20 23:50     ` Dave Jones
2007-11-21 14:02       ` Phillip Lougher [this message]
2007-11-21 14:48         ` Christoph Hellwig
2007-11-21 15:00           ` Phillip Lougher
2007-11-05 23:19 ` Michael Tokarev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47443A83.2020607@lougher.demon.co.uk \
    --to=phillip@lougher.demon.co.uk \
    --cc=davej@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=max@stro.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox