From: Benjamin Coddington <bcodding@redhat.com>
To: Anna Schumaker <anna@kernel.org>
Cc: Chuck Lever <chuck.lever@oracle.com>,
Jeff Layton <jlayton@kernel.org>,
trond.myklebust@hammerspace.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 2/2] NFSv4: Allow per-mount tuning of READDIR attrs
Date: Wed, 18 Oct 2023 15:08:45 -0400 [thread overview]
Message-ID: <828F5AC6-99CA-417A-9475-41B6B9F35DB1@redhat.com> (raw)
In-Reply-To: <CAFX2JfkON+5MsYuw-SsvSg04M6Fy=BY_v7RZ9aAs35P7fD15Gw@mail.gmail.com>
On 18 Oct 2023, at 14:38, Anna Schumaker wrote:
> On Wed, Oct 18, 2023 at 10:25 AM Chuck Lever <chuck.lever@oracle.com> wrote:
>>
>> On Wed, Oct 18, 2023 at 09:33:40AM -0400, Jeff Layton wrote:
>>> On Wed, 2023-10-18 at 08:56 -0400, Chuck Lever wrote:
>>>> On Tue, Oct 17, 2023 at 05:30:44PM -0400, Benjamin Coddington wrote:
>>>>> Expose a per-mount knob in sysfs to set the READDIR requested attributes
>>>>> for a non-plus READDIR request.
>>>>>
>>>>> For example:
>>>>>
>>>>> echo 0x800 0x800000 0x0 > /sys/fs/nfs/0\:57/v4_readdir_attrs
>>>>>
>
> I understand why you're not adding a keyword for each attribute
> requested in a readdir, but would it be possible to have a single
> magic keyword like "reset" or "default" that is an alias for reverting
> to the default attributes?
Yes, it's possible. But what happens when we change the defaults again?
"Reset" becomes meaningless after that. That sort of sysfs addition is not
future-proof. This file both shows the current and any future default set
of attributes being used on the client as well as allowing them to be
modified.
The only attributes that are allowed to be set are those that the client
would already request and properly decode in the readdir plus path. The
foot-shooty space is the permutation of every combination of those 20
attributes, save the three cases we've been stomping on already: 1) the
non-plus case, 2) the new non-plus with type, and 3) the plus case with all
20 attributes.
I suppose I could test all those cases for weirdness, but I expect they'd
all "just work" for listing directories. (I have tested quite a few without
surprises.) Perhaps some cases would expose assumptions in the attribute
cache on the client -- for example the client might expect _SIZE and
_SPACE_USED to always be updated in the same operation. But, I don't expect
that to create devastating issues, and I really don't think anyone's going
to need to break the client by trying to ask for only _SIZE without
_SPACE_USED (all hypothetical).
Another way forward may be to just allow the addition or removal of _TYPE,
but the client I want to use allows me to request any of those attributes.
If this never ends up helping anyone, I'll eat my hat.
Ben
next prev parent reply other threads:[~2023-10-18 19:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-17 21:30 [PATCH 0/2] NFSv4 READDIR d_type fixup Benjamin Coddington
2023-10-17 21:30 ` [PATCH 1/2] NFSv4: Always ask for type with READDIR Benjamin Coddington
2023-10-17 21:30 ` [PATCH 2/2] NFSv4: Allow per-mount tuning of READDIR attrs Benjamin Coddington
2023-10-18 12:56 ` Chuck Lever
2023-10-18 13:33 ` Jeff Layton
2023-10-18 14:24 ` Benjamin Coddington
2023-10-18 14:33 ` Chuck Lever
2023-10-18 14:25 ` Chuck Lever
2023-10-18 18:38 ` Anna Schumaker
2023-10-18 19:08 ` Benjamin Coddington [this message]
2023-10-18 19:17 ` Benjamin Coddington
2023-10-19 12:06 ` kernel test robot
2023-10-19 12:52 ` Benjamin Coddington
2023-10-19 12:18 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=828F5AC6-99CA-417A-9475-41B6B9F35DB1@redhat.com \
--to=bcodding@redhat.com \
--cc=anna@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@hammerspace.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox