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;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Geert Jansen <gerardu@amazon.com>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: RFC: return d_type for non-plus READDIR
Thread-Topic: RFC: return d_type for non-plus READDIR
Thread-Index: AQHXH4An0zoT5whq90uvEbXY1zJqrqqRsqoA
Date:   Tue, 23 Mar 2021 15:26:02 +0000
Message-ID: <689DD4DF-17C0-4776-BE53-7F10F7FFE720@oracle.com>
References: <20210323010057.GA129497@dev-dsk-gerardu-1d-3da90cb4.us-east-1.amazon.com>
In-Reply-To: <20210323010057.GA129497@dev-dsk-gerardu-1d-3da90cb4.us-east-1.amazon.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D78B5C8C87D02648966A881B562D3B04@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 70fdc06d-2a6f-4723-0379-08d8ee0ff83c
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2021 15:26:02.8532
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 34nr3SGxmwL6s0bIaVUWt7/oNluGp7ft5id1IIC6R3CoregUqnjiYwuxG1BIuImHv8Qr0mxF3MKpJ63MVka+mw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR10MB4257
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 phishscore=0
 mlxlogscore=999 suspectscore=0 spamscore=0 malwarescore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103230113
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9931 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 priorityscore=1501
 impostorscore=0 spamscore=0 mlxscore=0 suspectscore=0 mlxlogscore=999
 phishscore=0 bulkscore=0 adultscore=0 malwarescore=0 clxscore=1011
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2103230114
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

Hi Geert -

> On Mar 22, 2021, at 9:00 PM, Geert Jansen <gerardu@amazon.com> wrote:
>=20
> Hi,
>=20
> recursively listing a directory tree requires that you know which entries=
 are
> directories so that you can recurse into them. The getdents() API can pro=
vide
> this information through the d_type field.
>=20
> Today, d_type is available if we use READDIRPLUS. A non-plus READDIR requ=
ests
> only the "rdattr_error" and "mounted_on_fileid" attributes, but not "type=
", and
> consequently sets d_type to DT_UNKNOWN.
>=20
> 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 s=
ize
> 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 a=
lso
> mount with '-o nordirplus' to scan an entire file system efficiently.
>=20
> Since not all file servers may be able to produce the directory entry typ=
e
> efficiently, this could be implemented as a mount option that defaults of=
f.

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 an=
d 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.
>=20
> 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