> Trond Myklebust wrote:
>> Indeed. The latter is the main problem with NFSv3's
>> READDIRPLUS. It's really only useful in the case when you're
>> doing a 'find', but slows things down considerably in all other
>> cases.
> Is it even useful for `find'? A good find implementation does
> not stat() everything.
As you pointed out, you do need to determine whether an entry points
to a directory or a file. At the moment that means a full lookup of
the file handle for each candidate.
>> I'm still looking for a good heuristic before re-enabling it in
>> the current NFSv3 client patches.
> I'm wondering if a generic flag, either to open() or the new
> getdents replacement (with d_type support) would be
> appropriate.
> It would mean: "populate dentry cache and/or use READDIRPLUS
> over NFSv3". In other words: "we're going to be doing lots of
> lookups in this directory".
Possibly. Alternatively, one could perhaps use the directory's size as
an indicator whether or not to do a full READDIRPLUS or not. This is
(if I understood correctly) the approach favoured by other UNIX
clients.
Cheers,
Trond
-
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/