Change Details

The intent is to allow for vnode inspection where the result is validated with sequence counters, thus allowing to elide taking any locks. Lockless lookup being the primary beneficiary. Anything pertaining to a lookup -- vnode's parent, filesystems mounted on top or any permissions -- result in modification of the counter. One giant hole is lack of support for rename, which given the current API contract comes from filesystems wishing to utilize the feature. 2 other approaches: - integration with the vnode lock -- does not work since vnodes get notoriously relocked mid-VOPs - integration with wirte suspension -- would require special casing for rename, but would also require special casing on close and actual writes to the vnode, none of which do anything invalidate the lookup. the only real overlap is in setfacl etc., but that can be easily covered with pre/post hooks.

The intent is to allow for vnode inspection where the result is validated with sequence counters, thus allowing to elide taking any locks. Lockless lookup being the primary beneficiary. Anything pertaining to a lookup -- vnode's parent, filesystems mounted on top or any permissions -- result in modification of the counter. One giant hole is lack of support for rename, which given the current API contract comes from filesystems wishing to utilize the feature. As explained in vop_rename_pre, they re-lookup and can end up operating on different vnodes than passed in. 2 other approaches: - integration with the vnode lock -- does not work since vnodes get notoriously relocked mid-VOPs - integration with wirte suspension -- would require special casing for rename, but would also require special casing on close and actual writes to the vnode, none of which do anything invalidate the lookup. the only real overlap is in setfacl etc., but that can be easily covered with pre/post hooks.

The intent is to allow for vnode inspection where the result is validated with sequence counters, thus allowing to elide taking any locks. Lockless lookup being the primary beneficiary. Anything pertaining to a lookup -- vnode's parent, filesystems mounted on top or any permissions -- result in modification of the counter. One giant hole is lack of support for rename, which given the current API contract comes from filesystems wishing to utilize the feature. As explained in vop_rename_pre, they re-lookup and can end up operating on different vnodes than passed in. 2 other approaches: - integration with the vnode lock -- does not work since vnodes get notoriously relocked mid-VOPs - integration with wirte suspension -- would require special casing for rename, but would also require special casing on close and actual writes to the vnode, none of which do anything invalidate the lookup. the only real overlap is in setfacl etc., but that can be easily covered with pre/post hooks.