Re: [Xen-devel] libvirt, libxl and QDISKs

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 29 Apr 2013, Ian Campbell wrote:
> On Fri, 2013-04-26 at 18:10 +0100, Stefano Stabellini wrote:
> > On Fri, 26 Apr 2013, Ian Campbell wrote:
> > > On Fri, 2013-04-26 at 12:48 +0100, Stefano Stabellini wrote:
> > > > On Fri, 26 Apr 2013, Ian Campbell wrote:
> > > > > On Fri, 2013-04-26 at 12:31 +0100, Marek Marczykowski wrote:
> > > > > > What about old good loop+phy based backend for file disk images? I 
> > > > > > don't want
> > > > > > whole qemu in dom0 for PV domains, only for handling simple disk 
> > > > > > backend.
> > > > > > Additionally sparse images + loop + phy + mount -o discard in domU 
> > > > > > makes the
> > > > > > images "auto shrinking". Don't know if qemu is able to do this.
> > > > > 
> > > > > IIRC the problem with loop+phy is that loop doesn't do O_DIRECT and
> > > > > therefore your data isn't actually on the disk when you might think it
> > > > > is, which can lead to filesystem corruption even if the f/s is doing
> > > > > correct barriers.
> > > > 
> > > > If it is safe for QEMU, it should be safe for loop and blkback too.
> > > 
> > > qemu (and blkback) will issue correct barriers/syncs to the underlying
> > > storage. AFAIK loop does not.
> > 
> > Looking at drivers/block/loop.c, it seems to me that REQ_FUA and
> > REQ_FLUSH both handled correctly by issuing a vfs_fsync.
> 
> Oh, good, either it's been fixed (do we know when?) or I was confusing
> things with O_DIRECT.
> 
> > > > > > Attached patch, which I currently use for that. If it is close to 
> > > > > > something
> > > > > > that would be accepted, I will send it in new thread.
> > > > > 
> > > > > I think you can use a block script for this (i.e. it does the loop
> > > > > mount) and avoid patching libxl at all. That's what xend did at 
> > > > > least...
> > > > 
> > > > Yes, libxl would need to arrage the script to be called when "phy" is
> > > > used on a file, right?
> > > 
> > > I meant the user can pass "script=block-loop". In the full knowledge of
> > > what that means for their data integrity.
> >  
> > Yeah, but there is no such block-loop script at the moment, the script
> > is called block and its behaviour depends on the xenstore "type" node:
> > it must be "file" and libxl never writes "type" "file" to xenstore (see
> > device_disk_add and libxl__device_disk_string_of_backend).
> 
> A block-loop script would be a matter of a few minutes work based on the
> current block script, or the current block script could be modified to
> stat the path and DTRT when handling a phy type device.

I vote for having this in 4.3

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel