From: Nir Soffer <nirsof@gmail.com>
To: qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Nir Soffer <nsoffer@redhat.com>,
qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: [PATCH] block: file-posix: Fail unmap with NO_FALLBACK on block device
Date: Sat, 13 Jun 2020 20:08:26 +0300 [thread overview]
Message-ID: <20200613170826.354270-1-nsoffer@redhat.com> (raw)
Punching holes on block device uses blkdev_issue_zeroout() with
BLKDEV_ZERO_NOFALLBACK but there is no guarantee that this is fast
enough for pre-zeroing an entire device.
Zeroing block device can be slow as writing zeroes or 100 times faster,
depending on the storage. There is no way to tell if zeroing it fast
enough. The kernel BLKDEV_ZERO_NOFALLBACK flag does not mean that the
operation is fast; it just means that the kernel will not fall back to
manual zeroing.
Here is an example converting 10g image with 8g of data to block device:
$ ./qemu-img info test.img
image: test.img
file format: raw
virtual size: 10 GiB (10737418240 bytes)
disk size: 8 GiB
$ time ./qemu-img convert -f raw -O raw -t none -T none -W test.img /dev/test/lv1
Before:
real 1m20.483s
user 0m0.490s
sys 0m0.739s
After:
real 0m55.831s
user 0m0.610s
sys 0m0.956s
Signed-off-by: Nir Soffer <nsoffer@redhat.com>
---
block/file-posix.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/block/file-posix.c b/block/file-posix.c
index 3ab8f5a0fa..cd2e409184 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1621,6 +1621,16 @@ static int handle_aiocb_write_zeroes_unmap(void *opaque)
/* First try to write zeros and unmap at the same time */
#ifdef CONFIG_FALLOCATE_PUNCH_HOLE
+ /*
+ * The block device fallocate() implementation in the kernel does set
+ * BLKDEV_ZERO_NOFALLBACK, but it does not guarantee that the operation is
+ * fast so we can't call this if we have to avoid slow fallbacks.
+ */
+ if (aiocb->aio_type & QEMU_AIO_BLKDEV &&
+ aiocb->aio_type & QEMU_AIO_NO_FALLBACK) {
+ return -ENOTSUP;
+ }
+
int ret = do_fallocate(s->fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
aiocb->aio_offset, aiocb->aio_nbytes);
if (ret != -ENOTSUP) {
--
2.25.4
next reply other threads:[~2020-06-13 17:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-13 17:08 Nir Soffer [this message]
2020-06-15 19:32 ` [PATCH] block: file-posix: Fail unmap with NO_FALLBACK on block device Nir Soffer
2020-06-16 15:32 ` Kevin Wolf
2020-06-16 17:39 ` Nir Soffer
2020-06-16 20:01 ` Nir Soffer
2020-06-17 10:47 ` Kevin Wolf
2020-06-16 20:09 ` Eric Blake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200613170826.354270-1-nsoffer@redhat.com \
--to=nirsof@gmail.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=nsoffer@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).