From: Paulo Marques <pmarques@grupopie.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Phillip Lougher <phillip@lougher.demon.co.uk>,
greg@kroah.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][2/2] SquashFS
Date: Tue, 15 Mar 2005 18:21:49 +0000 [thread overview]
Message-ID: <423727BD.7080200@grupopie.com> (raw)
In-Reply-To: <20050314190140.5496221b.akpm@osdl.org>
Andrew Morton wrote:
> [...]
> 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?
UID/GID 8 bits 32 bits
Block Size 4K default 64k
Probably the block size is the most responsible for this, but the
compression ratio achieved by SquashFS is much higher than that achieved
with cramfs.
I just wanted to say one thing on behalf of SquashFS. We've been using
SquashFS in production on a POS system we sell, and we have currently
more than 1200 of these in use. There was never a problem reported that
involved SquashFS.
Although the workload patterns of these systems are probably very
similar (so the quantity doesn't really matter much), it is a real world
test of the filesystem, nevertheless.
--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
next prev parent reply other threads:[~2005-03-15 18:26 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 [this message]
2005-03-21 10:14 ` Pavel Machek
2005-03-21 15:56 ` Phillip Lougher
2005-03-21 19:00 ` Pavel Machek
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=423727BD.7080200@grupopie.com \
--to=pmarques@grupopie.com \
--cc=akpm@osdl.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=phillip@lougher.demon.co.uk \
/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