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.m...@gmail.com> wrote: > > On Fri, Feb 22, 2013 at 1:10 PM, Josef Bacik <jba...@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 <jba...@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 <jba...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
