Hello, I came across what seems to be a scalability issue with snapshots in ZFS on Linux. When many snapshots are taken concurrently (I tried 400), it takes a long time (minutes) for each 'zfs snapshot' command to complete (although they all do execute concurrently). I believe I tracked down the problem to the invocation of zvol_create_minors(poolname) in zfs_ioc_snapshot() before the latter exits. A cursory look at the function seems to indicate that the call is there to facilitate the 'snapdev' feature that appears to create block devices for snapshots of zvols that have the snapdev=visible property set. It is surely seems nice to have read only devices created for snapshots automagically (if I understand the intent correctly). But it seems that scanning the pool namespace (including all the snapshots) is a bit of a heavy weight operation. A part of the issues appears to be that the callbacks from dmu_objset_find() take global zvol_state_lock. I have moved the __zvol_snapdev_hidden() from under the lock to limit the impact, but that did not address the problem sufficiently. It appears that just scanning all the snapshots of all the datasets in the pool while creating other snapshots and clones gets sufficiently slow for 400 zvols and 10,000 total snapshots. I believe dsl_dataset_snapshot() already calls zvol_create_minors() for the snapshots under processing. Does anyone know why it is necessary to perform the pool-wide scan in the end of zfs_ioc_snapshot() ? Best regards, Boris.
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
