With all ZFS-on-Linux versions I've ever tried, using zfs list
to list all snapshots of a filesystem or volum (zfs list -r -t snapshot -H -o name pool/filesystem
) always takes many orders of magnitude more time to run than ls .zfs/snapshot
, which is immediate:
$ time ls -1 /srv/vz/subvol-300-disk-1/.zfs/snapshot
[list of 1797 snapshots here]
real 0m0.023s
user 0m0.008s
sys 0m0.014s
# time zfs list -r -t snapshot -H -o name vz/subvol-300-disk-1
[same list of 1797 snapshots]
real 1m23.092s
user 0m0.110s
sys 0m0.758s
Is this bug specific to ZFS-on-Linux?
Can anybody with a Solaris or FreeBSD ZFS box perform a similar test (on a filesystem with hundreds of snapshots on spinning hard disks)?
Is there a workaround to get a quick list of snapshots for a volume, which by its nature does not have a .zfs
directory?
I've run the above test with ZFS-on-Linux 0.6.5.2-2-wheezy on kernel 2.6.32-43-pve x86_64 (Proxmox) but I've always seen this issue, both on older and newer ZFS and kernel versions.
Here are the pool stats:
# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
vz 25.2T 9.42T 15.8T - 5% 37% 1.00x ONLINE -
It contains 114 filesystems and 1 volume, each with hundreds of snapshots, as this is a zfs send
/ zfs recv
backup server.
Solution: zfs list
is slow because it fetches additional information, even if it's not displayed. The solution is adding both -o name -s name
, that is, using zfs list -t snapshot -o name -s name
zfs list -t snapshot
always takes many orders of magnitude more time to run thanls .zfs/snapshot
You're also comparing two completely different operations.
zfs list -t snapshot
enumerates all the ZFS snapshots on the system - and provides a lot of information about those snapshots, such as the amount of space used. Run that understrace
to see the system calls made.ls .zfs/snapshot
is just emitting a simple name list from a directory. There's nothing to do other than read the names - and provide nothing else.Snapshot operations are a function of the number of snapshots you have, RAM, disk performance and drive space. This would be a general ZFS issue, not something unique to the Linux variant.
The better question is: Why you have 1797 snapshots of a zvol? This is definitely more than recommended and makes me wonder what else is happening on the system.
People say "ZFS snapshots are free", but that's not always true.
While ZFS snaps don't have an impact on production performance, the high number you have clearly require disk accesses to enumerate.
Disk access time > RAM access time
, hence the order of magnitude difference.strace
output. Note the time per syscall and imagine how poorly it would scale with the number of snapshots in your filesystem.versus