openzfs
tunables: remove legacy FreeBSD aliases
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 doubling up on them after so many years, and it's time for them to go.
I'd love an old FreeBSD hand or two to look over them though. FreeBSD generally doesn't churn much, so it wouldn't surprise me if there is critical code and documentation that relies on these to remain. I'm in no hurry to nuke anything in use; on the contrary, I'd like to find out and make sure it's properly documented and tested on our side. So please review this!
Description
Here's the list of names removed, with their "new" names on the right:
| old tunable name (removed) | available as |
|---|---|
| vfs.zfs.arc_max | vfs.zfs.arc.max |
| vfs.zfs.arc_min | vfs.zfs.arc.min |
| vfs.zfs.arc_free_target | vfs.zfs.arc.free_target |
| vfs.zfs.arc_no_grow_shift | vfs.zfs.arc.no_grow_shift |
| vfs.zfs.l2arc_write_max | vfs.zfs.l2arc.write_max |
| vfs.zfs.l2arc_write_boost | vfs.zfs.l2arc.write_boost |
| vfs.zfs.l2arc_headroom | vfs.zfs.l2arc.headroom |
| vfs.zfs.l2arc_headroom_boost | vfs.zfs.l2arc.headroom_boost |
| vfs.zfs.l2arc_feed_secs | vfs.zfs.l2arc.feed_secs |
| vfs.zfs.l2arc_feed_min_ms | vfs.zfs.l2arc.feed_min_ms |
| vfs.zfs.l2arc_noprefetch | vfs.zfs.l2arc.noprefetch |
| vfs.zfs.l2arc_feed_again | vfs.zfs.l2arc.feed_again |
| vfs.zfs.l2arc_norw | vfs.zfs.l2arc.norw |
| vfs.zfs.zfetch.max_distance | vfs.zfs.prefetch.max_distance |
| vfs.zfs.zfetch.max_idistance | vfs.zfs.prefetch.max_idistance |
| vfs.zfs.remove_max_segment | vfs.zfs.vdev.remove_max_segment |
| vfs.zfs.removal_suspend_progress | vfs.zfs.vdev.removal_suspend_progress |
| vfs.zfs.min_auto_ashift | vfs.zfs.vdev.min_auto_ashift |
| vfs.zfs.max_auto_ashift | vfs.zfs.vdev.max_auto_ashift |
| vfs.zfs.validate_skip | vfs.zfs.vdev.validate_skip |
| vfs.zfs.top_maxinflight | vfs.zfs.vdev.max_active |
| old stat name (removed) | available as |
|---|---|
| vfs.zfs.anon_size | kstat.zfs.misc.arcstats.anon_size |
| vfs.zfs.anon_metadata_esize | kstat.zfs.misc.arcstats.anon_evictable_metadata |
| vfs.zfs.anon_data_esize | kstat.zfs.misc.arcstats.anon_evictable_data |
| vfs.zfs.mru_size | kstat.zfs.misc.arcstats.mru_size |
| vfs.zfs.mru_metadata_esize | kstat.zfs.misc.arcstats.mru_evictable_metadata |
| vfs.zfs.mru_data_esize | kstat.zfs.misc.arcstats.mru_evictable_data |
| vfs.zfs.mru_ghost_size | kstat.zfs.misc.arcstats.mru_ghost_size |
| vfs.zfs.mru_ghost_metadata_esize | kstat.zfs.misc.arcstats.mru_ghost_evictable_metadata |
| vfs.zfs.mru_ghost_data_esize | kstat.zfs.misc.arcstats.mru_ghost_evictable_data |
| vfs.zfs.mfu_size | kstat.zfs.misc.arcstats.mfu_size |
| vfs.zfs.mfu_metadata_esize | kstat.zfs.misc.arcstats.mfu_evictable_metadata |
| vfs.zfs.mfu_data_esize | kstat.zfs.misc.arcstats.mfu_evictable_data |
| vfs.zfs.mfu_ghost_size | kstat.zfs.misc.arcstats.mfu_ghost_size |
| vfs.zfs.mfu_ghost_metadata_esize | kstat.zfs.misc.arcstats.mfu_ghost_evictable_metadata |
| vfs.zfs.mfu_ghost_data_esize | kstat.zfs.misc.arcstats.mfu_ghost_evictable_data |
| vfs.zfs.uncached_size | kstat.zfs.misc.arcstats.uncached_size |
| vfs.zfs.uncached_metadata_esize | kstat.zfs.misc.arcstats.uncached_evictable_metadata |
| vfs.zfs.uncached_data_esize | kstat.zfs.misc.arcstats.uncached_evictable_data |
| vfs.zfs.l2c_only_size | kstat.zfs.misc.arcstats.l2_size |
Note that there's still a handful of tunables in module/os/freebsd/zfs/sysctl_os.c that don't have "core" counterparts; those remain for the moment. I also haven't touched vfs.zfs.debugflags even though vfs.zfs.flags exists, because I think the former is a little smarter. I'll sort all these out another time.
How Has This Been Tested?
ZTS run in progress on FreeBSD 14.2-p1.
Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Performance enhancement (non-breaking change which improves efficiency)
- [x] Code cleanup (non-breaking change which makes code smaller or more readable)
- [ ] Quality assurance (non-breaking change which makes the code more robust against bugs)
- [x] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
- [ ] Documentation (a change to man pages or other documentation)
Checklist:
- [x] My code follows the OpenZFS code style requirements.
- [ ] I have updated the documentation accordingly.
- [ ] I have read the contributing document.
- [ ] I have added tests to cover my changes.
- [x] I have run the ZFS Test Suite with this change applied.
- [x] All commit messages are properly formatted and contain
Signed-off-by.
Huh, thanks. I need to fix my test rig some then, because it didn't throw those up (I mean yeah, the CI did, but I hadn't got into that yet). Cheers :)
I've just fixed couple things (systat and top) in FreeBSD base still using old names: https://cgit.freebsd.org/src/commit/?id=8aad1e6148d3389df100bb0391e2d3a909f26ecf .
Once https://cgit.freebsd.org/src/commit/?id=8aad1e6148d3389df100bb0391e2d3a909f26ecf lands we can go ahead and merge this.
Once https://cgit.freebsd.org/src/commit/?id=8aad1e6148d3389df100bb0391e2d3a909f26ecf lands we can go ahead and merge this.
@behlendorf It is in FreeBSD main already, and I'll merge it into stable branches tomorrow. Hope I'll be allowed to merge it into upcoming 14.3.
PS: Merged.
@amotin thanks for doing that!
I asked on socials and a couple of people pointed out that they have various old-style tunables set in various boot configs and such, so I'd like to stick this on hold for a moment while I go and find the right FreeBSD people to get some advice. We might be better to provide aliases or deprecation warnings, or FreeBSD might prefer to patch it themselves, or maybe it just gets documented around for 15. I still want to do this, but I don't wanna be a jerk and surprise anyone. So I've put the "blocked" tag on this, and I'll let you know what the plan is as soon as I can.
@behlendorf Unless anybody knows any specific issues, with us already branched 2.4 and FreeBSD branched stable/15, I'd say it is as good time to merge this as we ever get.
I haven't heard of anything specific. Agreed, now seems like a good time given where we're at in the release cycles.