From: Jeff Garzik <jeff@garzik.org>
To: Phillip Lougher <phillip@lougher.org.uk>
Cc: "Jörn Engel" <joern@wohnheim.fh-wedel.de>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [ANN] Squashfs 3.0 released
Date: Fri, 17 Mar 2006 12:25:44 -0500 [thread overview]
Message-ID: <441AF118.7000902@garzik.org> (raw)
In-Reply-To: <0E3DADA8-1A1C-47C5-A3CF-F6A85FF5AFB8@lougher.org.uk>
Phillip Lougher wrote:
> On 17 Mar 2006, at 16:00, Jeff Garzik wrote:
>> Jörn Engel wrote:
>>>>> The one still painfully missing is a
>>>>> fixed-endianness disk format.
>> Fixed endian isn't necessarily a requirement. Detectable endian is.
>> As long as (a) the filesystem mkfs notes the endian-ness and (b) the
>> kernel filesystem code properly handles both types of endian, life is
>> fine.
>>
> That's what is currently done. There are two filesystem formats, big
> endian (donated by Squashfs magic of 'sqsh') and little endian (denoted
> by Squashfs magic of 'hsqs'). The kernel code detects the filesystem
> endianness and swaps if necessary.
Well, then, I don't see a need to change anything. As I said,
[consistent and] detectable endian is the real requirement. For
SquashFS's users, I would think they would prefer the current situation
(selectable endian) to fixed endian, because many SquashFS users need to
squeeze every ounce of performance out of severely resource-constrained
devices.
I have two routers, ADM5120-based Edimax and LinkSys WRT54G v5, both of
which have a mere 2MB of flash, and both use SquashFS to maximize that
space. And both are el cheapo, slow embedded processors that run far
slower than 300Mhz. I look askance at anyone who wants to make an
arbitrary filesystem design decision imposing tons of bytesex upon these
lowly devices.
Jeff
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Garzik <jeff@garzik.org>
To: Phillip Lougher <phillip@lougher.org.uk>
Cc: "Jörn Engel" <joern@wohnheim.fh-wedel.de>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [ANN] Squashfs 3.0 released
Date: Fri, 17 Mar 2006 12:25:44 -0500 [thread overview]
Message-ID: <441AF118.7000902@garzik.org> (raw)
In-Reply-To: <0E3DADA8-1A1C-47C5-A3CF-F6A85FF5AFB8@lougher.org.uk>
Phillip Lougher wrote:
> On 17 Mar 2006, at 16:00, Jeff Garzik wrote:
>> Jörn Engel wrote:
>>>>> The one still painfully missing is a
>>>>> fixed-endianness disk format.
>> Fixed endian isn't necessarily a requirement. Detectable endian is.
>> As long as (a) the filesystem mkfs notes the endian-ness and (b) the
>> kernel filesystem code properly handles both types of endian, life is
>> fine.
>>
> That's what is currently done. There are two filesystem formats, big
> endian (donated by Squashfs magic of 'sqsh') and little endian (denoted
> by Squashfs magic of 'hsqs'). The kernel code detects the filesystem
> endianness and swaps if necessary.
Well, then, I don't see a need to change anything. As I said,
[consistent and] detectable endian is the real requirement. For
SquashFS's users, I would think they would prefer the current situation
(selectable endian) to fixed endian, because many SquashFS users need to
squeeze every ounce of performance out of severely resource-constrained
devices.
I have two routers, ADM5120-based Edimax and LinkSys WRT54G v5, both of
which have a mere 2MB of flash, and both use SquashFS to maximize that
space. And both are el cheapo, slow embedded processors that run far
slower than 300Mhz. I look askance at anyone who wants to make an
arbitrary filesystem design decision imposing tons of bytesex upon these
lowly devices.
Jeff
-
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
next prev parent reply other threads:[~2006-03-17 17:25 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-17 0:45 [ANN] Squashfs 3.0 released Phillip Lougher
[not found] ` <20060317010529.GB30801@schatzie.adilger.int>
2006-03-17 1:30 ` Phillip Lougher
2006-03-17 1:51 ` Samuel Masham
2006-03-17 10:40 ` Jörn Engel
2006-03-17 10:40 ` Jörn Engel
2006-03-17 11:16 ` Phillip Lougher
2006-03-17 11:16 ` Phillip Lougher
2006-03-17 12:43 ` Jörn Engel
2006-03-17 12:43 ` Jörn Engel
2006-03-17 16:00 ` Jeff Garzik
2006-03-17 17:04 ` Phillip Lougher
2006-03-17 17:04 ` Phillip Lougher
2006-03-17 17:25 ` Jeff Garzik [this message]
2006-03-17 17:25 ` Jeff Garzik
2006-03-17 20:39 ` Willy Tarreau
2006-03-19 1:38 ` Phillip Lougher
2006-03-21 15:33 ` Francesco Biscani
2006-03-19 1:42 ` Phillip Lougher
2006-03-19 16:32 ` Pavel Machek
2006-03-19 16:32 ` Pavel Machek
2006-03-21 16:01 ` Phillip Lougher
[not found] ` <20060321161452.GG27946@ftp.linux.org.uk>
2006-03-21 19:08 ` Phillip Lougher
2006-03-21 19:11 ` Pavel Machek
2006-03-21 19:11 ` Pavel Machek
2006-03-21 20:03 ` Phillip Lougher
2006-03-21 20:07 ` Al Viro
2006-03-21 22:01 ` Jan Engelhardt
2006-03-21 22:11 ` Jeff Garzik
2006-03-21 22:59 ` Al Viro
2006-03-21 20:15 ` Pavel Machek
2006-03-21 20:33 ` Al Viro
2006-03-21 21:28 ` Andreas Dilger
2006-03-21 23:24 ` Jörn Engel
2006-03-21 23:24 ` Jörn Engel
2006-03-17 21:32 ` Jan Engelhardt
2006-03-17 15:54 ` Xavier Bestel
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=441AF118.7000902@garzik.org \
--to=jeff@garzik.org \
--cc=joern@wohnheim.fh-wedel.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=phillip@lougher.org.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.