Bug #11945

pool import performance regression due to repeated libshare initialization

Added by Dan McDonald 13 days ago. Updated 8 days ago.

nfs - NFS server and client
Start date:
Due date:
% Done:


Estimated time:


This is an independent part of the nfs-zone wad of diffs from Nexenta (NEX-16219). Less calls to initialization is better. :)



Updated by Dan McDonald 9 days ago

Thanks Joyce for the following:

A previous issue where on pool import libshare was being initialized per shared dataset in the pool, due to:
"7955 libshare needs to initialize only those datasets being modified by the consumer"
was resolved issue by initializing libshare at a higher level for ALL of the datasets being shared.
However, if libshare needs to be refreshed (due to some other operation invalidating its cache) the import reverts to per share initialization. This was first observed when the startup of svc:/network/nfs/server:default was triggered by the sharing of the first dataset, but it has been reproduced for testing by setting the sharenfs property on a dataset in another pool while the import is running.
With a large number of datasets in the pool being imported, the repeated libshare refresh is very, very expensive.
The resolution is that if libshare is already initialized for multiple shares (API_SELECTIVE) higher up the stack and it requires a refresh in the per-share functions lower down, the refresh will be performed once for all shares, instead of per share.
dtrace was used on before/after builds for verification & profiling.


Updated by Dan McDonald 8 days ago

This has been in illumos-nexenta since March of 2018, and is in the shipped-product NexentaStor 5.2.1.

commit 36ebdcae488d7b52d92897bd16e19c901c564f75
Author: Joyce McIntosh <>
AuthorDate: Thu Mar 1 10:18:07 2018 -0800
Commit: Joyce McIntosh <>
CommitDate: Thu Mar 1 13:35:10 2018 -0800

Also available in: Atom PDF