On Sat, Jul 29 2006, Paul Brook wrote:
Easy to do with the fsync infrastructure, but probably not worth
doing since people are working on the AIO I/O backend, which would
allow multiple outstanding writes from a guest. That, in turn,
means I/O completion in the guest can be done when the
On Sat, Jul 29 2006, Rik van Riel wrote:
Fabrice Bellard wrote:
Hi,
Using O_SYNC for disk image access is not acceptable: QEMU relies on the
host OS to ensure that the data is written correctly.
This means that write ordering is not preserved, and on a power
failure any data written by
On 31 jul 2006, at 09:08, Jens Axboe wrote:
Applications running on the host can count on fsync doing the
right thing, meaning that if they call fsync, the data *will*
have made it to disk. Applications running inside a guest have
no guarantees that their data is actually going to make it
On Mon, Jul 31 2006, Jonas Maebe wrote:
On 31 jul 2006, at 09:08, Jens Axboe wrote:
Applications running on the host can count on fsync doing the
right thing, meaning that if they call fsync, the data *will*
have made it to disk. Applications running inside a guest have
no guarantees
On Mon, Jul 31 2006, andrzej zaborowski wrote:
On 30/07/06, Jamie Lokier [EMAIL PROTECTED] wrote:
Rik van Riel wrote:
This may look like hair splitting, but so far I've lost a
(test) postgresql database to this 3 times already. Not getting
the guest application's data to disk when the
On 31/07/06, Jens Axboe [EMAIL PROTECTED] wrote:
On Mon, Jul 31 2006, andrzej zaborowski wrote:
On 30/07/06, Jamie Lokier [EMAIL PROTECTED] wrote:
Rik van Riel wrote:
This may look like hair splitting, but so far I've lost a
(test) postgresql database to this 3 times already. Not getting
Rik van Riel wrote:
This may look like hair splitting, but so far I've lost a
(test) postgresql database to this 3 times already. Not getting
the guest application's data to disk when the application calls
fsync is a recipe for disaster.
Exactly the same thing happens with real IDE disks if
Bill C. Riemers wrote:
How about compromising, and making the patch a run time option.
Presumably this is only a problem when the virtual machine is not
properly shutdown. For those ho want the extra security of knowing
the data will be written regardless of the
Hi,
Using O_SYNC for disk image access is not acceptable: QEMU relies on the
host OS to ensure that the data is written correctly. Even the current
'fsync' support is questionnable to say the least !
Please don't mix issues regarding QEMU disk handling and the underlying
hypervisor/host OS
Fabrice Bellard wrote:
Hi,
Using O_SYNC for disk image access is not acceptable: QEMU relies on the
host OS to ensure that the data is written correctly.
This means that write ordering is not preserved, and on a power
failure any data written by qemu (or Xen fully virt) guests may
not be
Easy to do with the fsync infrastructure, but probably not worth
doing since people are working on the AIO I/O backend, which would
allow multiple outstanding writes from a guest. That, in turn,
means I/O completion in the guest can be done when the data really
hits disk, but without a
How about compromising, and making the patch a run time option. Presumably this is only a problem when the virtual machine is not properly shutdown. For those ho want the extra security of knowing the data will be written regardless of the shutdown status they can enable the flag. By default it
12 matches
Mail list logo
