This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] domU oom -> xvda1 read-only without any notice?

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] domU oom -> xvda1 read-only without any notice?
From: Josip Rodin <joy@xxxxxxxxxxxxxx>
Date: Wed, 31 Mar 2010 10:52:45 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 31 Mar 2010 01:53:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C7D8CA1D.F509%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20100331074950.GA18028@xxxxxxxxxxxxxxx> <C7D8CA1D.F509%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Wed, Mar 31, 2010 at 09:45:01AM +0100, Keir Fraser wrote:
> >> Blkback communicates this kind of info to blkfront via a node in xenstore
> >> named 'info'. Bit 2 of this numeric field indicates if a virtual disc is
> >> read-only. I think it's more likely that the domU has internally confused
> >> itself, rather than being told to mount read-only by dom0 -- the flags get
> >> probed when the virtual disc first appears, and I don't think would get
> >> probed again after that anyway without a full disc hot-unplug/replug.
> > 
> > OK, thanks, so is there any way I could examine xen-blkfront then? :)
> > I looked around and only found funny bits like:
> > 
> > % cat /sys/module/xen_blkfront/drivers/xen:vbd/vbd-51713/block/xvda1/ro
> > 0
> AFAIK that means that the read-only-ness is not being propagated up to domU
> block layer by the xen_blockfront driver. I'm not sure exactly what other
> possibilities there are, but if the kernel has been OOMing processes then
> perhaps you're in a runlevel or mode, or even a kenrel bug, in which rootfs
> is forced read-only for other reasons? There have been bugs around OOM in
> the past, and really it's a kernel path that's obviously best avoided! Any
> idea why the OOM occurred in the first place?

Not really. It's prompted by a skipfish (web security scanner) run on the
web server on the same machine, and that server has PHP that talks to the
database. It does nicely for a few hours, then it bursts into flames. The
2.6.26 domU kernel reliably died completely in that situation, it's that SMP
bug with the old forward-ported Xen patches. The new kernel survived some
OOM situations, and obviously some others not so much :) This is the first
time I saw it break blkfront, so I figured it may be useful to report early
in case I can gather some more debug info now.

If nobody has any immediate suggestions as to what to do, I'm going to
restart it now because we need the machine in a not-so-useless state.
But I'll probably reproduce the same problem tonight anyway.

     2. That which causes joy or happiness.

Xen-devel mailing list