[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

> > > 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.

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.