Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

List snapshots separately from volumes+filesystems #151

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
2 participants

calmh commented Dec 4, 2012

Listing snapshots with full properties takes a significant amount of
time, increasing the time for a 'vmadm list' from less than a second to
almost a minute on some systems. Since we're really only interested in
the snapshot names, issue a separate 'zfs list' for just that and merge
the data afterwards.

You might hate declaring a named function in the middle/end of another function. I did it that way to minimize the amount of changes and make the diff easier to review. If you want this refactored differently I'd be happy to do so.

The patched VM.js Works For Me(tm), but I'm not entirely sure where the snapshot data is used. I'm currently building and installing a system to run the test suite on, if that fails I'll retract the pull request or fix it.

calmh added some commits Dec 4, 2012

REFACTOR: List snapshots separately from volumes+filesystems
Listing snapshots with full properties takes a significant amount of
time, increasing the time for a 'vmadm list' from less than a second to
almost a minute on some systems. Since we're really only interested in
the snapshot names, issue a separate 'zfs list' for just that and merge
the data afterwards.
Owner

joshwilsdon commented Dec 9, 2012

We actually need both name and creation fields. On your system with lots of snapshots, is doing:

zfs list -H -p -r -t snapshot -o name,creation

stil quick?

calmh commented Dec 10, 2012

Yeah, it looks to be about the same (timing and stuff from my system below), also the total time varies quite a bit. It does not seem worse than what I suggested, at least.

It might be that I'm running a little too much kvm on that system and starving the ARC currently, slowing things down more than necessary. In general, it seems expensive to list all the snapshots so while it's nice to have all the data available up front in VM.js, maybe that's something to keep in mind. Grabbing less data seems better though. For me (a non-SDC user...) the most common vmadm commands are list, stop, start, reboot, neither of which needs the snapshot data i think?

[root@00-25-90-38-94-04 ~]# time zfs list -H -p -r -t snapshot -o name,quota,volsize,mountpoint,type,compression,recsize,volblocksize,zoned zones >/dev/null

real    0m22.616s
user    0m0.380s
sys     0m0.909s
[root@00-25-90-38-94-04 ~]# time zfs list -H -p -r -t snapshot -o name,creation zones >/dev/null

real    0m13.216s
user    0m0.364s
sys     0m0.752s
[root@00-25-90-38-94-04 ~]# time zfs list -H -p -r -t snapshot -o name zones >/dev/null

real    0m13.690s
user    0m0.353s
sys     0m0.764s
[root@00-25-90-38-94-04 ~]# zpool status
  pool: zones
 state: ONLINE
  scan: scrub repaired 0 in 5h33m with 0 errors on Tue Dec  4 14:52:48 2012
config:

        NAME                       STATE     READ WRITE CKSUM
        zones                      ONLINE       0     0     0
          mirror-0                 ONLINE       0     0     0
            c0t50014EE25B7FC628d0  ONLINE       0     0     0
            c0t50014EE205CF84F8d0  ONLINE       0     0     0
          mirror-1                 ONLINE       0     0     0
            c0t50014EE205CF7101d0  ONLINE       0     0     0
            c0t50014EE206561484d0  ONLINE       0     0     0
          mirror-3                 ONLINE       0     0     0
            c0t50014EE2B0D583F5d0  ONLINE       0     0     0
            c0t50014EE25B7CCB38d0  ONLINE       0     0     0
        logs
          c2t1d0                   ONLINE       0     0     0
          c2t2d0                   ONLINE       0     0     0

errors: No known data errors
[root@00-25-90-38-94-04 ~]# time vmadm list
UUID                                  TYPE  RAM      STATE             ALIAS
183b9ce8-38c6-460b-a5d1-9bb139be0f34  OS    1024     running           zcube
1bbb6dd3-6abd-47b9-8485-a7afe0b727d5  OS    1024     running           zafps
556004f2-36ec-4483-8e1e-5af188f0db7c  KVM   1024     running           unifi
8061c37a-5ec3-47e8-80d7-da9fa204fde1  OS    1024     running           zmailbk
8491ba2d-1ffc-4219-879d-d8f7384780d9  KVM   1024     running           zabbix
b2535e73-0892-4183-9e02-0255c6dde661  OS    1024     running           zbackup
ba1f8d92-2ca2-4f01-9939-fa2de11a535e  OS    1024     running           zlogin
e39c6382-3c22-4896-95b7-3e6515a6b26e  OS    1024     running           zpuppet
0d6e2251-aa11-452b-afb7-e43c8e7bfe1c  KVM   1536     running           plex
7dc0f886-5faa-4534-a68e-8277e167464e  KVM   2048     running           psm
08e1d3b2-597a-4d29-b41a-f51f3971d94c  KVM   4096     running           github
bc3d93e3-ee95-471a-8341-02881794fcfa  OS    32768    running           zbuilder

real    0m44.618s
user    0m0.614s
sys     0m1.200s

@calmh calmh closed this Oct 8, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment