This is a first try to move readdir() to become an inode operation. This is
necessary for a VFS implementation of "something like union-mounts" where a
readdir() needs to read the directory contents of multiple directories.
Besides that the new interface is no longer giving the struct file to the
filesystem implementations anymore.
Comments, please?
Jan
> This is a first try to move readdir() to become an inode operation. This is
> necessary for a VFS implementation of "something like union-mounts" where a
> readdir() needs to read the directory contents of multiple directories.
> Besides that the new interface is no longer giving the struct file to the
> filesystem implementations anymore.
>
> Comments, please?
Hmm, are you sure there are no users which keep some per-struct-file
information for directories? File offset is one such obvious thing which
you've handled but actually filesystem with more complicated structure
of directory may remember some hints about where we really are, keep
some readahead information or so...
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
On Tue, Oct 30, 2007 at 04:26:04PM +0100, Jan Kara wrote:
> > This is a first try to move readdir() to become an inode operation. This is
> > necessary for a VFS implementation of "something like union-mounts" where a
> > readdir() needs to read the directory contents of multiple directories.
> > Besides that the new interface is no longer giving the struct file to the
> > filesystem implementations anymore.
> >
> > Comments, please?
> Hmm, are you sure there are no users which keep some per-struct-file
> information for directories? File offset is one such obvious thing which
> you've handled but actually filesystem with more complicated structure
> of directory may remember some hints about where we really are, keep
> some readahead information or so...
The hfsplus code keeps some extra data in the ->private_data of directories,
although I've lost track of the exact benefit from not looking at the code
in some years. As I recall it was a performance enhancement due to the
fact that the data for all directories is effectively in a single file.
I believe it was easier to keep the current position as a structure
rather than just an offset and be careful about the tracking. The hfs
code is almost identical to the hfsplus code in this area.
Brad Boyer
[email protected]
On Tue, Oct 30, 2007 at 04:26:04PM +0100, Jan Kara wrote:
> > This is a first try to move readdir() to become an inode operation. This is
> > necessary for a VFS implementation of "something like union-mounts" where a
> > readdir() needs to read the directory contents of multiple directories.
> > Besides that the new interface is no longer giving the struct file to the
> > filesystem implementations anymore.
> >
> > Comments, please?
> Hmm, are you sure there are no users which keep some per-struct-file
> information for directories? File offset is one such obvious thing which
> you've handled but actually filesystem with more complicated structure
> of directory may remember some hints about where we really are, keep
> some readahead information or so...
For example, the ext3 filesystem, when it is supported hash tree, does
exactly this. See ext3_htree_store_dirent() in fs/ext3/dir.c and
ext3_htree_fill_tree() in fs/ext3/namei.c.
So your patch would break ext3 htree support.
- Ted