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
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:20 EST