NAK: [SRU][Kinetic][PATCH 0/1] Fix the significant increase in NFS ACCESS operations

Kleber Souza kleber.sacilotto.de.souza at canonical.com
Fri Mar 17 08:48:05 UTC 2023


On 17.03.23 03:22, 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.



More information about the kernel-team mailing list