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

RE: [Xen-devel] HVM domain with write caching going on somewhere to disk


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
  • Date: Thu, 8 Nov 2007 21:51:10 +1100
  • Delivery-date: Thu, 08 Nov 2007 02:51:45 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acgh89hmOjf1UcT/R7S91fG2xpfbEgAAJyu6AAAMH9A=
  • Thread-topic: [Xen-devel] HVM domain with write caching going on somewhere to disk

> On 8/11/07 10:40, "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
wrote:
> 
> > I've noticed before that any changes made in a Windows HVM domain
> > shortly before an 'xm shutdown' don't ever get written out...
> >
> > Anyway, is there a way to make sure that the qemu stuff doesn't do
any
> > write caching at all?
> 
> I don't think qemu caches writes internally, and also I believe that
> outstanding I/O requests are serviced before a domain is shut down

Are they serviced before a domain is destroyed (eg 'xm destroy')? Maybe
that's what I was using when I noticed it...

> Could
> there be a problem with data ending up in the buffer cache in dom0
kernel?

Hmmm... shouldn't the DomU->qemu->device and DomU->blkbackend->device
path's both have visibility to the same buffer cache though?

Maybe the problem isn't what I thought it was. It seems strange that
windows would boot almost completely using my PV drivers and then barf
at the last minute though.

Thanks

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