mbox series

[SRU,Bionic,0/1] Fix the significant increase in NFS ACCESS operations

Message ID 20230317021849.22643-1-chengen.du@canonical.com
Headers show
Series Fix the significant increase in NFS ACCESS operations | expand

Message

Chengen Du March 17, 2023, 2:18 a.m. UTC 
BugLink: https://bugs.launchpad.net/bugs/2009325

SRU Justification:

[Impact]
When a user logs in and their login time is more recent than the cache's timestamp,
a new entry is created to replace the original entry in the RB-tree.
Currently, the timestamp is only set if the entry is not found in the RB-tree.
This can lead to the timestamp being undefined when the entry already exists,
potentially causing a significant increase in ACCESS operations if the timestamp is set to zero.

[Fix]
The fix corrects the timing for assigning the access cache timestamp.

git://git.linux-nfs.org/projects/anna/linux-nfs linux-nfs branch
21fd9e8700de86d1169f6336e97d7a74916ed04a (NFS: Correct timing for assigning access cache timestamp)

[Test Plan]
1. Create some files in an NFS folder from the client side.
2. Log out and log back in with the same user.
3. Access the existing files in the NFS folder and confirm that the client side only sends one ACCESS operation to the server side.

[Where problems could occur]
This patch only adjusts the timing for initializing the cache's timestamp, 
which was found to be incorrect in the original code. 
While it does have an impact on NFS-related operations,
it does not affect any other aspects of the system's logic apart from timestamp initialization.

Chengen Du (1):
  NFS: Correct timing for assigning access cache timestamp

 fs/nfs/dir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Kleber Souza March 17, 2023, 8:48 a.m. UTC | #1 
On 17.03.23 03:18, Chengen Du wrote:
> BugLink: https://bugs.launchpad.net/bugs/2009325
> 
> SRU Justification:
> 
> [Impact]
> When a user logs in and their login time is more recent than the cache's timestamp,
> a new entry is created to replace the original entry in the RB-tree.
> Currently, the timestamp is only set if the entry is not found in the RB-tree.
> This can lead to the timestamp being undefined when the entry already exists,
> potentially causing a significant increase in ACCESS operations if the timestamp is set to zero.
> 
> [Fix]
> The fix corrects the timing for assigning the access cache timestamp.
> 
> git://git.linux-nfs.org/projects/anna/linux-nfs linux-nfs branch
> 21fd9e8700de86d1169f6336e97d7a74916ed04a (NFS: Correct timing for assigning access cache timestamp)
> 
> [Test Plan]
> 1. Create some files in an NFS folder from the client side.
> 2. Log out and log back in with the same user.
> 3. Access the existing files in the NFS folder and confirm that the client side only sends one ACCESS operation to the server side.
> 
> [Where problems could occur]
> This patch only adjusts the timing for initializing the cache's timestamp,
> which was found to be incorrect in the original code.
> While it does have an impact on NFS-related operations,
> it does not affect any other aspects of the system's logic apart from timestamp initialization.
> 
> Chengen Du (1):
>    NFS: Correct timing for assigning access cache timestamp
> 
>   fs/nfs/dir.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 

NAK'ing as the thread for Jammy has the same patch as has
been ACK'ed.


Thanks.