Am 01.03.21 um 11:13 schrieb Stefan Reiter:
On 3/1/21 11:06 AM, Fabian Ebner wrote:
Am 01.03.21 um 10:54 schrieb Stefan Reiter:
On 3/1/21 10:42 AM, Fabian Ebner wrote:
Moving to Ceph is very slow when bs=1. Instead, use the biggest
possible power
of two <= 1024. At the moment our EFI image sizes are multiples of
1024, so
just using 1024 wouldn't be a problem, but this feels more
future-proof.
Signed-off-by: Fabian Ebner <f.eb...@proxmox.com>
---
I did not see an way for 'qemu-img dd' to use a larger blocksize
while still
specifying the exact total size if it is not a multiple of the
blocksize.
Could it make sense to just set the block size equal to the image
size with count=1 ? Since the images will always be very small anyway...
Note that AAVMF_VARS.fd is 64 MiB. Are blocksizes that big a good idea?
That'd be too much, but the VARS file shouldn't be copied anyway? Only
the efidisk attached to the VM?
AFAICT that's the file used for the EFI disk.
PVE/QemuServer.pm | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index f401baf..e579cdf 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -6991,7 +6991,15 @@ sub clone_disk {
# that is given by the OVMF_VARS.fd
my $src_path = PVE::Storage::path($storecfg, $drive->{file});
my $dst_path = PVE::Storage::path($storecfg, $newvolid);
- run_command(['qemu-img', 'dd', '-n', '-O', $dst_format,
"bs=1", "count=$size",
+
+ # Ceph doesn't like too small blocksize, see bug #3324
+ my $bs = 1;
+ while ($bs < $size && $bs < 1024 && $size % $bs == 0) {
+ $bs *= 2;
+ }
+ my $count = $size / $bs;
+
+ run_command(['qemu-img', 'dd', '-n', '-O', $dst_format,
"bs=$bs", "count=$count",
"if=$src_path", "of=$dst_path"]);
} else {
qemu_img_convert($drive->{file}, $newvolid, $size,
$snapname, $sparseinit);
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
