Re: [Qemu-devel] [RFC] Disk integrity in QEMU

[Mark Wagner]

Anthony Liguori wrote:
> Mark Wagner wrote:
> > If you stopped and listened to yourself, you'd see that you are making 
> > my point...
> >
> > AFAIK, QEMU is neither designed nor intended to be an Enterprise 
> > Storage Array,
> > I thought this group is designing a virtualization layer.  However, 
> > the persistent
> > argument is that since Enterprise Storage products will often 
> > acknowledge a write
> > before the data is actually on the disk, its OK for QEMU to do the same.
>
> I think you're a little lost in this thread.  We're going to have QEMU 
> only acknowledge writes when they complete.  I've already sent out a 
> patch.  Just waiting a couple days to let everyone give their input.
Actually, I'm just don't being clear enough in trying to point out that I
don't think just setting a default value for "cache" goes far enough. My
argument has nothing to do with the default value. It has to do with what the
right thing to do is in specific situations regardless of the value of the
cache setting.

My point is that if a file is opened in the guest with the O_DIRECT (or O_DSYNC)
then QEMU *must* honor that regardless of whatever value the current value of
"cache" is.

So, if the system admin for the host decides to set cache=on and something
in the guest opens a file with O_DIRECT, I feel that it is a violation
of the system call for the host to cache the write in its local cache w/o
sending it immediately to the storage subsystem. It must get an ACK from
the storage subsystem before it can return to the guest in order to preserve
the guarantee.

So, if your proposed default value for the cache is in effect, then O_DSYNC
should provide the write-thru required by the guests use of O_DIRECT on the
writes.  However, if the default cache value is not used and its set to
cache=on, and if the guest is using O_DIRECT or O_DSYNC, I feel there are
issues that need to be addressed.

-mark

> > If QEMU
> > had a similar design to Enterprise Storage with redundancy, battery 
> > backup, etc, I'd
> > be fine with it, but you don't. QEMU is a layer that I've also thought 
> > was suppose
> > to be small, lightweight and unobtrusive that is silently putting 
> > everyones data
> > at risk.
> >
> > The low-end iSCSI server from EqualLogic claims:
> >     "it combines intelligence and automation with fault tolerance"
> >     "Dual, redundant controllers with a total of 4 GB battery-backed 
> > memory"
> >
> > AFAIK QEMU provides neither of these characteristics.
>
> So if this is your only concern, we're in violent agreement.  You were 
> previously arguing that we should use O_DIRECT in the host if we're not 
> "lying" about write completions anymore.  That's what I'm opposing 
> because the details of whether we use O_DIRECT or not have absolutely 
> nothing to do with data integrity as long as we're using O_DSYNC.
>
> Regards,
>
> Anthony Liguori
>
> > -mark
> >
> > > The fact that the virtualization layer has a cache is really not that 
> > > unusual.
> > Do other virtualization layers lie to the guest and indicate that the 
> > data
> > has successfully been ACK'd by the storage subsystem when the data is 
> > actually
> > still in the host cache?
> >
> >
> > -mark
> > > Regards,
> > >
> > > Anthony Liguori