[LU-9962] Possible file size glimpse issue

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Low Priority
• Severity: 3
• Assignee: Patrick Farrell
• Reporter: Patrick Farrell (Inactive)

Description

In the review for LU-6179 (https://review.whamcloud.com/#/c/13564/, specifically here:
https://review.whamcloud.com/#/c/13564/90/lustre/ofd/ofd_dlm.c ) Jinshan described a possible problem with the current file size glimpsing behavior.

Specifically, the current behavior is to send a glimpse to only the top PW lock on the file, because it controls file size. Lock ahead introduces some complexity there, creating speculative write locks which may not be used for i/o. In that case, we must glimpse all speculative locks above the local file size*, to be sure of getting the correct file size.

*(well, all clients holding speculative locks above the local file size - this and other details are covered in comments in ofd_dlm.c in the lockahead patch )

Jinshan noted that in some cases the i/o which created a normal PW lock will not happen. In that case, a client with a lock earlier in the file may in fact be updating the file size.

He gave this specific example to clarify:
Provided that the local object size is 1M, I would say the typical case is:
1. client A holds lock [2M, EOF), but fails to [write] anything to the object;
2. client B holds [0, 2M) lock, and extends the file size to 1.5M.

In this case, the OST will send glimpse request to client A, which doesn't know the exact file size.
------------------

Andreas noted that since this problem has existed for a long time, fixing it should be considered separately. He also noted that the problem is very unlikely to be serious, as temporarily incorrect file size in the context of a write error is a pretty small problem and should not ever corrupt data.

However, Andreas asked me to open another ticket and submit a patch to try fixing this issue, so we can discuss it there. This patch will depend on the infrastructure for glimpsing multiple locks introduced by the LU-6179 patch, so I plan to push it after that patch has landed.

Issue Links

• is blocked by: LU-6179 Lock ahead - Request extent locks from userspace