Re: Please advise on repair action

Adam Khan
2014-03-26T19:20:33Z

On 21/03/14 06:17 AM, Xavier Bassery wrote:
> 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" ?

There is not a detailed error returned by btrfsck. The only part I found
interesting is 'used err is 1', but maybe that is because this was my
first time running btrfsck. No inode errors are reported.

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

I tried running a Debian kernel from experimental (3.14~rc7-1~exp1) but
it won't boot.. I'm missing many modules.
Presumably if the new kernel prevents the crash then the files would be
accessible?

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

I would try this but btrfsck does not give me any inodes.

>
> Best regards,
> Xavier
>
>

Merci beaucoup pour l'assistance/thank you for the assistance,
Adam