block/file-posix.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
People get surprised when, after "qemu-img create -f raw /dev/sdX", they
still see qcow2 with "qemu-img info", if previously the bdev had a qcow2
header. While this is natural because raw doesn't need to write any
magic bytes during creation, hdev_create is free to clear out the first
sector to make sure the stale qcow2 header doesn't cause such confusion.
Signed-off-by: Fam Zheng <famz@redhat.com>
---
v2: Use stack allocated buffer. [Eric]
Fix return value.
(Keep qemu_write_full instead of switching to qemu_pwritev because
the former handles short writes.)
Fix typo "qemu-img". [Changlong]
---
block/file-posix.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/block/file-posix.c b/block/file-posix.c
index f4de022ae0..a63bbf2b90 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -2703,6 +2703,16 @@ static int hdev_create(const char *filename, QemuOpts *opts,
ret = -ENOSPC;
}
+ if (total_size) {
+ uint8_t buf[BDRV_SECTOR_SIZE] = { 0 };
+ int64_t zero_size = MIN(BDRV_SECTOR_SIZE, total_size);
+ if (lseek(fd, 0, SEEK_SET) == -1) {
+ ret = -errno;
+ } else {
+ ret = qemu_write_full(fd, buf, zero_size);
+ ret = ret == zero_size ? 0 : -errno;
+ }
+ }
qemu_close(fd);
return ret;
}
--
2.13.4
On 08/11/2017 03:09 AM, Fam Zheng wrote: > People get surprised when, after "qemu-img create -f raw /dev/sdX", they > still see qcow2 with "qemu-img info", if previously the bdev had a qcow2 > header. While this is natural because raw doesn't need to write any > magic bytes during creation, hdev_create is free to clear out the first > sector to make sure the stale qcow2 header doesn't cause such confusion. > > Signed-off-by: Fam Zheng <famz@redhat.com> > > --- > > v2: Use stack allocated buffer. [Eric] > Fix return value. > (Keep qemu_write_full instead of switching to qemu_pwritev because > the former handles short writes.) > Fix typo "qemu-img". [Changlong] > --- > block/file-posix.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/block/file-posix.c b/block/file-posix.c > index f4de022ae0..a63bbf2b90 100644 > --- a/block/file-posix.c > +++ b/block/file-posix.c > @@ -2703,6 +2703,16 @@ static int hdev_create(const char *filename, QemuOpts *opts, > ret = -ENOSPC; > } > > + if (total_size) { > + uint8_t buf[BDRV_SECTOR_SIZE] = { 0 }; > + int64_t zero_size = MIN(BDRV_SECTOR_SIZE, total_size); > + if (lseek(fd, 0, SEEK_SET) == -1) { > + ret = -errno; > + } else { > + ret = qemu_write_full(fd, buf, zero_size); > + ret = ret == zero_size ? 0 : -errno; > + } > + } Question: are we ever constrained by O_DIRECT where writing only 512 bytes would be too small for a block device that mandates 4k alignment? If so, then we need MAX(minimum write size, MIN(BDRV_SECTOR_SIZE, total_size)) - it would also mean we can't stack-allocate any more, but that we have to do an aligned buffer allocation (where g_malloc is not necessarily suitably aligned). If O_DIRECT is not a problem, then this is okay: Reviewed-by: Eric Blake <eblake@redhat.com> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On Fri, 08/11 09:42, Eric Blake wrote: > On 08/11/2017 03:09 AM, Fam Zheng wrote: > > People get surprised when, after "qemu-img create -f raw /dev/sdX", they > > still see qcow2 with "qemu-img info", if previously the bdev had a qcow2 > > header. While this is natural because raw doesn't need to write any > > magic bytes during creation, hdev_create is free to clear out the first > > sector to make sure the stale qcow2 header doesn't cause such confusion. > > > > Signed-off-by: Fam Zheng <famz@redhat.com> > > > > --- > > > > v2: Use stack allocated buffer. [Eric] > > Fix return value. > > (Keep qemu_write_full instead of switching to qemu_pwritev because > > the former handles short writes.) > > Fix typo "qemu-img". [Changlong] > > --- > > block/file-posix.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > > diff --git a/block/file-posix.c b/block/file-posix.c > > index f4de022ae0..a63bbf2b90 100644 > > --- a/block/file-posix.c > > +++ b/block/file-posix.c > > @@ -2703,6 +2703,16 @@ static int hdev_create(const char *filename, QemuOpts *opts, > > ret = -ENOSPC; > > } > > > > + if (total_size) { > > + uint8_t buf[BDRV_SECTOR_SIZE] = { 0 }; > > + int64_t zero_size = MIN(BDRV_SECTOR_SIZE, total_size); > > + if (lseek(fd, 0, SEEK_SET) == -1) { > > + ret = -errno; > > + } else { > > + ret = qemu_write_full(fd, buf, zero_size); > > + ret = ret == zero_size ? 0 : -errno; > > + } > > + } > > Question: are we ever constrained by O_DIRECT where writing only 512 > bytes would be too small for a block device that mandates 4k alignment? > If so, then we need MAX(minimum write size, MIN(BDRV_SECTOR_SIZE, > total_size)) - it would also mean we can't stack-allocate any more, but > that we have to do an aligned buffer allocation (where g_malloc is not > necessarily suitably aligned). > > If O_DIRECT is not a problem, then this is okay: A few lines above: fd = qemu_open(filename, O_WRONLY | O_BINARY); so there is no O_DIRECT issue. Fam
On Fri, 08/11 16:09, Fam Zheng wrote: > People get surprised when, after "qemu-img create -f raw /dev/sdX", they > still see qcow2 with "qemu-img info", if previously the bdev had a qcow2 > header. While this is natural because raw doesn't need to write any > magic bytes during creation, hdev_create is free to clear out the first > sector to make sure the stale qcow2 header doesn't cause such confusion. > > Signed-off-by: Fam Zheng <famz@redhat.com> Gentle ping as a reminder for 2.11 as we have now released 2.10. Fam
Am 11.08.2017 um 10:09 hat Fam Zheng geschrieben: > People get surprised when, after "qemu-img create -f raw /dev/sdX", they > still see qcow2 with "qemu-img info", if previously the bdev had a qcow2 > header. While this is natural because raw doesn't need to write any > magic bytes during creation, hdev_create is free to clear out the first > sector to make sure the stale qcow2 header doesn't cause such confusion. > > Signed-off-by: Fam Zheng <famz@redhat.com> > > --- > > v2: Use stack allocated buffer. [Eric] > Fix return value. > (Keep qemu_write_full instead of switching to qemu_pwritev because > the former handles short writes.) > Fix typo "qemu-img". [Changlong] > --- > block/file-posix.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/block/file-posix.c b/block/file-posix.c > index f4de022ae0..a63bbf2b90 100644 > --- a/block/file-posix.c > +++ b/block/file-posix.c > @@ -2703,6 +2703,16 @@ static int hdev_create(const char *filename, QemuOpts *opts, > ret = -ENOSPC; > } So the error paths above only set ret, but don't actually return or jump to the end of the function. > + if (total_size) { > + uint8_t buf[BDRV_SECTOR_SIZE] = { 0 }; > + int64_t zero_size = MIN(BDRV_SECTOR_SIZE, total_size); > + if (lseek(fd, 0, SEEK_SET) == -1) { > + ret = -errno; > + } else { > + ret = qemu_write_full(fd, buf, zero_size); > + ret = ret == zero_size ? 0 : -errno; Which means that an error above (like a too small block device or using a regular file) can be overwritten with a success value if clearing the first sector works. That's probably not quite right. > + } > + } > qemu_close(fd); > return ret; > } Kevin
On Thu, 09/07 17:07, Kevin Wolf wrote: > > diff --git a/block/file-posix.c b/block/file-posix.c > > index f4de022ae0..a63bbf2b90 100644 > > --- a/block/file-posix.c > > +++ b/block/file-posix.c > > @@ -2703,6 +2703,16 @@ static int hdev_create(const char *filename, QemuOpts *opts, > > ret = -ENOSPC; > > } > > So the error paths above only set ret, but don't actually return or jump > to the end of the function. > > > + if (total_size) { > > + uint8_t buf[BDRV_SECTOR_SIZE] = { 0 }; > > + int64_t zero_size = MIN(BDRV_SECTOR_SIZE, total_size); > > + if (lseek(fd, 0, SEEK_SET) == -1) { > > + ret = -errno; > > + } else { > > + ret = qemu_write_full(fd, buf, zero_size); > > + ret = ret == zero_size ? 0 : -errno; > > Which means that an error above (like a too small block device or using > a regular file) can be overwritten with a success value if clearing the > first sector works. That's probably not quite right. You're right, will fix. Fam
© 2016 - 2024 Red Hat, Inc.