Re: [Xen-devel] xl hangs instead of failing more graciously when the fs is read-only

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-06-12 at 10:08 +0200, Sander Eikelenboom wrote:
> Thursday, June 12, 2014, 9:59:37 AM, you wrote:
> 
> > On Thu, 2014-06-12 at 09:47 +0200, Sander Eikelenboom wrote:
> >> Hi Ian,
> >> 
> >> At the moment Iâm having the privilege of thrashing my box and root-fs 
> >> frequently while testing kernels. This causes the root-fs to be mounted 
> >> read-only. But init continues to do it's job any way .. so we get to 
> >> xendomains,
> >> which in turn uses 'xl'. But 'xl' needs a writable FS and hangs when it's 
> >> not,
> >> couldn't and shouldn't this fail more graciously ?
> 
> > Your logs seem to be showing reads/writes to a xenbus device, which has
> > nothing to do with the writeablility of your rootfs afaik.
> 
> > I'm pretty sure xl will correctly error out if it fails to write to a
> > file on a readonly fs, or at least I see no evidence here that it is
> > not.
> 
> [  734.993832]  [<ffffffff811f71e2>] vfs_write+0xc2/0x1e0
> [  735.000239]  [<ffffffff811f76f2>] SyS_write+0x52/0xc0
> [  735.019374]  #0:  (sb_writers#10){.+.+..}, at: [<ffffffff811f72e3>] 
> vfs_write+0x1c3/0x1e0
> 
> These let me think there was also some direct fs writing done, but i'm not 
> that 
> good in interpreting stacktraces to tell which is the actually blocking part.

They are writes, but you can't tell that they are to the rootfs from
this. The rest of the stack trace indicated that they were likely to the
xenbus special device file.

> > Maybe the issue is that xenstored is blocked or by the rootfs ro-ness
> > (or not even started due to it) and so attempts to communicate with it
> > fail?
> 
> > I think the right answer is to always have a writeable rootfs rather
> > than glossing over whatever error led to this situation.
> 
> I'm aiming for that :-) .. i'm not expecting it to function, but there is a 
> subtle difference between hanging and failing. 
> 
> > But I suppose as a fallback xendomains could try and probe for a usable
> > xenstored before proceeding, similar to how xencommons does (ideally
> > with a shared scriptlet somewhere).
> 
> Is it the right place to fix places that use xl, rather than xl it self and 
> let 
> it fail when it can't use xenstored then ?

Fixing it in xl seems to me like it would be very tricky, because xl
uses the kernel interface and not the unix domain socket to access
xenstored (to cope with stub xenstored configurations). You are welcome
to try of course but fixing it in the initscript seems likely to be much
simpler to me.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel