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

RE: [Xen-devel] testing that volumes are not currently attached to loopback devices


  • To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
  • From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
  • Date: Sun, 12 Apr 2009 13:49:33 +1000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Sat, 11 Apr 2009 20:50:10 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acm5Ebjt1zV5VvCXR7WIPcAVuDINUACD29hQ
  • Thread-topic: [Xen-devel] testing that volumes are not currently attached to loopback devices

> 
> Loop devices won't flush out writes to disk for an arbitrary amount
> of time, and of course also have read cache.
> 
> If your Xen guest  accesses the same underlying file, using direct
> I/O I imagine you could be seeing inconsistent data from the file
> 

It very nearly drove me around the bend. The boot process (bios and the
int13 bootstrap of windows) would see the 'old' data that was being
cached by the loopback device. The PV drivers were seeing the 'real'
data.

So I would update my PV drivers into the DomU, reboot, and get the old
ones because they were loaded by the int13 bootstrap (I didn't know this
at first). Once the PV drivers took over though, windows would see the
new version of the driver but didn't care as it was already loaded, the
drivers in C:\WINDOWS\system32\drivers were definitely the new ones and
I couldn't figure out why the old ones were still being loaded. It
nearly drove me insane I tell you!!!

I'm actually not sure that 3.3+ suffers from this problem though. I've
just realised that the machine I was testing on yesterday was my 3.1.x
machine...

James



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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