Please advise on repair action

DISCUSSION Adam Khan 2 participants 5 messages Mar 19, 2014 – Mar 27, 2014 Btrfs file system

Share & tools

Adam Khan

author

2014-03-19 05:57 UTC #0 lore raw

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.

btrfsck returns this:

Checking filesystem on /dev/mapper/xyz_crypt
UUID: ...
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?

Best regards,

Adam

[  313.491347] general protection fault: 0000 [#1] SMP 
[  313.491387] Modules linked in: ccm xt_conntrack xt_LOG xt_limit xt_tcpudp iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables x_tables rfcomm bnep deflate ctr twofish_generic twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_x86_64 serpent_sse2_x86_64 xts serpent_generic lrw gf128mul glue_helper blowfish_generic blowfish_x86_64 blowfish_common cast5_generic cast_common ablk_helper cryptd des_generic cmac xcbc rmd160 sha512_ssse3 sha512_generic hmac crypto_null af_key xfrm_algo nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc ext4 mbcache jbd2 fuse parport_pc ppdev lp parport hid_generic joydev hid_lenovo_tpkbd usbhid hid sg btusb bluetooth crc16 usb_storage iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant coretemp kvm_intel kvm psmouse serio_raw pcspkr evdev i2c_i801 lpc_ich mfd_core arc4 iwldvm mac80211 iwlwifi cfg80211 wmi battery thinkpad_acpi nvram rfkill ac snd_hda_intel snd_hda_codec tpm_tis snd_hwdep snd_pcm tpm snd_page_alloc snd_seq snd_seq_device snd_timer i915 snd video uhci_hcd ehci_pci drm_kms_helper button acpi_cpufreq ehci_hcd drm i2c_algo_bit e1000e i2c_core mei_me processor mei ptp pps_core soundcore usbcore usb_common btrfs crc32c libcrc32c xor raid6_pq sha256_ssse3 sha256_generic cbc dm_crypt dm_mod sd_mod crc_t10dif crct10dif_common ahci libahci libata scsi_mod thermal thermal_sys
[  313.492281] CPU: 1 PID: 3946 Comm: Thunar Not tainted 3.13-1-amd64 #1 Debian 3.13.5-1
[  313.492313] Hardware name: LENOVO 7454CTO/7454CTO, BIOS 6DET71WW (3.21 ) 12/13/2011
[  313.492345] task: ffff88022fe1c010 ti: ffff88022f6d8000 task.ti: ffff88022f6d8000
[  313.492376] RIP: 0010:[<ffffffff8127c66d>]  [<ffffffff8127c66d>] memcpy+0xd/0x110
[  313.492414] RSP: 0018:ffff88022f6d9970  EFLAGS: 00010206
[  313.492438] RAX: ffff8800aa2528b5 RBX: 000000000000034b RCX: 0000000000000069
[  313.492467] RDX: 0000000000000003 RSI: db73880000000000 RDI: ffff8800aa2528b5
[  313.492496] RBP: ffff880225b9e9c0 R08: 0000000000000000 R09: 0000000000001000
[  313.492525] R10: 0000000000000000 R11: 0000000000000000 R12: 6db6db6db6db6db7
[  313.492554] R13: 0000160000000000 R14: ffff8800aa252c00 R15: 000000000000034b
[  313.492584] FS:  00007fe3282f7a00(0000) GS:ffff88023bc80000(0000) knlGS:0000000000000000
[  313.492620] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  313.492643] CR2: 00007fe2e0029228 CR3: 00000000b7625000 CR4: 00000000000407e0
[  313.492673] Stack:
[  313.492683]  ffffffffa013f168 0000000000000000 ffff8800b8289000 ffff880225ac8c40
[  313.492724]  0000000000000000 0000000000000c00 ffff880225615330 ffff880227448658
[  313.492764]  ffffffffa0125064 ffff880225b9e8f0 0000000000001000 ffff8800aa252000
[  313.492804] Call Trace:
[  313.492836]  [<ffffffffa013f168>] ? read_extent_buffer+0xc8/0x120 [btrfs]
[  313.492877]  [<ffffffffa0125064>] ? btrfs_get_extent+0x8f4/0x950 [btrfs]
[  313.492917]  [<ffffffffa0138154>] ? set_state_bits+0x34/0x70 [btrfs]
[  313.492957]  [<ffffffffa013b7b8>] ? __do_readpage+0x378/0x730 [btrfs]
[  313.492995]  [<ffffffffa013a4dd>] ? lock_extent_bits+0x6d/0x1c0 [btrfs]
[  313.493034]  [<ffffffffa0124770>] ? btrfs_real_readdir+0x550/0x550 [btrfs]
[  313.493075]  [<ffffffffa013bf12>] ? __extent_readpages.constprop.42+0x2d2/0x2f0 [btrfs]
[  313.493119]  [<ffffffffa0124770>] ? btrfs_real_readdir+0x550/0x550 [btrfs]
[  313.493160]  [<ffffffffa013daa2>] ? extent_readpages+0x182/0x190 [btrfs]
[  313.493201]  [<ffffffffa0124770>] ? btrfs_real_readdir+0x550/0x550 [btrfs]
[  313.493234]  [<ffffffff811598a7>] ? alloc_pages_current+0x97/0x150
[  313.493264]  [<ffffffff81121f03>] ? __do_page_cache_readahead+0x193/0x240
[  313.493293]  [<ffffffff811223ba>] ? ondemand_readahead+0x14a/0x280
[  313.493322]  [<ffffffff811186ee>] ? generic_file_aio_read+0x4be/0x6e0
[  313.493350]  [<ffffffff81178d47>] ? do_sync_read+0x57/0x90
[  313.493376]  [<ffffffff8117935b>] ? vfs_read+0x8b/0x160
[  313.493399]  [<ffffffff81179e43>] ? SyS_read+0x43/0xa0
[  313.493424]  [<ffffffff814adb39>] ? system_call_fastpath+0x16/0x1b
[  313.493451] Code: fc ff ff 48 8b 43 58 48 2b 43 50 88 43 4e eb e9 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 20 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c 
[  313.493686] RIP  [<ffffffff8127c66d>] memcpy+0xd/0x110
[  313.493713]  RSP <ffff88022f6d9970>
[  313.500471] ---[ end trace a08695abfe727a2b ]---

