Rob 💚

Ok so, when #FreeBSD switched #ZFS to #OpenZFS in 13.0, a lot of sysctl knobs got new names, and the old ones retained as aliases. I now want to get rid of them, but I don't know how deep they go in code, tools, documentation and oral histories.

Since I'm here for code cleanup and not to ruin anyone's day, I could use an assist from old FreeBSD+ZFS boffins. Please review https://github.com/openzfs/zfs/pull/17375 and let me know if there are any that would be bad to remove, and why. Thank you!

tunables: remove legacy FreeBSD aliases by robn · Pull Request #17375 · openzfs/zfs

Motivation and Context These are old pre-OpenZFS tunable names that have long been available via either conventional ZFS_MODULE_PARAM tunables or through kstats. It seems there's no point doubl...

GitHub
May 25, 2025 at 12:43amWeb
Show threadTomAokiMay 25, 2025

@robn
I don't have GitHub account, so replying here.

Not sure it's trivial enough or not, but wouldn't it nice if this deletions are done in 3 steps, like below in single commit per step?
Step1: Implement new SYSCTL macro to create alias of
any sysctl/tunable node (i.e., SYSCTL_ALIAS).
Step2: Use it for to-be-removed nodes.
Step3: Actually remove now-actually-alias old nodes.

This kind of renaming could happen in the future. So having clear way like
Step1: Add new node as usual and make existing
to-be-deleted ones alias of the new one.
Step2: In next or later *.0-Release, search and delete aliases
to avoid POLA violations within single stable branch.

This way, the 2nd step would become trivial (look for SYSCTL_ALIAS).

#FreeBSD #OpenZFS #SYSCTL

Show threadRob 💚May 25, 2025
@TomAoki the aliases have existed since openzfs 2.0 / freebsd 13.0. this is the deleting part.
Show threadTomAokiMay 25, 2025

@robn
My point is that making clear way for the next time.
I think this can be a quite good example for the future.
So in this specific case, I'm not at all objecting the deletion itself.

But (I've overlooked in my previous toot) deprecation notice period would be wanted for admins to prepare.
With commit for deprecation notice first (deleted at 15.0-Release), admins can consider skipping 15.0 to get enough time or go for 15.0 as it is easy to deploy all computers to be upgraded they maintain.

Show threadRob 💚May 25, 2025

@TomAoki ahh, I see what you mean. yeah, I'm working on deprecation policy within OpenZFS at the moment as well. one of the challenges we have is that we also don't really have the tools to express a deprecation in code. I'm building those, and this change is part of a cleanup precursor to that. so it's all interrelated.

but, it will all be a lot easier if I can start as close to a clean sheet as possible, thus the ask!

Show threadTomAokiMay 25, 2025
@robn
Just an idea (I'm not yet enough familiar with macros used for SYSCTLs), but what I've imagined is something like
SYSCTL_ALIAS(struct sysctl_oid_list *original, struct sysctl_oid_list *alias)
expanded to the same definition with original except for parent and name.
Not sure it can be implemented trivially or not (or even possible or not).
This way, defining new oid as usual and make old oid to be alias, anyone want to prune old deprecated oids later simply need to grep SYSCTL_ALIAS and pick the actual target.
Maybe needs discussion at freebsd-arch ML and/or somewhere else.
Show threadMichael DexterMay 25, 2025
@robn Is this something that might settle down in time for 15.0-RELEASE?
Show threadGarrett WollmanMay 25, 2025
@robn So the ones we set (as tunables) are vfs.zfs.scrub_limit, vfs.zfs.vdev.max_pending, and vfs.zfs.dirty_data_max_max, at least on one server I checked. The ones we set as sysctls are vfs.zfs.dirty_data_max, vfs.zfs.top_maxinflight, vfs.zfs.vdev.aggregation_limit, vfs.zfs.resilver_delay, and vfs.zfs.dmu_offset_next_sync. I haven't checked to see whether any of these actually still need to be tuned at this point.