On Thu, Aug 15, 2013 at 08:41:53PM +0200, richard -rw- weinberger wrote: > Meant regarding fsync()...
Ah right, see what you mean :-) It calls sync(2). Then it opens each /dev/ubdX device and calls fsync on the file descriptor: https://github.com/libguestfs/libguestfs/blob/master/daemon/sync.c#L54 The reason for this is a bit complicated, but has to do with write barriers. I believe this has been fixed since then. https://github.com/libguestfs/libguestfs/commit/c0a3c9ce70b98171e737e49e6dccc4457963f2ec In any case, we're calling sync & fsync in the guest, and that ain't causing the host cache to be flushed. It's pretty easy to show this with libguestfs: LIBGUESTFS_BACKEND=uml LIBGUESTFS_HV=~/d/linux-um/linux \ time ./run ./fish/guestfish -N fs:ext2:1G -m /dev/sda1 fallocate64 /data 800M time sync The first command finishes in 8 seconds, with barely any disk activity. The sync afterwards takes 9 seconds with the disk light on the whole time, while it actually writes the whole 800 MB of data. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
