[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTi=mS43KwRG13ROmZX+HmbrPMVgV=g@mail.gmail.com>
Date: Thu, 16 Jun 2011 09:21:03 +0300
From: Pekka Enberg <penberg@...nel.org>
To: Anthony Liguori <anthony@...emonkey.ws>
Cc: Alexander Graf <agraf@...e.de>,
Prasad Joshi <prasadjoshi124@...il.com>,
Avi Kivity <avi@...hat.com>, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Sasha Levin <levinsasha928@...il.com>,
Cyrill Gorcunov <gorcunov@...il.com>,
Asias He <asias.hejun@...il.com>,
Jens Axboe <jaxboe@...ionio.com>
Subject: Re: [ANNOUNCE] Native Linux KVM tool v2
On Thu, Jun 16, 2011 at 1:44 AM, Anthony Liguori <anthony@...emonkey.ws> wrote:
>>> That's probably why it's fast, it doesn't preserve data integrity :(
>>
>> Actually, I misread the code. It does unstable writes but it does do
>> fsync() on FLUSH.
On Thu, Jun 16, 2011 at 8:41 AM, Pekka Enberg <penberg@...nel.org> wrote:
> Yes. That's fine, right? Or did we misread how virtio block devices
> are supposed to work?
And btw, we use sync_file_range() to make sure the metadata part of a
QCOW2 image is never corrupted. The rational here is that if the guest
doesn't do VIRTIO_BLK_T_FLUSH, you can corrupt your _guest filesystem_
but the _image_ will still work just fine and you can do fsck on it.
Also, Prasad ran xfstests and did over-night stress tests to iron out
corruption issues. Now we obviously can't promise that we'll never eat
your data but I can assure you that we've done as much as we've been
able to with the resources we have at the moment.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists