Re: Please advise on repair action

[Xavier Bassery <xavier@bartica.org>]

Le 2014-03-19 06:57, Adam Khan a écrit :
> Hello,
> 
> I have a simple btrfs located on a dm-crypt volume. I'm getting a
> general protection fault when I
> attempt to access a specific directory in Thunar file manager and in a
> Python program.
> 
> The trace is attached for Thunar.

[  313.491347] general protection fault: 0000 [#1] SMP 
...
[  313.492376] RIP: 0010:[<ffffffff8127c66d>]  [<ffffffff8127c66d>] memcpy+0xd/0x110 ...
[  313.492804] Call Trace:
[  313.492836]  [<ffffffffa013f168>] ? read_extent_buffer+0xc8/0x120 [btrfs]
[  313.492877]  [<ffffffffa0125064>] ? <btrfs_get_extent+0x8f4/0x950 [btrfs]
...
[  313.493293]  [<ffffffff811223ba>] ? ondemand_readahead+0x14a/0x280

> 
> btrfsck returns this:
> 
> Checking filesystem on /dev/mapper/xyz_crypt
> UUID: ...

Here you've omitted the interesting part (preceding the next line).
Weren't there lines looking like 
"root 256 inode XXXX errors 400, nbytes wrong" ?

> found 88316880601 bytes used err is 1
> total csum bytes: 180423792
> total tree bytes: 291459072
> total fs tree bytes: 50192384
> total extent tree bytes: 12898304
> btree space waste bytes: 55087032
> file data blocks allocated: 352826490880
>  referenced 184697802752
> Btrfs v3.12
> 
> How should I proceed to repair this fs?
> 

this seems to be the same issue as the one described in BZ 68411
(https://bugzilla.kernel.org/show_bug.cgi?id=68411).
If I'm correct, the run-time fix is "Btrfs: don't use ram_bytes for
uncompressed inline items" as said in the bz.
At the moment this fix is only in 3.14-xx but is expected to come to
stable too.
Also btrfs check is not yet able to repair this. You'll find a
work-around given in the bug report that involves truncating and
unlinking the problematic files.

Best regards,
Xavier