[LU-2869] extended attribute cache for Lustre

• Type: Improvement
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.5.0
• Labels: patch xattr
• Assignee: James Nunez (Inactive)
• Reporter: Andrew Perepechko

Description

The patch implements an extended attribute cache for
a Lustre client. It is organized as a write-through
cache: reads are performed from cache, updates are sent
synchronously to the MDS. An additional inode bit
is added to protect the cache.

The patch itself will be uploaded shortly.

Issue Links

• is related to: LU-3795 replay-single test_58b test_58c: trusted.foo: No such attribute
• is related to: LU-3670 some trusted xattrs are not coherent on the client
• is related to: LU-3669 (mdt_xattr.c:178:mdt_getxattr()) ASSERTION( lu_object_assert_exists(&info->mti_object->mot_obj) ) failed:
• is related to: LU-549 Add xattr list/value cache on client
• is related to: LU-3583 LDLM support for atomic match_or_enqueue operation
• is related to: LU-10276 Revise what MDS_INODELOCK_XATTR protects
• is related to: LU-17238 negative xattr cache on client

Comments

[Alex Zhuravlev]

great. thanks!

[Andrew Perepechko]

not sure what kind of inconsistency FLXATTRLS can observe?

Like, setxattr "a=x", setxattr "b=y". An unlocked FLXATTRLS can pack "b=y" update without packing "a=x" because of update races.

any plans to make a patch to drop it?

I'll update http://review.whamcloud.com/#/c/7208/ with this fix in a while.

[Alex Zhuravlev]

not sure what kind of inconsistency FLXATTRLS can observe? any plans to make a patch to drop it?

[Andrew Perepechko]

Besides -ENOENT, due to races an FLXATTRLS user can get an inconsistent list of attribute names and values, which the object never had from another client viewpoint. But since there is no use case for that, the locking can be simply dropped.

[Alex Zhuravlev]

well, if this failure is -ENOENT, then it should be easy to check and skip? on the otherhand we carry this structure for every object in MDT cache. a bit expensive for such a case?

[Andrew Perepechko]

The semaphore was added to protect the case when the client does not take the XATTR lock and requests FLXATTRALL.
FLXATTRALL is implemented as getting the list and then getting the values, so setting/removing an xattr in the middle
can lead to failure. Currently, there is no FLXATTRLS user that does not take the XATTR lock, so there is no use
case for the semaphore being contended.

[Alex Zhuravlev]

can you explain why mot_xattr_sem is needed, please?

[James Nunez (Inactive)]

Landed for 2.5

[Andrew Perepechko]

Thanks, James!

[James Nunez (Inactive)]

The master branch should open for new features soon.