[LU-10276] Revise what MDS_INODELOCK_XATTR protects

• Status: Open
• Project: Lustre
• Type: Improvement
• Priority: Minor
• Reporter: Li Wei (Inactive)
• Assignee: WC Triage
• Resolution: Unresolved

Description

MDS_INODELOCK_XATTR has been protecting all EAs of an inode since its introduction for client-side EA caching. Because some EAs are used internally, the set of procedures contending for MDS_INODELOCK_XATTR has went beyond SETXATTR, GETXATTR. A few examples:

• LINK, UNLINK, and RENAME take MDS_INODELOCK_XATTR for XATTR_NAME_LINK.
• HSM_STATE_SET, mdt_hsm_release(), mdt_add_dirty_flag() take MDS_INODELOCK_XATTR for XATTR_NAME_HSM.

Some of these may have an unnecessary negative effect on client-side EA caching efficiency.

We might want to consider removing internal EAs from the scope of MDS_INODELOCK_XATTR. Potential questions include:

• Clients wouldn't be able to do listxattr() completely from EA caches. Would this affect any applications we care about?
• How to handle older clients who assume MDS_INODELOCK_XATTR protects all EAs?

Issue Links

• is related to: LU-2869 extended attribute cache for Lustre
• is related to: LU-17238 negative xattr cache on client

Comments

[Andreas Dilger]

It seems possible to store "xe_value = ERR_PTR(-EREMOTE)" into the xattr cache to indicate that the xattr exists but the value is not in the cache. That would at least allow listxattr() from the client cache to work without having to cache all of the values.

I've also filed LU-17238 to implement a proper negative xattr cache that would store "xe_value = ERR_PTR(-ENODATA)" to indicate that the requested name does not exist.