From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dkim1.fusionio.com ([66.114.96.53]:59043 "EHLO dkim1.fusionio.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754529Ab3BYTMj (ORCPT ); Mon, 25 Feb 2013 14:12:39 -0500 Received: from mx1.fusionio.com (unknown [10.101.1.160]) by dkim1.fusionio.com (Postfix) with ESMTP id 700957C040A for ; Mon, 25 Feb 2013 12:12:39 -0700 (MST) Date: Mon, 25 Feb 2013 14:12:36 -0500 From: Josef Bacik To: Mace Moneta CC: Josef Bacik , "linux-btrfs@vger.kernel.org" Subject: Re: WARNING: at fs/btrfs/extent_io.c:4718 map_private_extent_buffer+0xd4/0xe0 [btrfs]() Message-ID: <20130225191236.GA19641@localhost.localdomain> References: <20130222165302.GE2062@localhost.localdomain> <20130222174401.GF2062@localhost.localdomain> <20130222181017.GG2062@localhost.localdomain> <20130222194021.GH2062@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Fri, Feb 22, 2013 at 09:54:08PM -0700, Mace Moneta wrote: > On Fri, Feb 22, 2013 at 2:40 PM, Josef Bacik 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 wrote: > >> > On Fri, Feb 22, 2013 at 1:10 PM, Josef Bacik 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 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 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