All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. R. Okajima" <hooanon05@yahoo.co.jp>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: Q. cache in squashfs?
Date: Thu, 08 Jul 2010 15:08:47 +0900	[thread overview]
Message-ID: <6356.1278569327@jrobl> (raw)
In-Reply-To: <4C354CBE.70401@lougher.demon.co.uk>


Phillip Lougher:
> What I think you're seeing here is the negative effect of fragment
> blocks (tail-end packing) in the native squashfs example and the
> positive effect of vfs/loop block caching in the ext3 on squashfs example.

Thank you very much for your explanation.
I think the number of cached decompressed fragment blocks is related
too. I thought it is much larger, but I found it is 3 by default. I will
try larger value with/without -no-fragments which you pointed.

Also I am afraid the nested loopback mount will cause caching doubly (or
more), cache by ext3-loopback and by native squashfs loopback, and some
people doesn't want this.
But if user has rich memory and doen't care about nested caching
(because it will be reclaimed when necessary), then I expect the nested
loopback mount will be a good option.
For instance,
- CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE = 1
- inner single ext2 image
- mksquashfs without -no-fragments
- ram 1GB
- the squashfs image size 250MB

Do you think will it be better for very random access pattern?


J. R. Okajima

  reply	other threads:[~2010-07-08  6:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-24  2:37 Q. cache in squashfs? J. R. Okajima
2010-07-08  3:57 ` Phillip Lougher
2010-07-08  6:08   ` J. R. Okajima [this message]
2010-07-09  7:53     ` J. R. Okajima
2010-07-09 10:32       ` Phillip Lougher
2010-07-09 10:55         ` Phillip Lougher
2010-07-10  5:07           ` J. R. Okajima
2010-07-10  5:08             ` J. R. Okajima
2010-07-11  2:48             ` Phillip Lougher
2010-07-11  5:55               ` J. R. Okajima
2010-07-11  9:38                 ` [RFC 0/2] squashfs parallel decompression J. R. Okajima
2011-02-22 19:41                   ` Phillip Susi
2011-02-23  3:23                     ` Phillip Lougher
2010-07-11  9:38                 ` [RFC 1/2] squashfs parallel decompression, early wait_on_buffer J. R. Okajima
2010-07-11  9:38                 ` [RFC 2/2] squashfs parallel decompression, z_stream per cpu J. R. Okajima
2010-07-09 12:24         ` Q. cache in squashfs? J. R. Okajima

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=6356.1278569327@jrobl \
    --to=hooanon05@yahoo.co.jp \
    --cc=linux-fsdevel@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 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.