[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: James Harper <james.harper@xxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Thu, 08 Nov 2007 11:04:48 +0000
  • Delivery-date: Thu, 08 Nov 2007 03:05:47 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acgh89hmOjf1UcT/R7S91fG2xpfbEgAAJyu6AAAMH9AAAKHtpA==
  • Thread-topic: [Xen-devel] HVM domain with write caching going on somewhere to disk

On 8/11/07 10:51, "James Harper" <james.harper@xxxxxxxxxxxxxxxx> wrote:

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

When a domain is shutdown, Xen will not acknowledge the shutdown until all
in-flight I/O requests are serviced. That should be sufficient, although it
might depend on what qemu is using for the storage backend. For example, I'm
not sure how aio will interact with SIGKILL of the requesting process
(that's how we terminate qemu-dm on domain destruction).

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

No, it's trickier than that. Blkback sends I/O requests direct into the
block subsystem, bypassing the buffer cache. You can see there's potential
for confusion therefore!

 -- Keir

Xen-devel mailing list



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