All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Jeff Garzik <jeff@garzik.org>
Cc: "Phillip Lougher" <phillip@lougher.org.uk>,
	"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: Sun, 19 Mar 2006 16:32:50 +0000	[thread overview]
Message-ID: <20060319163249.GA3856@ucw.cz> (raw)
In-Reply-To: <441AF118.7000902@garzik.org>

On Fri 17-03-06 12:25:44, Jeff Garzik wrote:
> 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.

gzip is already pretty expensive, I'd say. Is not byteswap lost in
noise?

-- 
Thanks, Sharp!

WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Jeff Garzik <jeff@garzik.org>
Cc: "Phillip Lougher" <phillip@lougher.org.uk>,
	"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: Sun, 19 Mar 2006 16:32:50 +0000	[thread overview]
Message-ID: <20060319163249.GA3856@ucw.cz> (raw)
In-Reply-To: <441AF118.7000902@garzik.org>

On Fri 17-03-06 12:25:44, Jeff Garzik wrote:
> 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.

gzip is already pretty expensive, I'd say. Is not byteswap lost in
noise?

-- 
Thanks, Sharp!
-
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

  parent reply	other threads:[~2006-03-21 15:13 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
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 [this message]
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=20060319163249.GA3856@ucw.cz \
    --to=pavel@ucw.cz \
    --cc=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.