From: Phillip Lougher <phillip@lougher.demon.co.uk>
To: unlisted-recipients:; (no To-header on input)
Cc: "Jeff Garzik" <jeff@garzik.org>,
"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: Tue, 21 Mar 2006 16:01:51 +0000 [thread overview]
Message-ID: <4420236F.80608@lougher.demon.co.uk> (raw)
In-Reply-To: <20060319163249.GA3856@ucw.cz>
Pavel Machek wrote:
> On Fri 17-03-06 12:25:44, Jeff Garzik wrote:
>>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?
>
Perhaps, but almost all the byteswap is performed on the metadata side,
reading directories and inodes, where nearly every byte will need to be
swapped. As inodes are compacted and compressed in 8 KB blocks, and are
on average 15 bytes in size, for each 8 KB decompress you're potentially
doing 8192/15 inode byteswaps. This is probably sufficent to affect
directory search and lookup on a slow processor.
The data path is all gzip overhead (64K datablocks), there is no
byteswap taking place except for the block size integer. Therefore
byteswap doesn't have any affect on reading data.
Phillip
next prev parent reply other threads:[~2006-03-21 16:02 UTC|newest]
Thread overview: 28+ 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 11:16 ` Phillip Lougher
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: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-21 16:01 ` Phillip Lougher [this message]
[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 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-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=4420236F.80608@lougher.demon.co.uk \
--to=phillip@lougher.demon.co.uk \
--cc=jeff@garzik.org \
--cc=joern@wohnheim.fh-wedel.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox