Re: Btrfs progs release 4.1.1

[David Sterba <dsterba@suse.com>]

On Sat, Jul 11, 2015 at 06:02:29PM -0700, Marc MERLIN wrote:
> Are you interested in crash reports for fsck?
> 
> If so, see my recent message:
> 
> On Mon, Jul 06, 2015 at 02:21:56PM -0700, Marc MERLIN wrote:
> > 
> > myth:~# btrfs check --repair /dev/mapper/crypt_sdd1 
> > enabling repair mode
> > Checking filesystem on /dev/mapper/crypt_sdd1
> > UUID: 024ba4d0-dacb-438d-9f1b-eeb34083fe49
> > checking extents
> > cmds-check.c:4486: add_data_backref: Assertion `back->bytes != max_size` failed.

The bugon was added by Josef in commit 650e656a8b9c1fbe4e to
(https://git.kernel.org/kdave/btrfs-progs/c/650e656a8b9c1fbe4ec)

but I don't thing that your filesystem is affected by the described bug,
rather that it tripped over some other inconsistency in backrefs.

> > I can mount with -o ro without it crashing, but if I drop ro, it then
> > tries to do something and crashes, and unfortunately the error doesn't
> > make it to syslog
> > 
> > Screenshot: http://marc.merlins.org/tmp/btrfs_crash.jpg

So it's 32bit system, 3.19.8, crashing during snapshot deletion and
backref walking. EIP is in do_walk_down+0x142. I've tried to match it to
the sources on a local 32bit build, but it does not point to the
expected crash site:

(gdb) l *(do_walk_down+0x142)
0x1cdc2 is in do_walk_down (fs/btrfs/extent-tree.c:7875).
7870
7871                            wc->stage = UPDATE_BACKREF;
7872                            wc->shared_level = level - 1;
7873                    }
7874            } else {
7875                    if (level == 1 &&
7876                        (wc->flags[0] & BTRFS_BLOCK_FLAG_FULL_BACKREF))
7877                            goto skip;
7878            }
7879

There are other places where it could hit a bug-on. It would need more
debugging to find out what's happening.