[LU-11706] create a lustre tunable to enable/disable experimental features

• Status: Resolved
• Project: Lustre
• Affects Version/s: Upstream
• Type: Improvement
• Priority: Major
• Reporter: Alexander Zarochentsev
• Assignee: Alexander Zarochentsev
• Resolution: Won't Fix
• Labels: patch

Description

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 .

Issue Links

• is related to: LU-11446 ldiskfs inodes nlink mismatch with DNE
• is related to: LU-11549 Unattached inodes after 3 min racer run.

Comments

[Andreas Dilger]

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.

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.
When you speak of features, do you mean being able to turn on/off OBD_CONNECT_* flags, or something else? Some features (e.g. DNE1/2) have /proc tunables to enable and disable their usage, but not all of them.

Do you have a specific feature in mind?

[Peter Jones]

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. 

[Gerrit Updater]

Alexander Zarochentsev ([e-mail]) uploaded a new patch: https://review.whamcloud.com/33729
Subject: LU-11706 libcfs: enable_experimental_features
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 1cc1f15bd044ab1d97b4ece2141c36ebbc5d60d1

[Alexander Zarochentsev]

Peter,

I am wondering if this suggestion is driven from features landed under our former process?

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.

Andreas,

When you speak of features, do you mean being able to turn on/off OBD_CONNECT_* flags, or something else?

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 LU-11549 and LU-11446 .

[Andreas Dilger]

There was no mechanism to restrict users from using striped dirs, for example.

But there is 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 http://review.whamcloud.com/5442). That is:

lctl get_param mdt.*.enable*
mdt.myth-MDT0000.enable_remote_dir=0
mdt.myth-MDT0000.enable_remote_dir_gid=0

This allows enabling/disabling remote/striped directories, and if it is enabled only allow specific groups (e.g. root or admin or wheel) to use it. In 2.12 there is a separate mdt.*.enable_striped_dir tunable (patch https://review.whamcloud.com/24498), though it is changed to allow remote and striped directories for regular users by default.

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 -EXDEV 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 LU-11446 on how that could be done.

[Andreas Dilger]

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.

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.