Messages in this thread | | | Date | Fri, 02 Aug 2002 22:59:04 +0400 | From | Hans Reiser <> | Subject | Re: BIG files & file systems |
| |
Nikita Danilov wrote:
>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. > It sounds like we could store the loc to key mapping in the file handle (a (partial) key is what reiser4 needs to find a directory entry). I am trying to understand if we need to store more than one loc to key mapping in the file handle, or if one is enough. What do people use telldir()/seekdir() for in practice?
> > > > > > > > >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 > > > > > > > > > >
-- 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/
| |