From: Adam Khan <adam.s.khan@gmail.com>
To: Xavier Bassery <xavier@bartica.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Please advise on repair action
Date: Wed, 26 Mar 2014 15:20:31 -0400 [thread overview]
Message-ID: <5333287F.6000601@gmail.com> (raw)
In-Reply-To: <20140321111701.2502a307@renoir.lan>
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
next prev parent reply other threads:[~2014-03-26 19:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 5:57 Please advise on repair action Adam Khan
2014-03-20 18:14 ` Adam Khan
2014-03-21 10:17 ` Xavier Bassery
2014-03-26 19:20 ` Adam Khan [this message]
2014-03-27 13:22 ` Xavier Bassery
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5333287F.6000601@gmail.com \
--to=adam.s.khan@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=xavier@bartica.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox