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: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] domU oom -> xvda1 read-only without any notice?
From: Josip Rodin <joy@xxxxxxxxxxxxxx>
Date: Wed, 31 Mar 2010 11:01:40 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 31 Mar 2010 02:03:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1270025699.10129.72488.camel@xxxxxxxxxxxxxxxxxxxxxx>
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: <C7D8CA1D.F509%keir.fraser@xxxxxxxxxxxxx> <1270025699.10129.72488.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Wed, Mar 31, 2010 at 09:54:59AM +0100, Ian Campbell wrote:
> On Wed, 2010-03-31 at 09:45 +0100, Keir Fraser wrote:
> > 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?
> Root filesystems are often mounted with the "errors=remount-ro" option
> (is it the Debian default?). So it's possible this is a domU decision to
> go read-only, but the question remains as to what happened in the domU
> to trigger this decision, can an OOM do that? There might be something
> earlier in the domU dmesg?

Yes, it's the default, but it doesn't explain why I can't go *back* to rw.
remount-ro should be functionally equivalent to mount -o remount,ro /, but
something made the system think that the block device is read-only.

And, there's nothing out of the OOM context in dmesg, as in, nothing
mentions xvda explicitly, but here's the entire kernel log from the last
boot to the end. (Hopefully the list allows gzipped attachments, it's a lot
of text.)

     2. That which causes joy or happiness.

Attachment: oom.kern.log.gz
Description: Binary data

Xen-devel mailing list