This is just an import of the work done here: http://cr.illumos.org/~webrev/sensille/exported_lock/
7378 exported_lock held during nfs4 compound processing
Review Request #813 — Created Jan. 12, 2018 and updated
Traditionally, rfs4_compound() holds a read lock on exported_lock during the processing of the compound request. The processing of some OPs might take several seconds. In our case, writes to a zfs filesystem can take very long if the filesystem is at quota. In this case, zfs waits for the next txg to free some space. This becomes problematic should someone need a write lock, like share(). If there is a pending writer, it has to wait for all existing readers to complete. During this time, all new readers also have to wait, effectively rendering nfs4 service unresponsive. The aim is to only acquire the exported_lock during nfs4 processing when needed.
Implemented changes I suggested here: https://illumos.topicbox.com/groups/developer/T38028833ac394eda
Revision 2 (+248 -153)
One thing I am concerned - performance metrics. Each PUTFH and LOOKUP (and some others) will
produce twice mutex hold and mutex release - 4 atomic operations. And NFS4 can have a lot of
operations in a request. Additionally note, rw-lock is very heavy (in comparision to plain mutex).
I suppose after-patch behaviour was not implemented intentionally
and original comment has a piece of description for that:
"since NFS4 breaks fundamental assumptions in the exi_count design"