From: Nikita Danilov <Nikita@Namesys.COM>
To: Hans Reiser <reiser@namesys.com>
Cc: trond.myklebust@fys.uio.no, Steve Lord <lord@sgi.com>,
Jan Harkes <jaharkes@cs.cmu.edu>,
Alexander Viro <viro@math.psu.edu>,
"Peter J. Braam" <braam@clusterfs.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: BIG files & file systems
Date: Fri, 2 Aug 2002 22:48:08 +0400 [thread overview]
Message-ID: <15690.54248.33518.887768@laputa.namesys.com> (raw)
In-Reply-To: <3D4AD00C.8060701@namesys.com>
Hans Reiser writes:
> Nikita Danilov wrote:
>
> >Trond Myklebust writes:
> > > >>>>> " " == Nikita Danilov <Nikita@Namesys.COM> writes:
> > >
> > > > But there still is a problem with applications (if any) calling
> > > > seekdir/telldir directly...
> > >
> > > Agreed. Note however that the semantics for seekdir/telldir as
> > > specified by SUSv2 are much weaker than those in our current
> > > getdents()+lseek().
> > >
> > > >From the Opengroup documentation for seekdir, it states that:
> > >
> > > On systems that conform to the Single UNIX Specification, Version 2,
> > > a subsequent call to readdir() may not be at the desired position if
> > > the value of loc was not obtained from an earlier call to telldir(),
> > > or if a call to rewinddir() occurred between the call to telldir()
> > > and the call to seekdir().
> > >
> > > IOW assigning a unique offset to each and every entry in the directory
> > > is overkill (unless the user is calling telldir() for all those
> > > entries).
> >
> Forgive the really dumb question, but does this mean we can just store
> the last entry returned to readdir in the directory metadata, and
> completely ignore the value of loc?
If application is using readdir, then yes: glibc internally maps readdir
into getdents plus at most one lseek on directory for "adjustment"
purposes (if I remember correctly, problem is that kernel struct dirent
has extra field and glibc cannot tell in advance how many of them will
fit into supplied user buffer).
But if application uses seekdir(3)/telldir(3) directly---then no.
>
> >
> >Are you implying some kind of ->telldir() file operation that notifies
> >file-system that user has intention to later restart readdir from the
> >"current" position and changing glibc to call sys_telldir/sys_seekdir in
> >stead of lseek? This will allow file-systems like reiser4 that cannot
> >restart readdir from 32bitsful of data to, at least, allocate something
> >in kernel on call to ->telldir() and free in ->release().
> >
> > >
> > > Cheers,
> > > Trond
> >
Nikita.
> >
> >
> >
> >
>
>
> --
> Hans
>
>
>
next prev parent reply other threads:[~2002-08-02 18:44 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-31 19:16 Peter J. Braam
2002-07-31 19:26 ` Christoph Hellwig
2002-07-31 20:04 ` Matti Aarnio
2002-07-31 20:12 ` Christoph Hellwig
2002-08-02 17:26 ` Albert D. Cahalan
2002-08-02 22:14 ` Randy.Dunlap
2002-08-03 3:26 ` Albert D. Cahalan
2002-08-06 5:19 ` Andreas Dilger
2002-08-06 7:24 ` Albert D. Cahalan
2002-08-06 7:52 ` Andreas Dilger
2002-08-06 9:28 ` Matti Aarnio
2002-08-05 13:04 ` Stephen Lord
2002-08-05 13:42 ` Hans Reiser
2002-08-05 13:56 ` Randy.Dunlap
2002-08-05 14:21 ` Randy.Dunlap
2002-08-05 17:31 ` Albert D. Cahalan
2002-08-06 0:16 ` jw schultz
2002-08-06 9:48 ` Hans Reiser
2002-07-31 21:07 ` Jan Harkes
2002-07-31 21:13 ` Alexander Viro
2002-08-01 3:51 ` Jan Harkes
2002-08-01 12:01 ` Mark Mielke
2002-08-02 0:09 ` Stephen Lord
2002-08-02 12:17 ` Chris Mason
2002-08-02 12:33 ` Anton Altaparmakov
2002-08-02 13:56 ` Jan Harkes
2002-08-02 14:06 ` Steve Lord
2002-08-02 15:10 ` Hans Reiser
2002-08-02 15:39 ` Trond Myklebust
2002-08-02 17:01 ` Hans Reiser
2002-08-02 17:25 ` Nikita Danilov
2002-08-02 17:47 ` Trond Myklebust
2002-08-02 18:10 ` Nikita Danilov
2002-08-02 18:31 ` Hans Reiser
2002-08-02 18:48 ` Nikita Danilov [this message]
2002-08-02 18:59 ` Hans Reiser
2002-08-01 12:01 ` David Woodhouse
2002-08-01 20:33 ` Andrew Morton
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=15690.54248.33518.887768@laputa.namesys.com \
--to=nikita@namesys.com \
--cc=braam@clusterfs.com \
--cc=jaharkes@cs.cmu.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=lord@sgi.com \
--cc=reiser@namesys.com \
--cc=trond.myklebust@fys.uio.no \
--cc=viro@math.psu.edu \
/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
all inboxes | Powered by JetHome®