mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Benjamin Coddington <bcodding@redhat.com>
To: Chengen Du <chengen.du@canonical.com>
Cc: trond.myklebust@hammerspace.com, anna@kernel.org,
	linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] NFS: Add mount option 'nofasc'
Date: Tue, 09 May 2023 11:16:23 -0400	[thread overview]
Message-ID: <B9E03B97-F67C-48FC-B5EE-5B02E288C227@redhat.com> (raw)
In-Reply-To: <CAPza5qee7vHKwjwhS27xB8xXTgAFHEmv7eiFk6zGTUUc4s8=TQ@mail.gmail.com>

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 have
very preliminary sysfs scaffolding as of yet.

However, if you want to keep pushing for the mount option, I'd suggest doing
a v2 with the userspace patches, and if that gets ignored then do a "PATCH
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 getting
work merged here.  I believe the maintainers want to see that you're
rebasing as mainline progresses, and you have active ownership over the work
to fix bugs that may follow or address other fallout from the community.

Ben


  parent reply	other threads:[~2023-05-09 15:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-11  3:02 Chengen Du
2023-04-19  7:17 ` Daire Byrne
2023-04-25  1:41   ` Chengen Du
2023-05-09  2:31     ` Chengen Du
2023-05-09 11:53       ` Jan Ingvoldstad
2023-05-09 15:16     ` Benjamin Coddington [this message]
2023-05-10  2:26       ` Chengen Du

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=B9E03B97-F67C-48FC-B5EE-5B02E288C227@redhat.com \
    --to=bcodding@redhat.com \
    --cc=anna@kernel.org \
    --cc=chengen.du@canonical.com \
    --cc=linux-kernel@vger.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

all inboxes | Powered by JetHome®