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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
