Re: [NFS] Updated patch for the [2.4.x] NFS 'missing directory entry a.k.a. IRIX server' problem...

[Jamie Lokier]

Trond Myklebust wrote:
> >>>>> " " == H J Lu <[e-mail]> writes:
> 
>      > I much prefer to have a new getdents system call which will
>      > also return d_type so that the 32 bit function in glibc can use
>      > this new getdents instead of getdents64.
> 
> That could also be done, however it seems odd to be adding a new
> 32-bit interface after the point when we're supposed to all have moved
> to 64 bits.

Indeed, getdents64 -> 32 conversion is hardly performance critical
anyway.

> BTW: does anybody anywhere actually use d_type? Certainly the standard
>      utilities such as 'find' or 'ls' don't seem to have been adapted
>      yet: I hacked up a version of NFSv3 that actually filled d_type
>      (by using readdirplus rather than readdir) but I've yet to find
>      any 'off the shelf' software, that uses the extra information.

Look for `treescan' via Google.  It uses a number of heuristics to
optimise a recursive directory search, and one of those is d_type if
available.  Though it dates back to a time before getdents64 (I hacked
getdents to return d_type).

d_type is quite effective for `find' type scans.  I really ought to
release an updated treescan -- the intent was always to replace the
backend of `find' but I got caught up trying to optimise the order of
open/readdir/close sequences and then on to other things.

-- Jamie