Re: structure dentry help...

Linus Torvalds (torvalds@transmeta.com)
2 Nov 1999 16:56:44 GMT


In article <19991102132416.B17092@pcep-jamie.cern.ch>,
Jamie Lokier <lkd@tantalophile.demon.co.uk> wrote:
>
>Directory lookups following readdir(), and quite possibly following
>other lookups, would be faster if filesystems had the option of creating
>"dentry without inode", such that lookup would do iget() on them.

You can do this already.

See how "autofs" plays with the inode, by using the "revalidate()"
option.

Essentially, if you really really want to do something like the above (I
don't personally think it's all that great an idea), what you can do is:

- readdir() fills in the dentry with a NULL inode, hiding some extra
information (eg the inode number) in "dentry->d_flags"
- now, because the dentry exists, the VFS layer will not call the
"lookup()" method on the dentry, but it WILL call the "revalidate"
method to make sure that the data is still valid...
- your "revalidate" can look something like this:

/* If we have an inode, we're cool */
if (dentry->d_inode)
return 1;
/* Is it a real negative dentry? Cool. */
if (!dentry->d_flags)
return 1;
dentry->d_inode = iget(super_block, dentry->d_flags);
dentry->d_flags = 0;
return 1;

And voila, you have exactly what you were looking for.

Note that if a "readdir" operation returns the inode information fully
(like "readdir_long" on NFSv3, I think, and some other filesystems that
just make directories be a list of inodes directly), then you can just
fill in the full inode information directly and not play games with
revalidate.

Oh. And a final comment - I really don't think the above is necessarily
a good idea. A lot of applications do more readdir() calls than they
ever do lookups, and you might make readdir() slower by doing the dentry
allocation with not enough gain at lookup time.

But feel free to try it out,

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/