public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@suse.cz>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: Paulo Marques <pmarques@grupopie.com>,
	Andrew Morton <akpm@osdl.org>,
	greg@kroah.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][2/2] SquashFS
Date: Mon, 21 Mar 2005 20:00:44 +0100	[thread overview]
Message-ID: <20050321190044.GD1390@elf.ucw.cz> (raw)
In-Reply-To: <423EEEC2.9060102@lougher.demon.co.uk>

Hi!

> >>>Also, this filesystem seems to do the same thing as cramfs.  We'd need to
> >>>understand in some detail what advantages squashfs has over cramfs to
> >>>justify merging it.  Again, that is something which is appropriate to the
> >>>changelog for patch 1/1.
> >>
> >>Well, probably Phillip can answer this better than me, but the main 
> >>differences that affect end users (and that is why we are using SquashFS 
> >>right now) are:
> >>                         CRAMFS          SquashFS
> >>
> >>Max File Size               16Mb               4Gb
> >>Max Filesystem Size        256Mb              4Gb?
> >
> >
> >So we are replacing severely-limited cramfs with also-limited
> >squashfs... 
> 
> I think that's rather unfair, Squashfs is significantly better than 
> cramfs.  The main aim of Squashfs has been to achieve the best 

Yes, it *is* rather unfair. Sorry about that. But having 2 different
limited compressed filesystems in kernel does not seem good to me.

> compression (using zlib of course) of any filesystem under Linux - which 
> it does, while also being the fastest.  Moving beyond the 4Gb limit has 
> been a goal, but it has been a secondary goal.  For most applications 
> 4Gb compressed (this equates to 8Gb or more of uncompressed data in most 
> usual cases) is ok.

Okay, having limit on 4GB compressed is slightly better (and should
mean that SquashFS would actually be usefull to me).

> >For live DVDs etc 4Gb filesystem size limit will hurt for
> >sure, and 4Gb file size limit will hurt, too. Can those be fixed?
> 
> Almost everything can be fixed given enough time and money. 
> Unfortunately for Squashfs, I don't have much of either.  I'm not paid 
> to work on Squashfs and so it has to be done in my free time. I'm hoping 
> to get greater than 4Gb support this year, it all depends on how much 
> free time I get.

Well, out-of-tree maintainenance takes lot of time, too, so by keeping
limited code out-of-kernel we provide quite good incentive to make
those limits go away.

Perhaps squashfs is good enough improvement over cramfs... But I'd
like those 4Gb limits to go away.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

  reply	other threads:[~2005-03-21 19:01 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-14 16:30 [PATCH][2/2] SquashFS Phillip Lougher
2005-03-15  1:06 ` Andrew Morton
2005-03-15  1:14   ` Phillip Lougher
2005-03-15  3:01     ` Andrew Morton
2005-03-15 17:16       ` Phillip Lougher
2005-03-15 18:21       ` Paulo Marques
2005-03-21 10:14         ` Pavel Machek
2005-03-21 15:56           ` Phillip Lougher
2005-03-21 19:00             ` Pavel Machek [this message]
2005-03-21 18:03               ` Phillip Lougher
2005-03-21 22:49                 ` Pavel Machek
2005-03-22  2:41                   ` Josh Boyer
2005-03-22  2:58                     ` David Lang
2005-03-22  3:04                     ` Andrew Morton
2005-03-22  2:59                       ` Phillip Lougher
2005-03-22  5:32                         ` Paul Jackson
2005-03-22  3:34                   ` Phillip Lougher
2005-03-22  5:37                     ` Stefan Smietanowski
2005-03-21 22:32               ` Mws
2005-03-21 22:44                 ` Pavel Machek
2005-03-21 22:54                   ` Mws
2005-03-22  3:36                   ` Phillip Lougher
2005-03-22  7:19                 ` Stefan Smietanowski
2005-03-22  5:20               ` Willy Tarreau
2005-03-21 18:08           ` Mws
2005-03-21 18:54             ` Pavel Machek
2005-03-21 22:23               ` Mws
2005-03-21 22:31                 ` Pavel Machek
2005-03-21 22:47                   ` Mws
2005-03-21 22:56                     ` Pavel Machek
2005-03-15  3:12 ` Matt Mackall
2005-03-15 23:25   ` Phillip Lougher
2005-03-16  0:57     ` Andrew Morton
2005-03-16  1:04     ` Matt Mackall
2005-03-16  4:19       ` Matt Mackall
2005-03-15  5:38 ` Greg KH

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=20050321190044.GD1390@elf.ucw.cz \
    --to=pavel@suse.cz \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillip@lougher.demon.co.uk \
    --cc=pmarques@grupopie.com \
    /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