Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 23 Mar 2021 01:00:57 +0000
From:   Geert Jansen <gerardu@amazon.com>
To:     <linux-nfs@vger.kernel.org>
Subject: RFC: return d_type for non-plus READDIR
Message-ID: <20210323010057.GA129497@dev-dsk-gerardu-1d-3da90cb4.us-east-1.amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

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.

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?