Project

General

Profile

Bug #6327

devfsadm and bootadm taking long time for configs with large number of zvols

Added by Matthew Ahrens over 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
zfs - Zettabyte File System
Start date:
2015-10-13
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

There are several problems here:
1. when running 'bootadm update-archive' I see that lots of time is spent in newfs. The problem here is that this call is using libdiskmgt to verify that the lofi device is not being used by anybody. Since the lofi device was just created the use of libdiskmgmt here is unnecessary.
2. devzvol_readdir() traverses every snapshot.

I looked at removing the snapshots from /dev/zvol by making a change in the zvol code. This does improve things but doesn't it solve it completely. In my investigation I still saw that mkfs would still try to lstat() every zvol snapshot even though the device node did not exist.

Digging further I think the real solution is to change the dev subsystem to prevent both pseudo and the /dev/zvol links from being created.

This change adds a tunable which disables creation of /dev/zvol links for snapshots. By default, the behavior is not changed, but if you don't need to access zvol snapshots through /dev/zvol, you can disable them for a nice performance improvement.

History

#1

Updated by Electric Monk over 3 years ago

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

git commit 470bc2d6d44a4a70ed9403c0bce321333e897c31

commit  470bc2d6d44a4a70ed9403c0bce321333e897c31
Author: George Wilson <george.wilson@delphix.com>
Date:   2016-07-14T19:11:34.000Z

    6327 devfsadm and bootadm taking long time for configs with large number of zvols
    Reviewed by: Matthew Ahrens <mahrens@delphix.com>
    Reviewed by: Sebastien Roy <sebastien.roy@delphix.com>
    Reviewed by: Eric Schrock <eric.schrock@delphix.com>
    Reviewed by: Igor Kozhukhov <ikozhukhov@gmail.com>
    Reviewed by: Richard Elling <Richard.Elling@RichardElling.com>
    Reviewed by: Dan McDonald <danmcd@omniti.com>
    Approved by: Robert Mustacchi <rm@joyent.com>

Also available in: Atom PDF