Page MenuHomeFreeBSD

vfs: fix vnlru marker handling for filtered/unfiltered cases

Authored by mjg on Mar 18 2021, 2:08 PM.



The global list has a marker with an invariant that free vnodes are placed somewhere past that. A caller which performs filtering (like ZFS) can move said marker all the way to the end, across free vnodes which don't match. Then a caller which does not perform filtering will fail to find them. This makes vn_alloc_hard sleep for 1 second instead of reclaiming, resulting in significant stalls.

Fix the problem by requiring an explicit marker by callers which do filtering.

As a temporary measure extend vnlru_free to restart if it fails to reclaim anything.

MFC: immediately

Test Plan

Tested by the user which reported the problem here

Diff Detail

rG FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

mjg requested review of this revision.Mar 18 2021, 2:08 PM
mjg edited the summary of this revision. (Show Details)
mjg edited the test plan for this revision. (Show Details)

Your logic to reset the marker from head only triggers if there were no vnode (try)reclaimed at all. Should it occur even if some vnode was tryrecycled, but target not met?


I don't think it's worthwhile. In base only zfs can run into the problem, so addressing this would be a nop for this case. For any other case, if there are real problems there will be repeated calls and they will make progress.


.. since the marker got wrapped around

This revision is now accepted and ready to land.Mar 18 2021, 2:50 PM