According to Jiri Denemark on 3/2/2010 8:26 AM:
> Instead of opening storage file with O_DSYNC, make sure data are written
> to a disk only before we claim allocation has finished.
>
> +++ b/src/storage/storage_backend.c
> @@ -332,6 +332,13 @@ static int createRawFileOpHook(int fd, void *data) {
> goto cleanup;
> }
> }
> +
> + if (fsync(fd) < 0) {
> + ret = errno;
> + virReportSystemError(errno, _("cannot sync data to file '%s'"),
> + hdata->vol->target.path);
> + goto cleanup;
> + }
> }
>
> cleanup:
> @@ -357,7 +364,7 @@ virStorageBackendCreateRaw(virConnectPtr conn ATTRIBUTE_UNUSED,
> }
>
> if ((createstat = virFileOperation(vol->target.path,
> - O_RDWR | O_CREAT | O_EXCL | O_DSYNC,
> + O_RDWR | O_CREAT | O_EXCL,
Are there any other uses of the fd that also need a call to fsync()? This
is certainly the less invasive patch of the two options, with no obvious
problems to me. You are correct that we have less progress timing
visibility into the guts of the fsync() than if we are doing the per-page
mmap/write flushing on an O_DSYNC fd.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list