Lower default 'maxfiles' to stay under default 'maxvnodes'
AbandonedPublic
Actions

Authored by olce on Mon, May 12, 1:18 PM.

Details

Reviewers

markj
kib

Summary

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 (~50k), 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.

This change divides by 2 the previous 'maxfiles' value, which we suspect
will not be a problem in practice, as 'maxfiles' was before this change
already 130k for a 4GB machine, 524k for 16GB and 1M for 32GB (this
computation is purely linear).

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 64104
Build 60988: arc lint + arc unit

Event Timeline

olce created this revision.Mon, May 12, 1:18 PM

Herald added a subscriber: imp. · View Herald TranscriptMon, May 12, 1:18 PM

olce requested review of this revision.Mon, May 12, 1:18 PM

Harbormaster completed remote builds in B64104: Diff 155330.Mon, May 12, 1:18 PM

olce added a parent revision: D50310: vfs: vntblinit(): Rework comments on the computation of 'kern.maxvnodes'.Mon, May 12, 1:19 PM

An alternative to D50125.

The objections to the previous review are equally applicable to this one.

If you need to pace a misbehaving app, apply individual limits as a workaround, or fix the code.

Again, my position with all tweaks to the limits is that it is for local system administration, not for the system policy. Ideally, we should have defaults to be infinite and return ENOMEM if resource cannot be acquired. maxvnodes is just sizing the cache, it is not about policy.

In D50311#1147819, @kib wrote:

If you need to pace a misbehaving app, apply individual limits as a workaround, or fix the code.

I've already answered this in D50125, we have a system problem here.

Again, my position with all tweaks to the limits is that it is for local system administration, not for the system policy. Ideally, we should have defaults to be infinite and return ENOMEM if resource cannot be acquired. maxvnodes is just sizing the cache, it is not about policy.

I agree, but we don't live in an ideal world. Pending a rework of these mechanisms, this mitigation, however imperfect it is, is still better than nothing.

olce mentioned this in D50314: vfs: vntblinit(): Raise default 'kern.maxvnodes' higher than 'kern.maxfiles'.Mon, May 12, 7:07 PM

Chosen alternative is D50314.