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-3660 Lustre <p>With ldiskfs, the MDT can be mounted with <tt>-o noacl</tt> to disable POSIX ACL support. With ZFS, that option seems to have no effect, and clients are still able to set and honor ACLs. It would be desirable to be able to turn off ACLs, as they can be detrimental to performance. For example, the <tt>cp -a</tt> command tries to write the xattr <tt>system.posix_acl_access</tt> on every destination file, regardless of whether the source file has that attribute. The ACL update is handled synchronously on the MDT, so the request handler has to wait for a ZFS transaction group to sync. This can introduce significant latency on a busy MDS, effectively limiting the per-file copy rate to the txg sync rate. On ldiskfs, <tt>cp -a</tt> performance is significantly improved by disabling ACLs.</p> <p>(This performance problem is a separate issue that may be helped by integrating ZIL support in Lustre. Turning off ACLs is a temporary workaround.)</p> <p>LLNL-bug-ID: TOSS-2207</p> LU-3660

Can't disable ACL support with ZFS MDT

Bug Critical Resolved Fixed Lai Siyao Ned Bass llnl prz zfs Mon, 29 Jul 2013 23:42:29 +0000 Fri, 19 Sep 2014 02:17:58 +0000 Tue, 26 Aug 2014 15:29:59 +0000 Lustre 2.4.0 Lustre 2.7.0 Lustre 2.5.4 0 8 <p>Is there a reason that ACL updates are done synchronously on the MDS? I don't think there is a valid security rationale for this, since (AFAIK) chmod(), chown(), or chgrp() operations are not synchronous either, and they can have the same security impact as any ACL change. It would be far more beneficial to disable synchronous updates on the MDS entirely for this operation than to make them somewhat more efficient with the ZIL.</p> <p>I don't know why they're done synchronously. In fact my claim that it is synchronous is based on the observation that the request handler seems to block until the txg syncs, not on a close reading of the code. It think it's related to this comment, but it doesn't explain <em>why</em>.</p> <div class="code panel" style="border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;"><b>mdt_xattr.c:mdt_reint_setxattr()</b></div><div class="codeContent panelContent"> <pre class="code-java">334 /* Revoke all clients' lookup lock, since the access 335 * permissions <span class="code-keyword">for</span> <span class="code-keyword">this</span> inode is changed when ACL_ACCESS is 336 * set. This isn't needed <span class="code-keyword">for</span> ACL_DEFAULT, since that does 337 * not change the access permissions of <span class="code-keyword">this</span> inode, nor any 338 * other existing inodes. It is setting the ACLs inherited 339 * by <span class="code-keyword">new</span> directories/files at create time. */ 340 <span class="code-comment">/* We need revoke both LOOKUP|PERM lock here, see mdt_attr_set. */</span> 341 <span class="code-keyword">if</span> (!strcmp(xattr_name, XATTR_NAME_ACL_ACCESS)) 342 lockpart |= MDS_INODELOCK_PERM | MDS_INODELOCK_LOOKUP; </pre> </div></div> <p>Lai</p> <p>Could you please advise on this one?</p> <p>Thanks</p> <p>Peter</p> <p>Created <a href="https://jira.whamcloud.com/browse/LU-3671" title="why are permission changes synchronous?" class="issue-link" data-issue-key="LU-3671"><del>LU-3671</del></a> to discuss the synchronous behavior. This issue is to discuss whether we need a mechanism to disable ACL support with ZFS.</p> <p>Lowered priority to minor because disabling ACL support is not really an effective workaround to the performance issue described here. But, we should still decide if this should be fixed and document ACL functionality as it relates to ZFS backends.</p> <p>osd_conf_get() for zfs osd doesn't really get mount options from super_block like ldiskfs, but enables ACL by default. I'll see how to get it work.</p> <p>Lai's patch for this problem is at <a href="http://review.whamcloud.com/#/c/10850/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/10850/</a> .</p> <p>Landed for 2.7</p> Related LU-3671 Development Rank 1|hzvwmv: Rank (Obsolete) 9444 Severity