Details
-
Bug
-
Resolution: Duplicate
-
Minor
-
Lustre 2.3.0
-
None
-
5
-
3
-
4548
Description
Caching the xattr list (and xattrs themselves) on the clients is becoming increasingly important, since this has shown up as a performance problem in the past (e.g. doing an RPC to get "security.capability" for every file access).
We can easily/compatibly add a simple xattr list and/or value cache on the client under the MDS_INODELOCK_UPDATE bit, which setxattr always gets in LCK_EX mode. mdt_reint_setxattr() also gets the MDS_INODELOCK_LOOKUP for XATTR_NAME_ACL_ACCESS, but this should be expanded to also include XATTR_SECURITY_PREFIX. This should also allow negative xattr caching so that an RPC is not sent repeatedly for xattrs that do not exist. Whether we want to cache the non-security xattrs under a separate MDS_INODELOCK_XATTR bit lock can be decided/implemented separately.
A second phase would be to read/send/cache common xattrs on the client on first access to avoid extra RPCs. This will become increasingly important with clients, since SELinux and other xattr-heavy tools are becoming increasingly common.
If we begin to cache xattrs on the client, we should remove the special-case handling of security.capability in ll_setxattr_common() which was added as a hack to address a serious performance problem.
Attachments
Issue Links
- is related to
-
LU-2869 extended attribute cache for Lustre
- Resolved
- Trackbacks
-
Lustre Community Development in Progress Features are being developed for future Lustre releases both at Whamcloud and by other organizations in the Lustre community. These will be eligible for inclusion in future Lustre releases as per our processes