[LU-17997] 'scp -p' command cannot preserve mtime on nfs mounted lustre

• Type: Bug
• Resolution: Duplicate
• Priority: Minor
• Severity: 3
• Assignee: Feng Lei
• Reporter: Feng Lei

Description

Reproduce steps:

1. prepare a lustre fs
2. on node-1, mount lustre fs (e.g., /mnt/lustre). And nfs export the lustre fs
3. on node-2, mount nfs exported fs from node-1 (e.g., /mnt/nfs_lustre)
4. on node-3, copy some local files to node-2 with 'scp -p' command

node-3# scp -p file_1 node-2://mnt/nfs_lustre/file_1

Sometime the mtime of target file is not the same as source file. It is still at current time.

node-1, 2, 3 may be one single node.

The bug cannot be reproduced if any protocol (lustre/nfs/scp) is skipped.

Issue Links

• duplicates: LU-13374 open-close operation can lead to loss of file time set performed in the middle

Comments

[Gerrit Updater]

"Feng Lei <[e-mail]>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/55710
Subject: LU-17997 llite: add sanity/test_39t
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: dd188b9a9305470fd7b01642834cf40791e099e0

[Feng Lei]

It's a race condition between setattr(timestamps) and close(). For example:

1. thread-1 enters into close(), it reads timestamps (usually current time in this case) from inode and prepare a RPC.
2. thread-2 enters into setattr(timestamps), it sets the timestamps (to a previous time) in inode, sends RPC to server, gets response and return.
3. thread-1 sends close() RPC to server. The timestamps on MDS is updated again to current time.