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:   Wed, 24 Mar 2021 01:47:14 +0000
From:   Geert Jansen <gerardu@amazon.com>
To:     Chuck Lever III <chuck.lever@oracle.com>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: RFC: return d_type for non-plus READDIR
Message-ID: <20210324014713.GA44499@gerardu>
References: <20210323010057.GA129497@dev-dsk-gerardu-1d-3da90cb4.us-east-1.amazon.com>
 <689DD4DF-17C0-4776-BE53-7F10F7FFE720@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <689DD4DF-17C0-4776-BE53-7F10F7FFE720@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

On Tue, Mar 23, 2021 at 03:26:02PM +0000, Chuck Lever III wrote:

> > 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?

The ability to satisfy a non-plus READDIR by reading just the directory
pages, instead of having to read all dirent inodes as well, can be worth it
for certain use cases (especially those with large directories). If a file
system does not store d_type in the directory, and the client would always
request the type attribute even for non-plus READDIR, then you lose the
ability to make this optimization.

From a review of the man pages, most local file systems appear to be able to
store d_type within the directory, including ext4, xfs and zfs. Both ext4
and xfs have options to turn this behavior off. If you'd export such a file
system using nfsd, then this would cause additional IO on the file system if
we would always request the type attribute.

I do not know how other commercial servers handle this.

> 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.

I looked in the RFCs but I am not sure if there is a way today? Both 4.0 and
4.1 define "type" as a required attribute that needs to be returned if the
client asks for it. There also does not appear to be an enum value
corresponding to DT_UNKNOWN. Were you thinking about something specifically?

If there's no way to do this today, then I guess a per-file system attribute
that indicates support for "can produce file type efficient when reading a
directory" would would be a relatively clean solution. I presume it would
require an RFC to define this attribute. Would you have a recommendation given
your your experience with the RFC process?

Geert