Hi Trond / Anna,
I wanted to provide you with additional feedback regarding the
performance issue that was addressed in commit 21fd9e8700de (NFS:
Correct timing for assigning access cache timestamp).
I apologize for reaching out to you frequently, but I believe this
information is important to share.
Although the commit appears to have resolved the issue, I have
received reports from some community users who are experiencing a
significant increase in NFS ACCESS operations.
If you are interested, you can find further details regarding this
feedback here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2009325
After conducting a survey, I have discovered that this issue may be
attributed to suexec-like mechanisms.
Specifically, applications or users may use the 'su' command to switch
to other privileged users and operate on NFS-mounted folders.
In these instances, the login time will be renewed, and NFS ACCESS
operations will need to be resent.
While I believe the new mechanism adheres to POSIX design and the
performance overhead seems reasonable,
I think it would be beneficial to provide a mount option that allows
users to decide whether to renew access cache after login.
In some production environments where access cache can be trusted due
to the stable group membership, this option could be particularly
useful.
In my humble opinion, the option could be enabled by default for most
personal users who can afford the overhead.
However, I am open to hearing your thoughts on this approach or any
alternative ideas you may have.
I would be willing to contribute to this effort if there is an opportunity.
Thank you for your time and consideration.
Best regards,
Chengen Du
Hi Trond / Anna,
I apologize for disturbing you, as I understand that you may be
occupied with other tasks.
However, I wanted to bring to your attention that several users have
reported a performance issue, and are eagerly awaiting a possible
solution.
I have proposed a potential solution and I would be grateful if you
could provide me with some feedback.
Your input would be highly appreciated, as it will allow me to
continue working on this issue and finding a resolution for our users.
Thank you for your time and consideration.
Best regards,
Chengen Du
On Wed, Mar 29, 2023 at 1:48 PM Chengen Du <[email protected]> wrote:
>
> Hi Trond / Anna,
>
> I wanted to provide you with additional feedback regarding the
> performance issue that was addressed in commit 21fd9e8700de (NFS:
> Correct timing for assigning access cache timestamp).
> I apologize for reaching out to you frequently, but I believe this
> information is important to share.
>
> Although the commit appears to have resolved the issue, I have
> received reports from some community users who are experiencing a
> significant increase in NFS ACCESS operations.
> If you are interested, you can find further details regarding this
> feedback here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2009325
>
> After conducting a survey, I have discovered that this issue may be
> attributed to suexec-like mechanisms.
> Specifically, applications or users may use the 'su' command to switch
> to other privileged users and operate on NFS-mounted folders.
> In these instances, the login time will be renewed, and NFS ACCESS
> operations will need to be resent.
>
> While I believe the new mechanism adheres to POSIX design and the
> performance overhead seems reasonable,
> I think it would be beneficial to provide a mount option that allows
> users to decide whether to renew access cache after login.
> In some production environments where access cache can be trusted due
> to the stable group membership, this option could be particularly
> useful.
>
> In my humble opinion, the option could be enabled by default for most
> personal users who can afford the overhead.
> However, I am open to hearing your thoughts on this approach or any
> alternative ideas you may have.
> I would be willing to contribute to this effort if there is an opportunity.
>
> Thank you for your time and consideration.
>
> Best regards,
> Chengen Du