Project

General

Profile

Actions

Bug #11945

closed

pool import performance regression due to repeated libshare initialization

Added by Dan McDonald about 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
nfs - NFS server and client
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

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


Related issues

Related to illumos gate - Bug #7955: libshare needs to initialize only those datasets being modified by the consumerClosedPrakash Surya2017-03-09

Actions
Actions #1

Updated by Dan McDonald about 4 years 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.

Actions #2

Updated by Dan McDonald about 4 years 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

Actions #3

Updated by Electric Monk about 4 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit b8dc1b43d204b714c2fda8dd4efd67de0c671db6

commit  b8dc1b43d204b714c2fda8dd4efd67de0c671db6
Author: Joyce McIntosh <joyce.mcintosh@nexenta.com>
Date:   2019-12-02T21:53:49.000Z

    11945 pool import performance regression due to repeated libshare initialization
    Reviewed by: Sanjay Nadkarni <sanjay.nadkarni@nexenta.com>
    Reviewed by: Evan Layton <evan.layton@nexenta.com>
    Reviewed by: Dan McDonald <danmcd@joyent.com>
    Reviewed by: Jason King <jason.brian.king@gmail.com>
    Approved by: Garrett D'Amore <garrett@damore.org>

Actions #4

Updated by Marcel Telka about 4 years ago

  • Related to Bug #7955: libshare needs to initialize only those datasets being modified by the consumer added
Actions

Also available in: Atom PDF