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.
# btrfs fi show
failed to read /dev/sr0
Label: 'btrfs' uuid: 057239ee-1cc7-44b2-8fa3-714661dfa7fe
Total devices 1 FS bytes used 39.06GB
devid 1 size 455.58GB used 77.04GB path /dev/sda3
Btrfs Btrfs v0.19
# btrfs fi df /home
Data: total=58.01GB, used=38.46GB
System, DUP: total=8.00MB, used=16.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=9.50GB, used=611.59MB
Metadata: total=8.00MB, used=0.00
Btrfs Btrfs v0.19
--
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
