On Sat, May 25, 2013 at 09:42:08AM -0800, Mark Trumpold wrote:
> On 5/24/13 1:05 AM, "Stefan Hajnoczi" <stefa...@gmail.com> wrote:
> >On Thu, May 23, 2013 at 09:58:31PM +0000, Mark Trumpold wrote:
> >One thing to be careful of is whether these operations are asynchronous.
> >The signal is asynchronous, you have no way of knowing when qemu-nbd is
> >finished flushing to the physical disk.
>
> Right, of course. I missed the obvious.
I missed something too. Paolo may have already hinted at this when he
posted a dd oflag=sync command-line option:
blockdev --flushbufs is the wrong tool because ioctl(BLKFLSBUF) only
writes out dirty pages to the block device. It does *not* guarantee to
send a flush request to the device.
Therefore, the underlying image file may not be put into an up-to-date
state by qemu-nbd.
I suggest trying the following instead of blockdev --flushbufs:
python -c 'import os; os.fsync(open("/dev/loopX", "r+b"))'
This should do the same as blockdev --flushbufs *plus* it sends and
waits for the NBD FLUSH command.
You may have to play with this command-line a little but the main idea
is to open the block device and fsync it.
Stefan
