All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Zarochentsev <zam@namesys.com>
To: Zhihui Zhang <bf20761@binghamton.edu>
Cc: reiserfs-list@namesys.com
Subject: Re: A question about slum and relocate
Date: Tue, 25 Nov 2003 21:07:54 +0300	[thread overview]
Message-ID: <20031125180754.GC2144@backtop.namesys.com> (raw)
In-Reply-To: <20031125101902.GB2144@backtop.namesys.com>

On Tue, Nov 25, 2003 at 01:19:03PM +0300, Alex Zarochentcev wrote:
> On Mon, Nov 24, 2003 at 06:50:07PM -0500, Zhihui Zhang wrote:
> > Hi,
> > 
> > After reading some code, it seems to me that a slum does not have to be
> > relocated.  If a slum is small , it will use the overwrite strategy.  Is
> > this understanding correct?  
> 
> Not exactly.
> 
> If slum is big we set pos->leaf_relocate and always relocate leaf nodes.
> Except this, flush alg. makes relocate/overwrite decision individually for each
> node. Leaves can be relocated even if slum size < FLUSH_RELOCATE_THRESHOLD.
> 
> > Also, at the leaf level, if the number of
> > dirty nodes exceeds FLUSH_RELOCATE_THRESHOLD (64), they are always
> > relocated.  Is there any similar threshold for an internal level?  
> 
> no.
> 
> > Does Reiser4 relocate internal nodes separately (i.e. not as part of the slum
> > involving leaf nodes.  
> 
> yes.

Seems I did not understand your question correctly.

The flush position state has a "preceder" object.  It is used as a search start
when reiser4 relocates node and it is set to node's block number after
finishing node processing.  But the relocate/overwrite decision is made
individually for each node.  If there is enough free space all nodes will be
allocated close one to each other.

-- 
Alex.

      reply	other threads:[~2003-11-25 18:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-24 23:50 A question about slum and relocate Zhihui Zhang
2003-11-24 13:04 ` Hans Reiser
2003-11-25 17:41   ` Zhihui Zhang
2003-11-25 22:56     ` Alex Zarochentsev
2003-11-26  4:29       ` Hans Reiser
2003-11-25 10:19 ` Alex Zarochentsev
2003-11-25 18:07   ` Alex Zarochentsev [this message]

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=20031125180754.GC2144@backtop.namesys.com \
    --to=zam@namesys.com \
    --cc=bf20761@binghamton.edu \
    --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.