Re: RFC: return d_type for non-plus READDIR

[Chuck Lever III <chuck.lever@oracle.com>]

Hi Geert -

> On Mar 22, 2021, at 9:00 PM, Geert Jansen <gerardu@amazon.com> wrote:
> 
> Hi,
> 
> recursively listing a directory tree requires that you know which entries are
> directories so that you can recurse into them. The getdents() API can provide
> this information through the d_type field.
> 
> Today, d_type is available if we use READDIRPLUS. A non-plus READDIR requests
> only the "rdattr_error" and "mounted_on_fileid" attributes, but not "type", and
> consequently sets d_type to DT_UNKNOWN.
> 
> Requesting the "type" attribute for regular, non-plus READDIR would allow us to
> always return d_type, even for large directories where we switch to a non-plus
> READDIR. It would allow the user to recursively list directories of any size
> without the need for GETATTRs, and, if the server supports this, without any
> stat() or equivalent calls on the server. For some use cases, you could also
> mount with '-o nordirplus' to scan an entire file system efficiently.
> 
> Since not all file servers may be able to produce the directory entry type
> efficiently, this could be implemented as a mount option that defaults off.

Can you say more about the impact of requesting this attribute
from servers that cannot efficiently provide it? Which servers
and filesystems find it a problem, and how much of a problem is
it?


> Some local file systems offer a similar choice. For example, both ext4 and xfs
> have an (in this case mkfs-time) option to store the inode type in the
> directory. If this option is set, then getdents() always returns d_type.
> 
> Would a patch that adds such a mount option be acceptable?

I'd rather avoid adding another administrative knob unless it is
absolutely necessary... are there other options for controlling
whether the client requests this attribute?

For example, is there a way for a server to decide not to provide
it if it would be burdensome to do so? ie, the client always asks,
but it would be up to the server to provide it if it can do so.

--
Chuck Lever