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 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