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-11706 Lustre <p>The proposal is to make a sysfs/procfs accessible flag for "experimental features" whatever is considered not stable enough for use in production at current state of development . </p> LU-11706

create a lustre tunable to enable/disable experimental features

Improvement Major Resolved Won't Fix Alexander Zarochentsev Alexander Zarochentsev patch Tue, 27 Nov 2018 15:10:10 +0000 Fri, 9 Apr 2021 20:00:26 +0000 Fri, 9 Apr 2021 20:00:26 +0000 Upstream 0 7 <p>It probably makes more sense to have a per-feature tunable. Otherwise, it wouldn't be possible to enable some of the experimental features without enabling all of them. </p> <p>I think in some cases, it may be desirable to disable features even long after they are not experimental, for administrative reasons or to maintain compatibility with older clients. <br/> When you speak of features, do you mean being able to turn on/off <tt>OBD_CONNECT_&#42;</tt> flags, or something else? Some features (e.g. DNE1/2) have /proc tunables to enable and disable their usage, but not all of them.</p> <p>Do you have a specific feature in mind?</p> <p>I am wondering if this suggestion is driven from features landed under our former process? Nowadays we maintain topic branches to keep larger features isolated from production releases until they are deemed ready. </p> <p>Alexander Zarochentsev (c17826@cray.com) uploaded a new patch: <a href="https://review.whamcloud.com/33729" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/33729</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11706" title="create a lustre tunable to enable/disable experimental features" class="issue-link" data-issue-key="LU-11706"><del>LU-11706</del></a> libcfs: enable_experimental_features<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 1cc1f15bd044ab1d97b4ece2141c36ebbc5d60d1</p> <p>Peter,</p> <blockquote><p>I am wondering if this suggestion is driven from features landed under our former process? </p></blockquote> <p>probably yes, it is like tech preview features in 2.7. There was no mechanism to restrict users from using striped dirs, for example. If your current process does not include "preview" features into releases, this "enable_experimental_features" flag is not needed, at least in this "global" form.</p> <p>Andreas,</p> <blockquote><p>When you speak of features, do you mean being able to turn on/off OBD_CONNECT_* flags, or something else?</p></blockquote> <p>I guess it depends on what feature needs to disabled/enabled. I submitted to gerrit only a generic part of the patch, b/c whamcloud may have a different view which features are experimental. It did include disabling for cross-target renames due to <a href="https://jira.whamcloud.com/browse/LU-11549" title="Unattached inodes after 3 min racer run." class="issue-link" data-issue-key="LU-11549"><del>LU-11549</del></a> and <a href="https://jira.whamcloud.com/browse/LU-11446" title="ldiskfs inodes nlink mismatch with DNE" class="issue-link" data-issue-key="LU-11446">LU-11446</a> .</p> <blockquote> <p>There was no mechanism to restrict users from using striped dirs, for example.</p></blockquote> <p>But there <b>is</b> a mechanism to restrict users from using striped dirs, and it was disabled by default, so only root could use it. It has been available since 2.4.0 (patch <a href="http://review.whamcloud.com/5442" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5442</a>). That is:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>lctl get_param mdt.*.enable* mdt.myth-MDT0000.enable_remote_dir=0 mdt.myth-MDT0000.enable_remote_dir_gid=0 </pre> </div></div> <p>This allows enabling/disabling remote/striped directories, and if it is enabled only allow specific groups (e.g. <tt>root</tt> or <tt>admin</tt> or <tt>wheel</tt>) to use it. In 2.12 there is a separate <tt>mdt.&#42;.enable_striped_dir</tt> tunable (patch <a href="https://review.whamcloud.com/24498" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/24498</a>), though it is changed to allow remote and striped directories for regular users by default.</p> <p>I'm not against adding tunables to enable/disable specific features, but I think having a generic "experimental" tunable doesn't make sense - it doesn't provide users/admins any idea what it is protecting, and it is too coarse-grained to be useful to ever enable it. If you want to add a tunable to disable cross-MDT rename (at least to return <tt>-EXDEV</tt> in that case, so that userspace will copy the file itself) then I'd be OK with that. Of course, fixing the actual bugs would be better, and there is definitely a fairly clear proposal in <a href="https://jira.whamcloud.com/browse/LU-11446" title="ldiskfs inodes nlink mismatch with DNE" class="issue-link" data-issue-key="LU-11446">LU-11446</a> on how that could be done.</p> <p>I think it is better to have clear tunables for each feature separately. As you wrote, what is an "experimental feature" depends on the release and may change over time, so it is better to have a tunable for each one separately. This is also useful even after a release, since features that may appear stable during testing or under some workloads may expose problems under other workloads even long afterward. Having a configuration tunable available to turn a feature off at runtime is always nice to have to allow a system to keep running in that case. </p> <p>The only thing that I could think of that might be worthwhile to have a "generic" interface for would be to turn off "OBD_CONNECT" feature flags at mount time or runtime. That would allow easier testing of feature interop, and give a built-in way to disable many features covered by those flags. It wouldn't be enough to cover all features, but might be useful. </p> Related LU-11446 LU-11549 Development Rank 1|i006zb: Rank (Obsolete) 9223372036854775807