Adam Khan

author

2014-03-20 18:14 UTC #1 lore raw

Does anyone know if my issue is btrfs related or if it is more likely hardware related:
http://www.spinics.net/lists/linux-btrfs/msg30999.html

My kernel is from Debian Jessie:
3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04) x86_64 GNU/Linux

Thanks for any insight

Quoted 27 lines · Adam Khan

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.
btrfsck returns this:
Checking filesystem on /dev/mapper/xyz_crypt
UUID: ...
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?
Best regards,
Adam

Xavier Bassery

2014-03-21 10:17 UTC #2 lore raw

In reply to Adam Khan

Le 2014-03-19 06:57, Adam Khan a écrit :

Quoted 8 lines

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

Quoted 5 lines

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" ?

Quoted 10 lines

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

Quoted 2 lines

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

Adam Khan

author

2014-03-26 19:20 UTC #3 lore raw

Quoted 20 lines · Xavier Bassery

Le 2014-03-19 06:57, Adam Khan a Ã©crit :
Quoted 8 lines
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
Quoted 1 line

Quoted 8 lines

Quoted 4 lines
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.

Quoted 13 lines

Quoted 10 lines
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
Quoted 2 lines
How should I proceed to repair this fs?

Quoted 6 lines

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?

Quoted 3 lines

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.

Quoted 5 lines

Best regards,
Xavier

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

Xavier Bassery

2014-03-27 13:22 UTC #4 lore raw

Quoted 6 lines · On Wed, 26 Mar 2014 15:20:31 -0400 Adam Khan <[email protected]> wrote:

Quoted 6 lines
Quoted 5 lines
btrfsck returns this:
Checking filesystem on /dev/mapper/xyz_crypt
UUID: ...

Quoted 7 lines

Quoted 3 lines
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.

Could you please provide the full output of btrfs check?

Xavier