On Tue, Mar 2, 2021 at 4:08 AM ChangLimin <chan...@chinatelecom.cn> wrote: > > After Linux 5.10, write zeros to a multipath device using > ioctl(fd, BLKZEROOUT, range) with cache none or directsync will return EBUSY. > > Similar to handle_aiocb_write_zeroes_unmap, handle_aiocb_write_zeroes_block > allow -EBUSY errors during ioctl(fd, BLKZEROOUT, range). > > Reference commit in Linux 5.10: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=384d87ef2c954fc58e6c5fd8253e4a1984f5fe02
But this can happen only when the block device is used by a file system or maybe someone else. In qemu we assume that we are the only user of the block device, so EBUSY is a fatal error that should never happen, no? Can you explain a real world use case when we get EBUSY? Nir > Signed-off-by: ChangLimin <chan...@chinatelecom.cn> > --- > block/file-posix.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/block/file-posix.c b/block/file-posix.c > index 05079b40ca..3e60c96214 100644 > --- a/block/file-posix.c > +++ b/block/file-posix.c > @@ -1629,8 +1629,13 @@ static ssize_t > handle_aiocb_write_zeroes_block(RawPosixAIOData *aiocb) > } while (errno == EINTR); > > ret = translate_err(-errno); > - if (ret == -ENOTSUP) { > + switch (ret) { > + case -ENOTSUP: > + case -EINVAL: > + case -EBUSY: > s->has_write_zeroes = false; > + return -ENOTSUP; > + break; > } > } > #endif > -- > 2.27.0 >