[LU-8019] Openlock breakage

• Type: Bug
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.9.0
• Severity: 3
• Assignee: WC Triage
• Reporter: Oleg Drokin

Description

Ever since LU-4367 we have a subtle case of breakage that went unnoticed.

The breakage is two-fold:
1. When an application requests an open lock, it is granted, but cannot be used. This is because revalidate always returns 0 for open requests, but we cannot get to inode from new dentry in ll_lookup_it unless we do RPC which defeats the purpose. - Impact: Low since next to nobody cares about it.

2. When an application opens a file that is already opened for the same mode - we now do not have inode access to see that there is an open handle already, so we do a needless RPC same as above to get to the inode and then discard the filehandle right away. - The impact is a bit more, but this still could only happen if we have a lookup lock on the file first, as if we don't, we still do full lookup to get from dentry to inode.

Issue Links

• is duplicated by: LU-8441 Text file busy error after overwriting file
• is related to: LU-4185 Incorrect permission handling when creating existing directories at ICHEC
• is related to: LU-4367 unlink performance regression on lustre-2.5.52 client

Comments

[Joseph Gmitter (Inactive)]

patch has landed to master for 2.9.0

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/20354/
Subject: LU-8019 llite: Restore proper opencache operations
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 65d0add6057b138e753761b04583339cf39b84f6

[Gerrit Updater]

Oleg Drokin ([e-mail]) uploaded a new patch: http://review.whamcloud.com/20354
Subject: LU-8019 llite: Restore proper opencache operations
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 56ec0a1d2c7941f4a4ae7cc76d2096662583b248