Re: readdir behaviour

Re: readdir behaviour

[Jan Blunck]

This was also topic on lkml 2 weeks ago.

Zitat von Tomas Hruby <thruby@gmail.com>:

> First of all I would like to know what exactly is the meaning of the
> 'offset' parameter of filldir and whether it is used somewhere? Unlike
> ext2, our directories are not easily read sequentially and this value
> (copied by filldir to dirent->d_off) seems to be quite useless outside
> our fs code.

The offset of the dirent has no common meaning. Think of it as a cookie or
something like that. It should not be interpreted either by VFS or by the
user-space.

> Related question is what is the correct behaviour of readdir in case
> of user's seeking in the directory? If I understand correctly, in case
> of ext3 (indexed directories), when seeking is detected, readdir
> starts reading from the directory beginning again.

On different archs the libc is seeking (to d_off) after each call to getdents().
Therefore the implementation should honor it.

> The last is about concurrency. How is solved problem when a directory
> is read by readdir and between two readdir calls the same directory is
> changed?

This is the filesystems duty to seek to the next valid dentry. Although it is
not defined if the new directories contents is returned or the one on
opendir().

Although I think it would be nice (and convenient to the "everything is a file"
paradigm) when the directory is presented like a sequential file this is not
the common practice. Due to the fact that there are no applications which are
reading and seeking the directories directly this is a good tradeoff to achieve
high performance for readdir().

Jan

Re: readdir behaviour

[Nikita Danilov]

Jan Blunck writes:
 > This was also topic on lkml 2 weeks ago.
 > 
 > Zitat von Tomas Hruby <thruby@gmail.com>:
 > 
 > > First of all I would like to know what exactly is the meaning of the
 > > 'offset' parameter of filldir and whether it is used somewhere? Unlike
 > > ext2, our directories are not easily read sequentially and this value
 > > (copied by filldir to dirent->d_off) seems to be quite useless outside
 > > our fs code.
 > 
 > The offset of the dirent has no common meaning. Think of it as a cookie or
 > something like that. It should not be interpreted either by VFS or by the
 > user-space.

->d_off is remembered by glibc, and returned to the user as a result of
telldir(3). As such it is valid argument for the following seekdir(3).

 > 
 > > Related question is what is the correct behaviour of readdir in case
 > > of user's seeking in the directory? If I understand correctly, in case
 > > of ext3 (indexed directories), when seeking is detected, readdir
 > > starts reading from the directory beginning again.
 > 
 > On different archs the libc is seeking (to d_off) after each call to getdents().
 > Therefore the implementation should honor it.
 > 
 > > The last is about concurrency. How is solved problem when a directory
 > > is read by readdir and between two readdir calls the same directory is
 > > changed?

Single UNIX specification
(http://www.opengroup.org/onlinepubs/007904875/functions/readdir.html)
is vague about whether directory entries added asynchronously should be
returned.

 > 
 > This is the filesystems duty to seek to the next valid dentry. Although it is
 > not defined if the new directories contents is returned or the one on
 > opendir().
 > 
 > Although I think it would be nice (and convenient to the "everything is a file"
 > paradigm) when the directory is presented like a sequential file this is not
 > the common practice. Due to the fact that there are no applications which are
 > reading and seeking the directories directly this is a good tradeoff to achieve
 > high performance for readdir().

Unfortunately, seekdir and telldir are standard (albeit optional)
interfaces, and libc translates seekdir into lseek. File systems have to
support this.

 > 
 > Jan

Nikita.