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
possible.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home