7378 exported_lock held during nfs4 compound processing

Review Request #813 - Created Jan. 12, 2018 and updated

Marcel Telka
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

Marcel Telka
Marcel Telka
Review request changed

Change Summary:

Implemented changes I suggested here: https://illumos.topicbox.com/groups/developer/T38028833ac394eda




Revision 2 (+248 -153)

Show changes

Vitaliy Gusev

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"