Re: WARNING: at fs/btrfs/extent_io.c:4718 map_private_extent_buffer+0xd4/0xe0 [btrfs]()

[Josef Bacik <jbacik@fusionio.com>]

On Fri, Feb 22, 2013 at 09:54:08PM -0700, Mace Moneta wrote:
> On Fri, Feb 22, 2013 at 2:40 PM, Josef Bacik <jbacik@fusionio.com> wrote:
> > On Fri, Feb 22, 2013 at 11:31:07AM -0700, Mace Moneta wrote:
> >> On Fri, Feb 22, 2013 at 1:16 PM, Mace Moneta <moneta.mace@gmail.com> wrote:
> >> > On Fri, Feb 22, 2013 at 1:10 PM, Josef Bacik <jbacik@fusionio.com> wrote:
> >> >> On Fri, Feb 22, 2013 at 10:52:19AM -0700, Mace Moneta wrote:
> >> >>> On Fri, Feb 22, 2013 at 12:44 PM, Josef Bacik <jbacik@fusionio.com> wrote:
> >> >>> > On Fri, Feb 22, 2013 at 10:22:04AM -0700, Mace Moneta wrote:
> >> >>> >> On Fri, Feb 22, 2013 at 11:53 AM, Josef Bacik <jbacik@fusionio.com> wrote:
> >> >>> >> > On Fri, Feb 22, 2013 at 07:46:16AM -0700, Mace Moneta wrote:
> >> >>> >> >> https://bugzilla.redhat.com/show_bug.cgi?id=906142
> >> >>> >> >>
> >> >>> >> >> With 3.8 kernels in Fedora 18, using encfs on btrfs I get the
> >> >>> >> >> following error.  It can take hours of use before I get a
> >> >>> >> >> reoccurrence, and I need to btrfsck, btrfs-zero-log, and/or mount with
> >> >>> >> >> '-o recovery' to get the filesystem back after a reboot.  No data
> >> >>> >> >> appears to be lost, and a scrub runs to completion with no errors.
> >> >>> >> >
> >> >>> >> > Could you do
> >> >>> >> >
> >> >>> >> > gdb btrfs.ko
> >> >>> >> > list *(btrfs_log_inode+0x3b8)
> >> >>> >> >
> >> >>> >> > and tell me what it says?  Thanks,
> >> >>> >> >
> >> >>> >> > Josef
> >> >>> >>
> >> >>> >> # uname -r
> >> >>> >> 3.8.0-0.rc7.git0.1.fc19.x86_64
> >> >>> >>
> >> >>> >> # gdb /usr/lib/modules/3.8.0-0.rc7.git0.1.fc19.x86_64/kernel/fs/btrfs/btrfs.ko
> >> >>> >>
> >> >>> >
> >> >>> > Sigh sorry, I miseed the other line because of line wrapping, can you do
> >> >>> >
> >> >>> > list *(btrfs_log_changed_extents+0x384)
> >> >>> >
> >> >>> > Thanks,
> >> >>> >
> >> >>> > Josef
> >> >>>
> >> >>> (gdb) list *(btrfs_log_changed_extents+0x384)
> >> >>> 0x65264 is in btrfs_log_changed_extents (fs/btrfs/ctree.h:2731).
> >> >>> 2726                       generation, 64);
> >> >>> 2727    BTRFS_SETGET_FUNCS(file_extent_disk_num_bytes, struct
> >> >>> btrfs_file_extent_item,
> >> >>> 2728                       disk_num_bytes, 64);
> >> >>> 2729    BTRFS_SETGET_FUNCS(file_extent_offset, struct btrfs_file_extent_item,
> >> >>> 2730                      offset, 64);
> >> >>> 2731    BTRFS_SETGET_FUNCS(file_extent_num_bytes, struct btrfs_file_extent_item,
> >> >>> 2732                       num_bytes, 64);
> >> >>> 2733    BTRFS_SETGET_FUNCS(file_extent_ram_bytes, struct btrfs_file_extent_item,
> >> >>> 2734                       ram_bytes, 64);
> >> >>> 2735    BTRFS_SETGET_FUNCS(file_extent_compression, struct
> >> >>> btrfs_file_extent_item,
> >> >>> (gdb)
> >> >>
> >> >> Ok nothing obvious is jumping out at me, anything specifc to your btrfs setup?
> >> >> Mount options, raid etc.  I'm going to setup encfs up here and hammer it with
> >> >> fsstress and see if I can reproduce.  Thanks,
> >> >>
> >> >> Josef
> >> >
> >> > The btrfs mount options I'm using are: subvol=home,noatime,autodefrag
> >> >
> >> > The encfs is mounted with default options.
> >>
> >> Oh, and there's no raid data, just a single drive.  I don't do heavy
> >> I/O to the encfs, which may explain why it takes minutes to hours to
> >> recreate.  I have my google-chrome config directory (cache, profile,
> >> passwords, etc.) in the encfs, so it's getting read/written as I
> >> browse.
> >
> > So incase I can't reproduce can you build btrfs-next and see if it reproduces on
> > there?  And if it does perfect I can send you debug patches to apply and such.
> > Thanks,
> >
> > Josef
> 
> Using btrfs-next, current as of commit
> bf3ec18ebec80b2251df8cab062fce5f2bc33a45 (Btrfs: update inode flags
> when renaming), I got a re-occurrence:
>

Is there any chance you got the line above [ cut here ]?  (I hate that stupid [
cut here ], it makes us miss all the usefull info.)  Thanks,

Josef