From: Hans Reiser <reiser@namesys.com>
To: Jeff Mahoney <jeffm@suse.com>
Cc: ReiserFS List <reiserfs-list@namesys.com>
Subject: Re: [PATCH 4/4] reiserfs: on-demand bitmap loading
Date: Tue, 17 Jan 2006 11:03:31 -0800 [thread overview]
Message-ID: <43CD3F83.3060207@namesys.com> (raw)
In-Reply-To: <43CD3EA1.80709@suse.com>
Jeff Mahoney wrote:
> Hans Reiser wrote:
>
> >Are you saying that you allow bitmaps to be unloaded? If yes, how about
> >making that a separate option, and not the default?
>
>
> They're released, yes. Whether or not they're unloaded is up to the rest
> of the system, vm pressure, etc to determine. This isn't any different
> than the patch I posted before, which you ultimately approved in
> September.
>
> If the bitmaps are to be pinned at all, I'd prefer to make *that* the
> option. ReiserFS's behavior with respect to bitmaps is inconsistent with
> every other Linux file system. I'd prefer to make the dynamic bitmaps
> the default, and if you really must, add an option to continue to pin
> them.
>
> The fact remains that the bitmap blocks are infrequently accessed in
> comparison with other bits of metadata that we don't pin. They're not
> accessed at all in a read-only environment, and barely accessed in a
> light-write workload. If the bitmaps are truly in demand for heavy
> writing, the caches should keep those blocks in memory, the same as they
> do on other file systems. If another file system, application, or kernel
> subsystem needs that memory more, it should be available for it to claim.
Ok.
>
> -Jeff
>
> --
> Jeff Mahoney
> SUSE Labs
next prev parent reply other threads:[~2006-01-17 19:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-17 13:54 [PATCH 4/4] reiserfs: on-demand bitmap loading Jeff Mahoney
2006-01-17 18:34 ` Hans Reiser
2006-01-17 18:59 ` Jeff Mahoney
2006-01-17 19:03 ` Hans Reiser [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-01-17 20:30 Jeff Mahoney
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=43CD3F83.3060207@namesys.com \
--to=reiser@namesys.com \
--cc=jeffm@suse.com \
--cc=reiserfs-list@namesys.com \
/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.