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.
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
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 application calls
> fsync is a recipe for disaste
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
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
anyw
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
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 wh
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 t
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
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
> 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 p
Paul Brook wrote:
On Saturday 29 July 2006 15:59, 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
failu
On Saturday 29 July 2006 15:59, 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
> failu
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 pres
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 b
This is the simple approach to making sure that disk writes actually
hit disk before we tell the guest OS that IO has completed. Thanks
to DMA_MULTI_THREAD the performance still seems to be adequate.
A fancier solution would be to make the sync/non-sync behaviour of
the qemu disk backing store t
16 matches
Mail list logo
