Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230411030248.53356-1-chengen.du@canonical.com>
 <CAPt2mGNqqDeRMeCSVh6oX_=nS0UcGCfhBfVcuaVG9HpdwVSzVg@mail.gmail.com>
 <CAPza5qee7vHKwjwhS27xB8xXTgAFHEmv7eiFk6zGTUUc4s8=TQ@mail.gmail.com> <B9E03B97-F67C-48FC-B5EE-5B02E288C227@redhat.com>
In-Reply-To: <B9E03B97-F67C-48FC-B5EE-5B02E288C227@redhat.com>
From:   Chengen Du <chengen.du@canonical.com>
Date:   Wed, 10 May 2023 10:26:59 +0800
Message-ID: <CAPza5qeTqYfnpDa+h+d_nGTz4xh=aiFZZJuH81ZaTA0-t1iqpw@mail.gmail.com>
Subject: Re: [PATCH] NFS: Add mount option 'nofasc'
To:     Benjamin Coddington <bcodding@redhat.com>
Cc:     trond.myklebust@hammerspace.com, anna@kernel.org,
        linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Benjamin,

Thank you so much for your valuable advice.
I truly appreciate your input and it has been very helpful for me.

In my humble opinion, users should base their decision on the remote
target they use to mount.
If the remote target has stable group membership or if they have
performance concerns,
they can consider skipping the clearing of the file access cache.
In order to avoid affecting current behavior, I will also change the
default to not clear the file access cache.

I understand that my choice may not be the best, but I will try to
propose the mount option first.
After I modify the man page description, I will resend the patches and
discuss with the upstream.

Once again, I really appreciate your help and guidance.

Best regards,
Chengen Du

On Tue, May 9, 2023 at 11:16=E2=80=AFPM Benjamin Coddington <bcodding@redha=
t.com> wrote:
>
> On 24 Apr 2023, at 21:41, Chengen Du wrote:
>
> > Hi,
> >
> > May I ask if there are any concerns or opinions regarding the
> > introduction of the new mount option?
> > If there is a more suitable solution, we can discuss it, and I can
> > work on implementing it.
>
> I suspect there's some weariness of mount options, we have a lot of them =
and
> they are not easily removed once implemented.  Additionally, requests to =
add
> them usually can show the appropriate changes to the nfs-utils mount.nfs =
and
> man pages required.  Incompleteness here may be the reason you're not
> hearing back from a maintainer.
>
> However, without guidance from a maintainer, you might end up doing extra
> work trying to meet unclear standards.
>
> There's a couple of other ways to address the access cache performance
> "degradation" that was introduced by the changes that other folks
> desperately needed for correctness.
>
> We can change nfs_access_login_time to have a module parameter modifying
> the behavior.  The downside is this would affect every mount.
>
> We can grow a sysfs knob to change the behavior.  Downside is we only hav=
e
> very preliminary sysfs scaffolding as of yet.
>
> However, if you want to keep pushing for the mount option, I'd suggest do=
ing
> a v2 with the userspace patches, and if that gets ignored then do a "PATC=
H
> RESEND" on that a month or so before each mainline merge window.
>
> I've found that bump-replying to old patches isn't as effective at gettin=
g
> work merged here.  I believe the maintainers want to see that you're
> rebasing as mainline progresses, and you have active ownership over the w=
ork
> to fix bugs that may follow or address other fallout from the community.
>
> Ben
>