zv_suspend_lock in zvol_open()/zvol_release()

[bprotopopov]

Acquire zv_suspend_lock on first open and last close only.

Signed-off-by: Boris Protopopov boris.protopopov@actifio.com

Description

zv_suspend_lock is being acquired in zvol_open()/zvol_release() unconditionally. This lock might be held for a long time across zvol_suspend()/zvol_resume() (e.g. during zfs recv), and therefore, it is desirable to avoid taking the lock, unless it is actually needed (at the time of the first open and last close).

Motivation and Context

Improve concurrency and latency of the zvol_open()/zvol_release() operations.

This is related to #6263 in that it might make it simpler to reproduce the issue.

How Has This Been Tested?

standard zfs-test run

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the ZFS on Linux code style requirements.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commit messages are properly formatted and contain Signed-off-by.
• Change has been approved by a ZFS on Linux member.

[bprotopopov]

Turned the crank to re-run the tests.

[bprotopopov]

It appears that SPL build is broken for Kernel.org kernel ?

[behlendorf]

@bprotopopov yes. The 4.12 kernel was released a week ago allowing more disruptive changes to be merged for the latest kernel. We'll need to look in to exact what changes and add some additional compatibility code to deal with it. Ignore those failures for now.

[bprotopopov]

zvol_misc_002_pos seems to be failing on Fedora 26 with

...
17:28:21.54 SUCCESS: mount /dev/zvol/testpool/testvol /var/tmp/testdir
17:28:22.14 write failed (-1), good_writes = 2, error: No space left on device[28]
...

[behlendorf]

#6297 was opened to track the zvol_misc_002_pos failures weren't seeing on the latest Fedora and Ubuntu kernels.

[bprotopopov]

@behlendorf could this be a test VM configuration issue (not enough disk space provisioned) ?

[behlendorf]

@bprotopopov when you get a moment could you please rebase this on master.

[bprotopopov]

@behlendorf will do

[sempervictus]

This has run in our test cloud for a couple of weeks - along with the zil pipelining, zvol backed cinder ops are noticeably snappier.

[bprotopopov]

rebased on master