All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.