53a236f2c51d42a88c76edd5c7a654d5ffc6abc2
with more than a few images, 'rbd ls -l' gets rather slow compared to a simple 'rbd ls'. since we only need to check existing image names for finding a free one, the latter is sufficient. example with ~400 rbd images: $ time rbd ls -p ceph-vm > /dev/null real 0m0.027s user 0m0.012s sys 0m0.008s $ time rbd ls -l -p ceph-vm > /dev/null real 0m5.250s user 0m1.632s sys 0m0.584s a linked clone of two disks on the same setup accordingly also shows a massive speedup: $ time qm clone 1000 10000 -snap test create linked clone of drive scsi0 (ceph-vm:vm-1000-disk-2) clone vm-1000-disk-2: vm-1000-disk-2 snapname test to vm-10000-disk-1 create linked clone of drive scsi1 (ceph-vm:vm-1000-disk-1) clone vm-1000-disk-1: vm-1000-disk-1 snapname test to vm-10000-disk-2 real 0m11.157s user 0m3.752s sys 0m1.308s $ time qm clone 1000 10000 -snap test create linked clone of drive scsi1 (ceph-vm:vm-1000-disk-1) clone vm-1000-disk-1: vm-1000-disk-1 snapname test to vm-10000-disk-1 create linked clone of drive scsi0 (ceph-vm:vm-1000-disk-2) clone vm-1000-disk-2: vm-1000-disk-2 snapname test to vm-10000-disk-2 real 0m0.872s user 0m0.652s sys 0m0.096s Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Description
with PMEM support!
Languages
Perl
99.3%
Makefile
0.6%