Subject: Re: getdent, d_type and NFS
To: Frank van der Linden <firstname.lastname@example.org>
From: Charles M. Hannum <email@example.com>
Date: 10/30/2003 16:38:25
On Thursday 30 October 2003 12:13 pm, Frank van der Linden wrote:
> On Wed, Oct 29, 2003 at 05:26:28PM +0000, Emmanuel Dreyfus wrote:
> > It seems getdents will not fill d_type for objects that live on a NFS
> > mount. Do I miss something, or should it be documented in getdents(2) and
> > readdir(3)?
> It can't always support d_type on NFS (only in the case of NFSv3 using
> READDIRPLUS operations is it easy to do; it would have considerable
> overhead otherwise).
> I'm not entirely sure why we have d_type or how it got into our interface..
> I originally didn't document d_type in getdents(2), because it couldn't
> be completely supported. And other systems, like Solaris, do not have the
> field at all.
I'm virtually certain this is documented somewhere, but I'm not sure where.
d_type is an optimization for tree-walking. If you have it, a typical tree
walk does not need to stat(2) each inode to determine whether it's a
directory. This gives a major performance improvement, e.g. for almost
anything that uses fts(3).
It's not necessary for proper operation for every file system to support it.
If the file system can't support it, it just returns DT_UNKNOWN, and the
user-level code falls back to using stat(2) transparently.
I thought Linux picked up some variant on this? I see we do:
idb.d_type = bdp->d_type;
Are their d_type values really the same as ours?