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: Josip Rodin <joy@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] domU oom -> xvda1 read-only without any notice?
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Wed, 31 Mar 2010 11:40:31 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 31 Mar 2010 03:41:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100331090140.GA1648@xxxxxxxxxxxxxxx>
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>
Organization: Citrix Systems, Inc.
References: <C7D8CA1D.F509%keir.fraser@xxxxxxxxxxxxx> <1270025699.10129.72488.camel@xxxxxxxxxxxxxxxxxxxxxx> <20100331090140.GA1648@xxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, 2010-03-31 at 10:01 +0100, Josip Rodin wrote:
> 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.

I'm not sure about that. It's possible that whatever the original error
was it caused the system to also mark the underlying block device as ro
at the same time as the remount,ro and therefore going back to rw is not


Xen-devel mailing list