All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Artem B. Bityuckiy" <dedekind@yandex.ru>
To: Vladimir Saveliev <vs@namesys.com>
Cc: reiserfs-list@namesys.com
Subject: Re: Reiser4 + seekdir()
Date: Mon, 27 Jun 2005 16:09:06 +0400	[thread overview]
Message-ID: <42BFEC62.1010907@yandex.ru> (raw)
In-Reply-To: <1119872500.4257.260.camel@tribesman.namesys.com>

> Location within a directory in reiser4 is logical number of entry within
> the directory.
Yes, I know. It does not absolutely correctly handle the way when 
dirents were deleted before and after the saved position.

Well, Nikita kindly answered my questions in IRC (unfortunately there 
are few Namesys people there).
According to him, seekdir() doesn't have to work correctly if the 
previous N direntries were deleted (it only tries). Indeed, even 
classical FSes (where directory is a file with the plain list of 
direntries) may shrink directories. I thought Reiser4 pretends to work 
correctly even in case of deletions.

> fs/reiser4/plugin/dir/dir.c:seek_dir()
> 
> You may also want to read a comment before
> fs/reiser4/plugin/dir/dir.c:readdir_common and comment named  "STATELESS
> READDIR" in the fs/reiser4/plugin/dir/dir.c.
Yes, I read it of course. It is really confusing. What it should mention 
is that

> we can not return entry key to telldir, on seekdir we have to be able to
> position within a directory by off_t - therefore, we need adjust_dir_pos
> anyway.
Yes, thanks, I've realized this as well.

Could you please explain the real difference between 
SEEKABLE_HASHED_DIR_PLUGIN_ID and LAST_DIR_ID plugins. Both seems to 
support seeks. Both seems to call adjust_dir_pos(). Only key assignment 
is simpler in case of SEEKABLE_HASHED_DIR_PLUGIN_ID. This confused me 
very much.

Thanks.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

  reply	other threads:[~2005-06-27 12:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-27  9:28 Reiser4 + seekdir() Artem B. Bityuckiy
2005-06-27 11:41 ` Vladimir Saveliev
2005-06-27 12:09   ` Artem B. Bityuckiy [this message]
2005-06-27 12:39     ` Vladimir Saveliev
2005-06-27 12:57       ` Artem B. Bityuckiy
2005-06-27 13:49         ` Vladimir Saveliev
2005-06-27 13:53           ` Artem B. Bityuckiy
2005-06-27 19:50             ` Hans Reiser
2005-06-29  6:51               ` Artem B. Bityuckiy
2005-06-29 10:22                 ` Vladimir Saveliev
2005-06-29 10:29                   ` Artem B. Bityuckiy
2005-06-29 11:48                     ` Vladimir Saveliev
2005-06-29 18:11                   ` Valdis.Kletnieks
2005-06-30 16:26                     ` Vladimir Saveliev
2005-06-27 18:09     ` Hans Reiser

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=42BFEC62.1010907@yandex.ru \
    --to=dedekind@yandex.ru \
    --cc=reiserfs-list@namesys.com \
    --cc=vs@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.