Re: [Qemu-devel] [qcow2] how to avoid qemu doing lseek(SEEK_DATA/SEEK_HOLE)?

2017-02-08 Thread Stephane Chazelas
2017-02-08 15:27:11 +0100, Max Reitz: [...] > A bit of a stupid question, but: How is your performance when using > detect-zeroes=off? [...] I did try that. See: } Note that passing detect-zeroes=off or detect-zeroes=unmap (with } discard) doesn't help (even though FALLOC_FL_PUNCH_HOLE is } suppo

Re: [Qemu-devel] [qcow2] how to avoid qemu doing lseek(SEEK_DATA/SEEK_HOLE)?

2017-02-08 Thread Stephane Chazelas
2017-02-08 00:43:18 +0100, Max Reitz: [...] > Therefore, the patch as it is makes sense. The fact that said lseek() is > slow on ZFS is (in my humble opinion) the ZFS driver's problem that > needs to be fixed there. [...] For the record, I've mentioned the qemu performance implication at https://g

Re: [Qemu-devel] [qcow2] how to avoid qemu doing lseek(SEEK_DATA/SEEK_HOLE)?

2017-02-08 Thread Stephane Chazelas
2017-02-08 00:43:18 +0100, Max Reitz: [...] > OTOH, it may make sense to offer a way for the user to disable > lseek(SEEK_{DATA,HOLE}) in our "file" block driver. That way your issue > would be solved, too, I guess. I'll look into it. [...] Thanks Max, Yes, that would work for me and other users

Re: [Qemu-devel] [qcow2] how to avoid qemu doing lseek(SEEK_DATA/SEEK_HOLE)?

2017-02-02 Thread Stephane Chazelas
2017-02-02 16:23:53 +0100, Laszlo Ersek: [...] > You didn't mention what qcow2 features you use -- vmstate, snapshots, > backing files (chains of them), compression? > > Since commit 2928abce6d1d only modifies "block/qcow2.c", you could > switch / convert the images to "raw". "raw" still benefits

[Qemu-devel] [qcow2] how to avoid qemu doing lseek(SEEK_DATA/SEEK_HOLE)?

2017-02-02 Thread Stephane Chazelas
Hello, since qemu-2.7.0, doing synchronised I/O in a VM (tested with Ubuntu 16.04 amd64 VM) while the disk is backed by a qcow2 file sitting on a ZFS filesystem (zfs on Linux on Debian jessie (PVE)), the performances are dreadful: # time dd if=/dev/zero count=1000 of=b oflag=dsync 1000+0 record

[Qemu-devel] [Bug 595117] Re: qemu-nbd slow and missing "writeback" cache option

2010-12-10 Thread Stephane Chazelas
For the record, there's more on that bug at http://thread.gmane.org/gmane.linux.ubuntu.bugs.server/36923 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/595117 Title: qemu-nbd slow and missing "write

Re: [Qemu-devel] [Bug 595117] Re: qemu-nbd slow and missing "writeback" cache option

2010-07-07 Thread Stephane Chazelas
2010-06-24 00:16:03 -, Jamie Lokier: > Serge Hallyn wrote: > > The default of qemu-img (of using O_SYNC) is not very sensible > > because anyway, the client (the kernel) uses caches (write-back), > > (and "qemu-nbd -d" doesn't flush those by the way). So if for > > instance qemu-nbd is killed,

[Qemu-devel] Re: [Bug 595117] Re: qemu-nbd slow and missing "writeback" cache option

2010-06-17 Thread Stephane Chazelas
2010-06-16 20:36:00 -, Dustin Kirkland: [...] > Could you please send that patch to the qemu-devel@ mailing list? > Thanks! [...] Hi Dustin, it looks like qemu-devel is subscribed to bugs in there, so the bug report is on the list already. Note that I still consider it as a bug because: - s