On Thu, Jul 14, 2011 at 08:34:46AM -0600, Eric Blake wrote:
On 07/14/2011 08:24 AM, Eric Blake wrote:
O_DIRECT has stringent requirements - I/O must occur with buffers that have both alignment and size as multiples of the file system block size (used to be 512 bytes, but these days, 4k is safer, and 64k allows for better throughput). Rather than make lots of changes at each site that wants to use O_DIRECT, it is easier to offload the work through a helper process that mirrors the I/O between a pipe and the actual direct fd, so that the other end of the pipe no longer has to worry about constraints.
+virDirectFdPtr +virDirectFdNew(int *fd, const char *name) +{ + virDirectFdPtr ret = NULL; + bool output = false; + int pipefd[2] = { -1, -1 }; + int mode = -1; + + if (VIR_ALLOC(ret) < 0) { + virReportOOMError(); + goto error; + } + if (!O_DIRECT) + return ret;
Question - should an attempt to use 'virsh save --direct' on a system that lacks O_DIRECT (think mingw) be rejected, rather than silently ignored? My argument is that --direct is merely an optimization hint - it tries to reduce filesystem cache pollution (possibly at the expense of slower operation), but other than the cache effects, the end result is the same as if O_DIRECT is unavailable. Hence, my decision of silently ignoring it rather than erroring out.
The motivation for using O_DIRECT is that allowing pollution of the host cache causes stability problems for the host as a whole. As such IMHO, apps would likely want an error back if O_DIRECT cannot be supported, NB, even some Linux filesystems can't do O_DIRECT, so this isn't an obscure mingw32 issue. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|