https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-3670 Lustre <p>The value of trusted.link should change as hard links are added to files.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># llmount.sh # cd /mnt/lustre # touch f0 # getfattr -n trusted.link f0 # file: f0 trusted.link=0s3/HqEQEAAAAsAAAAAAAAAAAAAAAAAAAAABQAAAACAAAABwAAAAEAAAAAZjA= # getfattr -n trusted.link f0 | md5sum f0ea62a3d3c5efd8329b1147bf97ce7b - # ln f0 f1 # getfattr -n trusted.link f0 | md5sum f0ea62a3d3c5efd8329b1147bf97ce7b - # sys_lea f0 [0x200000007:0x1:0x0] 'f0' </pre> </div></div> <p>Before extended attribute caching landed the trusted.link attribute is updated and the interpreting the link EA has the expected result:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># cd /mnt/lustre # touch f0 # getfattr -n trusted.link f0 # file: f0 trusted.link=0s3/HqEQEAAAAsAAAAAAAAAAAAAAAAAAAAABQAAAACAAAABwAAAAEAAAAAZjA= # getfattr -n trusted.link f0 | md5sum f0ea62a3d3c5efd8329b1147bf97ce7b - # ln f0 f1 # getfattr -n trusted.link f0 | md5sum 53753efeb8ce17a87df257ee317c7b68 - # sys_lea f0 [0x200000007:0x1:0x0] 'f0' [0x200000007:0x1:0x0] 'f1' </pre> </div></div> <p>The lov xattrs appear to be immune to this issue since they are handled by special cases in ll_</p> {get,set} <p>xattr() but I did not verify this in all cases. Some other attributes (trusted.hsm) which are modified outside of the normal MDS_SETXATTR path are also affected.</p> LU-3670

some trusted xattrs are not coherent on the client

Bug Critical Resolved Fixed John Hammond John Hammond llite mdt patch xattr Tue, 30 Jul 2013 16:00:28 +0000 Thu, 26 Sep 2013 20:00:30 +0000 Thu, 26 Sep 2013 20:00:30 +0000 Lustre 2.5.0 Lustre 2.5.0 0 10 <p>It looks like the following extended attributes can be modified in the mdd or osd layer:</p> <p>XATTR_NAME_LMA "trusted.lma"<br/> XATTR_NAME_LINK "trusted.link"<br/> XATTR_NAME_ACL_DEFAULT "system.posix_acl_default"<br/> XATTR_NAME_ACL_ACCESS "system.posix_acl_access"<br/> XATTR_NAME_LOV "trusted.lov"<br/> XATTR_NAME_HSM "trusted.hsm"</p> <p>"trusted.link" updates require XATTR inode bit cancellation in mdt_reint_unlink, mdt_reint_link and mdt_reint_rename.<br/> I pushed <a href="http://review.whamcloud.com/#/c/7186/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/7186/</a> with fixes for XATTR_NAME_LINK, and will update the patch with HSM soon.</p> <p>Andrew, I was thinking it might be best for the trusted xattrs to bypass the cache. What do you think?</p> <p>John, I like this solution, since the original goal was to speed up samba clients. Trusted attr lookups seem unlikely.</p> <p>John, except that tools like SELinux depend heavily on trusted.* xattrs and will benefit significantly from the cache. I don't think many of them change very frequently, with the exception of .link being the possible exception (and not even that will change very often).</p> <p>SELinux uses "security.selinux" to store object contexts. Hopefully, it is not affected by that.</p> <p>One of the shortcomings of trusted.* filtering is that listxattr data cannot be cached as well.</p> <p>I updated the patch with xattr locking for HSM:<br/> mdt_swap_layouts, mdt_reint_setattr (via mdt_add_dirty_flag), mdt_mfd_close (vid mdt_hsm_release), mdt_hsm_state_set.</p> <p>Landed for 2.5</p> Related LU-2869 Development Rank 1|hzvwpr: Rank (Obsolete) 9458 Severity