Having 'kern.maxvnodes' higher than 'kern.maxfiles' mitigates a scenario
where some processes can eat up all vnodes in the system, causing
a deadlock, as long as the kernel itself does not create too many vnodes
without creating some file descriptor in some process' FD table. A very
small percentage (~0.6%) of excess vnodes at infinity, coupled with
a large difference near the origin, should cover basic cases more than
enough. Note however that this measure can be defeated, e.g., by using
nullfs mounts with non-trivial file hierarchies.
Details
Details
- Reviewers
markj emaste - Commits
- rG6b6d6448feff: vfs: vntblinit(): Raise default 'kern.maxvnodes' higher than 'kern.maxfiles'
rGa6b05a35ce3c: vfs: vntblinit(): Raise default 'kern.maxvnodes' higher than 'kern.maxfiles'
rGe9baf472a6d2: vfs: vntblinit(): Raise default 'kern.maxvnodes' higher than 'kern.maxfiles'
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
An alternative to D50125 and D50311. Given the current automatic tuning numbers, though, I don't think raising the number of vnodes is necessary, I'd go for D50311 (lowering kern.maxfiles) rather than this one, as I suspect it is well enough for today's machines and software. The change here is just the most conservative, while ensuring that the number of files remains lower then the number of vnodes by default (but here, contrary to D50125, the administrator is still free to override that).