xfs
[Top] [All Lists]

Re: [bisected] xfs panics when attempting to mount btrfs

To: Sergei Trofimovich <slyfox@xxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: [bisected] xfs panics when attempting to mount btrfs
From: Ben Myers <bpm@xxxxxxx>
Date: Thu, 3 Jan 2013 07:53:32 -0600
Cc: Alex Elder <elder@xxxxxxxxxx>, bpm@xxxxxxx, Dave Chinner <dchinner@xxxxxxxxxx>, xfs@xxxxxxxxxxx, Phil White <pwhite@xxxxxxx>
In-reply-to: <20121230122622.04e44f53@sf>
References: <20121229135229.4ea4615a@xxxxxxxxxxxxx> <50DF508D.2010105@xxxxxxxxxxx> <20121230015109.1219d01f@sf> <50DF7CD1.90205@xxxxxxxxxxx> <20121230122622.04e44f53@sf>
User-agent: Mutt/1.5.20 (2009-06-14)
On Sun, Dec 30, 2012 at 12:26:22PM +0300, Sergei Trofimovich wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sat, 29 Dec 2012 17:29:21 -0600
> Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 12/29/12 4:51 PM, Sergei Trofimovich wrote:
> > > On Sat, 29 Dec 2012 14:20:29 -0600
> > > Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
> > > 
> > >>> Panic showed all my drives and partitions which means
> > >>> they were detected correctly.
> > > 
> > >> Was it a panic, or was it simply a very verbose message which contained 
> > >> a backtrace?
> > > 
> > >> Can you please include what you actually saw in your logs?
> > > 
> > > Yes, it was a panic. Box did not boot (i would not bisect it otherwise).
> > > I won't have access to real box thus I've reproduced it in minimal
> > > UML:
> > > 
> > > Current usermode linux perfectly reproduces the problem as well:
> > > 
> > > $ cat ./run_ubda_fails 
> > > #!/bin/sh
> > > 
> > > ./vmlinux                                        \
> > >     ubd0=$(pwd)/1G.img                           \
> > >     root=/dev/ubda                               \
> > >     rw                                           \
> > >     mem=256M                                     \
> > >     umid=foo                                     \
> > >                                                  \
> > >     "$@"
> > > reset
> > > 
> > > $ cat ./run_ubda
> > > #!/bin/sh
> > > 
> > > ./vmlinux                                        \
> > >     ubd0=$(pwd)/1G.img                           \
> > >     root=/dev/ubda                               \
> > >     rw rootfstype=btrfs                          \
> > >     mem=256M                                     \
> > >     umid=foo                                     \
> > >                                                  \
> > >     "$@"
> > > reset
> > > 
> > > Note the rootfstype in the workign case. I've included only EXT4=y XFS=y 
> > > and BTRFS=y
> > > as supported FSen. The UML OOps:
> > > 
> > > [    0.170000] VFS: Cannot open root device "ubda" or 
> > > unknown-block(98,0): error -117
> > 
> > Oh, ok, so it was panicing due to inability to mount root; not xfs itself 
> > panicing.
> > 
> > Were there any messages from xfs prior to this?
> > 
> > Especially if there were none, this might fix it, though TBH it's just
> > a quick guess, I haven't really looked at how the probing works at
> > boot time recently.  Can you test it?
> > 
> > From: Eric Sandeen <sandeen@xxxxxxxxxx>
> > 
> > Do not return EFSCORRUPTED when filesystem probe finds no XFS magic
> > 
> > 9802182 changed the return value from EWRONGFS (aka EINVAL)
> > to EFSCORRUPTED which doesn't seem to be handled properly by
> > the root filesystem probe.
> > 
> > Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
> 
> Yeah, you patch is nicer. xfs_mount_validate_sb does the similar thing.
> Thanks!
> 
> Tested-by: Sergei Trofimovich <slyfox@xxxxxxxxxx>

Looks good to me.  

Reviewed-by: Ben Myers <bpm@xxxxxxx>

<Prev in Thread] Current Thread [Next in Thread>