Differential D34944

geli: Add a chicken switch for unmapped I/O
ClosedPublic
Actions

Authored by markj on Apr 18 2022, 5:30 PM.

Details

Reviewers

asomers

Group Reviewers

manpages

Commits

rG081b4452a758: geli: Add a chicken switch for unmapped I/O

Summary

We have a report of a panic in GELI that appears to go away when
unmapped I/O is disabled. Add a tunable to make such investigations
easier in the future. No functional change intended.

PR: 262894

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 45206
Build 42094: arc lint + arc unit

Event Timeline

markj created this revision.Apr 18 2022, 5:30 PM

Herald added a reviewer: manpages. · View Herald TranscriptApr 18 2022, 5:30 PM

Herald added a subscriber: imp. · View Herald Transcript

markj requested review of this revision.Apr 18 2022, 5:30 PM

Harbormaster completed remote builds in B45206: Diff 105113.Apr 18 2022, 5:30 PM

LGTM, but see my comment in the PR. I doubt unmapped I/O is actually being used.

This revision is now accepted and ready to land.Apr 18 2022, 5:47 PM

Closed by commit rG081b4452a758: geli: Add a chicken switch for unmapped I/O (authored by markj). · Explain WhyApr 18 2022, 9:56 PM

This revision was automatically updated to reflect the committed changes.

markj added a commit: rG081b4452a758: geli: Add a chicken switch for unmapped I/O.

pauamma_gundo.com added a subscriber: pauamma_gundo.com.Apr 18 2022, 10:44 PM

pauamma_gundo.com added inline comments.

lib/geom/eli/geli.8
889	Isn't that what debug.* is for? In 14.x website sysctl(3), I see: Name Next Level Names Description CTL_DEBUG <sys/sysctl.h> Debugging CTL_VFS <sys/mount.h> File system CTL_HW <sys/sysctl.h> Generic CPU, I/O CTL_KERN <sys/sysctl.h> High kernel limits which would make debug.* less POLA-y than kern.* IMO. (If the definition of kern.* changed since sysctl(3) was last updated, then it needs to be made current.)

markj added inline comments.Apr 18 2022, 10:55 PM

lib/geom/eli/geli.8
889	In principle yes, but I think that ship has sailed a long time ago. As far as I know there are no strict rules governing where in the tree a new sysctl should go, and different subsystems have different conventions. Lots of subsystems have a single sysctl rooted somewhere, and I think the debug MIB is typically used when there isn't an existing sysctl tree to hang things off of. Here I wanted to keep things locally consistent: all existing GELI sysctls live under kern.geom.eli, and most will only be used when trying to debug functionality or performance problems anyway.