* fs corruption report @ 2014-08-25 5:08 Zooko Wilcox-OHearn 2014-08-28 2:28 ` Gui Hecheng 2014-08-28 2:46 ` Gui Hecheng 0 siblings, 2 replies; 19+ messages in thread From: Zooko Wilcox-OHearn @ 2014-08-25 5:08 UTC (permalink / raw) To: linux-btrfs [-- Attachment #1: Type: text/plain, Size: 2757 bytes --] Dear people of linux-btrfs: Thank you for btrfs! It is a beautiful thing. I say that in spite of the fact that it seems to have failed and eaten some of my data. I'm writing with two purposes: to get help and advice in recovering my data, to help debug the software. I was running linux 3.12.26 and btrfsprogs 3.14, and I started getting error messages like these in my syslog: syslog.7:Aug 16 02:32:35 spark kernel: [48524.140611] btrfs no csum found for inode 15537898 start 4096 It happened only for one of the three partitions on this SSD, and smartctl indicated no problem with the disk: SMART overall-health self-assessment test result: PASSED … Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 6406 - # 2 Extended captive Completed without error 00% 6405 - I upgraded my kernel to 3.16.1 and tried the various techniques suggested in https://btrfs.wiki.kernel.org/index.php/Btrfsck and https://btrfs.wiki.kernel.org/index.php/Problem_FAQ , including `btrfsck check --repair --init-csum-tree`. This didn't fix it. I made an image of the filesystem in case someone wants to diagnose it (78 MB), and I also a made a dd copy of the affected partition. The `btrfs restore` command aborts even though I've passed the -i flag. In fact, I see that on subsequent runs it aborts at different places. Looking at the source code (http://git.kernel.org/cgit/linux/kernel/git/mason/btrfs-progs.git/tree/cmds-restore.c?id=c17d0a73c11d7cdbdf1582408ec6d168876160ea#n819) I don't see how -6 from decompress could cause it to stop when I have set `ignore_errors`, so next I ran it under valgrind. Aha. When it is run under valgrind it consistently stops (killing valgrind, in fact!) in the same way on every run. Here's the tail of stdout and stderr when it aborted when run under valgrind: Restoring ./sda6-btrfs-restore-3/@home/zooko/.mozilla/firefox/ltjwtkwe.ketotic.org/thumbnails/188888af64f6d2871b0f24e325d8a298.png Restoring ./sda6-btrfs-restofailed to inflate: -6 Full valgrind outputs from such a run is attached to this letter. I've spent a little time looking at the stack traces in the valgrind log, and I *guess* that there is corruption such that the decompression fails, and I guess it would be possible to make cmds-restore handle corrupted compressedtext better, so that it would end up skipping whatever files and directories were unrestorable due to corruption. However, I don't immediately see how to proceed. Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters. [-- Attachment #2: vlog.txt --] [-- Type: text/plain, Size: 20364 bytes --] ==5569== Memcheck, a memory error detector ==5569== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==5569== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info ==5569== Command: btrfs restore -v -v -v -i /dev/sda6 ./sda6-btrfs-restore-3 ==5569== Parent PID: 5566 ==5569== ==5569== Syscall param pwrite64(buf) points to uninitialised byte(s) ==5569== at 0x56ABD03: __pwrite_nocancel (syscall-template.S:81) ==5569== by 0x41F346: search_dir (cmds-restore.c:392) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== Address 0x5ce3084 is 18,420 bytes inside a block of size 20,480 alloc'd ==5569== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x41EFC3: search_dir (cmds-restore.c:316) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== ==5569== Invalid read of size 1 ==5569== at 0x4C2F95E: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x4388E6: read_extent_buffer (string3.h:51) ==5569== by 0x41ED6C: search_dir (cmds-restore.c:233) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== Address 0x5d11260 is 0 bytes after a block of size 4,224 alloc'd ==5569== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x4381B7: alloc_extent_buffer (extent_io.c:574) ==5569== by 0x42B5D8: btrfs_find_create_tree_block (disk-io.c:133) ==5569== by 0x42CD00: read_tree_block (disk-io.c:265) ==5569== by 0x427407: read_node_slot (ctree.c:634) ==5569== by 0x42A1A5: btrfs_search_slot (ctree.c:1113) ==5569== by 0x41EA5A: search_dir (cmds-restore.c:567) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== ==5569== Invalid read of size 1 ==5569== at 0x4C2F950: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x4388E6: read_extent_buffer (string3.h:51) ==5569== by 0x41ED6C: search_dir (cmds-restore.c:233) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== Address 0x5d11262 is 2 bytes after a block of size 4,224 alloc'd ==5569== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x4381B7: alloc_extent_buffer (extent_io.c:574) ==5569== by 0x42B5D8: btrfs_find_create_tree_block (disk-io.c:133) ==5569== by 0x42CD00: read_tree_block (disk-io.c:265) ==5569== by 0x427407: read_node_slot (ctree.c:634) ==5569== by 0x42A1A5: btrfs_search_slot (ctree.c:1113) ==5569== by 0x41EA5A: search_dir (cmds-restore.c:567) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== ==5569== Invalid read of size 2 ==5569== at 0x4C2F7EF: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x4388E6: read_extent_buffer (string3.h:51) ==5569== by 0x41ED6C: search_dir (cmds-restore.c:233) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== Address 0x5d4de70 is 0 bytes after a block of size 4,224 alloc'd ==5569== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x4381B7: alloc_extent_buffer (extent_io.c:574) ==5569== by 0x42B5D8: btrfs_find_create_tree_block (disk-io.c:133) ==5569== by 0x42CD00: read_tree_block (disk-io.c:265) ==5569== by 0x427407: read_node_slot (ctree.c:634) ==5569== by 0x42A1A5: btrfs_search_slot (ctree.c:1113) ==5569== by 0x41EA5A: search_dir (cmds-restore.c:567) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== ==5569== Invalid read of size 2 ==5569== at 0x4C2F7E0: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x4388E6: read_extent_buffer (string3.h:51) ==5569== by 0x41ED6C: search_dir (cmds-restore.c:233) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== Address 0x5d4de76 is 6 bytes after a block of size 4,224 alloc'd ==5569== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x4381B7: alloc_extent_buffer (extent_io.c:574) ==5569== by 0x42B5D8: btrfs_find_create_tree_block (disk-io.c:133) ==5569== by 0x42CD00: read_tree_block (disk-io.c:265) ==5569== by 0x427407: read_node_slot (ctree.c:634) ==5569== by 0x42A1A5: btrfs_search_slot (ctree.c:1113) ==5569== by 0x41EA5A: search_dir (cmds-restore.c:567) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== ==5569== Invalid read of size 8 ==5569== at 0x4C2F790: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x4388E6: read_extent_buffer (string3.h:51) ==5569== by 0x41ED6C: search_dir (cmds-restore.c:233) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== Address 0x5e0cf20 is 0 bytes after a block of size 4,224 alloc'd ==5569== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x4381B7: alloc_extent_buffer (extent_io.c:574) ==5569== by 0x42B5D8: btrfs_find_create_tree_block (disk-io.c:133) ==5569== by 0x42CD00: read_tree_block (disk-io.c:265) ==5569== by 0x427407: read_node_slot (ctree.c:634) ==5569== by 0x42A1A5: btrfs_search_slot (ctree.c:1113) ==5569== by 0x41EA5A: search_dir (cmds-restore.c:567) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== ==5569== Invalid read of size 8 ==5569== at 0x4C2F79E: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x4388E6: read_extent_buffer (string3.h:51) ==5569== by 0x41ED6C: search_dir (cmds-restore.c:233) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== Address 0x5e0cf28 is 8 bytes after a block of size 4,224 alloc'd ==5569== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x4381B7: alloc_extent_buffer (extent_io.c:574) ==5569== by 0x42B5D8: btrfs_find_create_tree_block (disk-io.c:133) ==5569== by 0x42CD00: read_tree_block (disk-io.c:265) ==5569== by 0x427407: read_node_slot (ctree.c:634) ==5569== by 0x42A1A5: btrfs_search_slot (ctree.c:1113) ==5569== by 0x41EA5A: search_dir (cmds-restore.c:567) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== ==5569== Invalid read of size 4 ==5569== at 0x41E394: decompress (cmds-restore.c:93) ==5569== by 0x41F291: search_dir (cmds-restore.c:378) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== Address 0x64a4e6d is 20,477 bytes inside a block of size 20,480 alloc'd ==5569== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x41EF6A: search_dir (cmds-restore.c:309) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== ==5569== Invalid read of size 1 ==5569== at 0x548DDB6: lzo1x_decompress_safe (in /lib/x86_64-linux-gnu/liblzo2.so.2.0.0) ==5569== by 0x41E3BD: decompress (cmds-restore.c:122) ==5569== by 0x41F291: search_dir (cmds-restore.c:378) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== Address 0x64a4e71 is 1 bytes after a block of size 20,480 alloc'd ==5569== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x41EF6A: search_dir (cmds-restore.c:309) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== ==5569== Invalid read of size 1 ==5569== at 0x548DFB0: lzo1x_decompress_safe (in /lib/x86_64-linux-gnu/liblzo2.so.2.0.0) ==5569== by 0x41E3BD: decompress (cmds-restore.c:122) ==5569== by 0x41F291: search_dir (cmds-restore.c:378) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== Address 0x64a4e72 is 2 bytes after a block of size 20,480 alloc'd ==5569== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x41EF6A: search_dir (cmds-restore.c:309) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== ==5569== Invalid write of size 1 ==5569== at 0x548DFB6: lzo1x_decompress_safe (in /lib/x86_64-linux-gnu/liblzo2.so.2.0.0) ==5569== by 0x41E3BD: decompress (cmds-restore.c:122) ==5569== by 0x41F291: search_dir (cmds-restore.c:378) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== Address 0x6b4d430 is 0 bytes after a block of size 131,072 alloc'd ==5569== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x41EFC3: search_dir (cmds-restore.c:316) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== ==5569== Invalid read of size 1 ==5569== at 0x548DFC1: lzo1x_decompress_safe (in /lib/x86_64-linux-gnu/liblzo2.so.2.0.0) ==5569== by 0x41E3BD: decompress (cmds-restore.c:122) ==5569== by 0x41F291: search_dir (cmds-restore.c:378) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== Address 0x64a4e74 is 4 bytes after a block of size 20,480 alloc'd ==5569== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x41EF6A: search_dir (cmds-restore.c:309) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== ==5569== Invalid read of size 1 ==5569== at 0x548DFCA: lzo1x_decompress_safe (in /lib/x86_64-linux-gnu/liblzo2.so.2.0.0) ==5569== by 0x41E3BD: decompress (cmds-restore.c:122) ==5569== by 0x41F291: search_dir (cmds-restore.c:378) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== Address 0x64a4ed6 is not stack'd, malloc'd or (recently) free'd ==5569== ==5569== Invalid read of size 1 ==5569== at 0x548E003: lzo1x_decompress_safe (in /lib/x86_64-linux-gnu/liblzo2.so.2.0.0) ==5569== by 0x41E3BD: decompress (cmds-restore.c:122) ==5569== by 0x41F291: search_dir (cmds-restore.c:378) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) ==5569== Address 0x64a4ed7 is not stack'd, malloc'd or (recently) free'd ==5569== --5569-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --5569-- si_code=80; Faulting address: 0x0; sp: 0x802b99d70 valgrind: the 'impossible' happened: Killed by fatal signal ==5569== at 0x3805BA9A: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==5569== by 0x3805DA02: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==5569== by 0x38021535: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==5569== by 0x3802172B: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==5569== by 0x380218A2: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==5569== by 0x3809DC03: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==5569== by 0x380AC87C: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==5569== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5569== by 0x5943689: strdup (strdup.c:42) ==5569== by 0x41F80E: search_dir (cmds-restore.c:829) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x41FA03: search_dir (cmds-restore.c:895) ==5569== by 0x4205D6: cmd_restore (cmds-restore.c:1284) ==5569== by 0x403F57: main (btrfs.c:286) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-08-25 5:08 fs corruption report Zooko Wilcox-OHearn @ 2014-08-28 2:28 ` Gui Hecheng 2014-09-01 8:47 ` Marc Dietrich 2014-08-28 2:46 ` Gui Hecheng 1 sibling, 1 reply; 19+ messages in thread From: Gui Hecheng @ 2014-08-28 2:28 UTC (permalink / raw) To: Zooko Wilcox-OHearn; +Cc: linux-btrfs, marvin24 On Mon, 2014-08-25 at 05:08 +0000, Zooko Wilcox-OHearn wrote: > Dear people of linux-btrfs: > > Thank you for btrfs! It is a beautiful thing. I say that in spite of > the fact that it seems to have failed and eaten some of my data. > > I'm writing with two purposes: to get help and advice in recovering my > data, to help debug the software. > > I was running linux 3.12.26 and btrfsprogs 3.14, and I started getting > error messages like these in my syslog: > > syslog.7:Aug 16 02:32:35 spark kernel: [48524.140611] btrfs no csum > found for inode 15537898 start 4096 > > It happened only for one of the three partitions on this SSD, and > smartctl indicated no problem with the disk: > > SMART overall-health self-assessment test result: PASSED > … > Num Test_Description Status Remaining > LifeTime(hours) LBA_of_first_error > # 1 Extended offline Completed without error 00% 6406 - > # 2 Extended captive Completed without error 00% 6405 - > > I upgraded my kernel to 3.16.1 and tried the various techniques > suggested in https://btrfs.wiki.kernel.org/index.php/Btrfsck and > https://btrfs.wiki.kernel.org/index.php/Problem_FAQ , including > `btrfsck check --repair --init-csum-tree`. This didn't fix it. > > I made an image of the filesystem in case someone wants to diagnose it > (78 MB), and I also a made a dd copy of the affected partition. > > The `btrfs restore` command aborts even though I've passed the -i > flag. In fact, I see that on subsequent runs it aborts at different > places. > > Looking at the source code > (http://git.kernel.org/cgit/linux/kernel/git/mason/btrfs-progs.git/tree/cmds-restore.c?id=c17d0a73c11d7cdbdf1582408ec6d168876160ea#n819) > I don't see how -6 from decompress could cause it to stop when I have > set `ignore_errors`, so next I ran it under valgrind. > > Aha. When it is run under valgrind it consistently stops (killing > valgrind, in fact!) in the same way on every run. > > Here's the tail of stdout and stderr when it aborted when run under valgrind: > > Restoring ./sda6-btrfs-restore-3/@home/zooko/.mozilla/firefox/ltjwtkwe.ketotic.org/thumbnails/188888af64f6d2871b0f24e325d8a298.png > Restoring ./sda6-btrfs-restofailed to inflate: -6 > > Full valgrind outputs from such a run is attached to this letter. > > I've spent a little time looking at the stack traces in the valgrind > log, and I *guess* that there is corruption such that the > decompression fails, and I guess it would be possible to make > cmds-restore handle corrupted compressedtext better, so that it would > end up skipping whatever files and directories were unrestorable due > to corruption. However, I don't immediately see how to proceed. > > Regards, Hi Zooko， Here are some pieces for your information: For the first: ==5569== Syscall param pwrite64(buf) points to uninitialised byte(s) ==5569== at 0x56ABD03: __pwrite_nocancel (syscall-template.S:81) ==5569== by 0x41F346: search_dir (cmds-restore.c:392) It is handled by https://patchwork.kernel.org/patch/4755441/ For the second: ==5569== Invalid read of size 1 ==5569== at 0x4C2F95E: memcpy@@GLIBC_2.14 ==5569== by 0x4388E6: read_extent_buffer (string3.h:51) ==5569== by 0x41ED6C: search_dir (cmds-restore.c:233) It should be handled by https://patchwork.kernel.org/patch/4792381/ And it handles Marc's similar problem too. And for the last one and the crucial one... ==5569== Invalid read of size 4 ==5569== at 0x41E394: decompress (cmds-restore.c:93) ==5569== by 0x41F291: search_dir (cmds-restore.c:378) along with ==5569== Invalid read of size 1 ==5569== at 0x548DDB6: lzo1x_decompress_safe ==5569== by 0x41E3BD: decompress (cmds-restore.c:122) ==5569== by 0x41F291: search_dir (cmds-restore.c:378) Sorry, I'm not able to reproduce it yet, it may be just what you've guessed that corruption happens. But I am sure that there are bugs around the decompress routine, because I've got "failed to inflate"s too with a non-corrupted btrfs. I'm going to track it down. Thanks, -Gui > Zooko Wilcox-O'Hearn > > Founder, CEO, and Customer Support Rep > https://LeastAuthority.com > Freedom matters. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-08-28 2:28 ` Gui Hecheng @ 2014-09-01 8:47 ` Marc Dietrich 2014-09-01 9:09 ` Marc Dietrich 0 siblings, 1 reply; 19+ messages in thread From: Marc Dietrich @ 2014-09-01 8:47 UTC (permalink / raw) To: Gui Hecheng; +Cc: Zooko Wilcox-OHearn, linux-btrfs [-- Attachment #1: Type: text/plain, Size: 6478 bytes --] Guy, Am Donnerstag 28 August 2014, 10:28:02 schrieb Gui Hecheng: > On Mon, 2014-08-25 at 05:08 +0000, Zooko Wilcox-OHearn wrote: > > Aha. When it is run under valgrind it consistently stops (killing > > valgrind, in fact!) in the same way on every run. > > > > Here's the tail of stdout and stderr when it aborted when run under > > valgrind: > > > > Restoring > > ./sda6-btrfs-restore-3/@home/zooko/.mozilla/firefox/ltjwtkwe.ketotic.org/ > > thumbnails/188888af64f6d2871b0f24e325d8a298.png Restoring > > ./sda6-btrfs-restofailed to inflate: -6 > > > > Full valgrind outputs from such a run is attached to this letter. > > > > I've spent a little time looking at the stack traces in the valgrind > > log, and I *guess* that there is corruption such that the > > decompression fails, and I guess it would be possible to make > > cmds-restore handle corrupted compressedtext better, so that it would > > end up skipping whatever files and directories were unrestorable due > > to corruption. However, I don't immediately see how to proceed. > > > > Regards, > > Hi Zooko， > Here are some pieces for your information: > > For the first: > ==5569== Syscall param pwrite64(buf) points to uninitialised byte(s) > ==5569== at 0x56ABD03: __pwrite_nocancel (syscall-template.S:81) > ==5569== by 0x41F346: search_dir (cmds-restore.c:392) > > It is handled by > https://patchwork.kernel.org/patch/4755441/ > > For the second: > ==5569== Invalid read of size 1 > ==5569== at 0x4C2F95E: memcpy@@GLIBC_2.14 > ==5569== by 0x4388E6: read_extent_buffer (string3.h:51) > ==5569== by 0x41ED6C: search_dir (cmds-restore.c:233) > > It should be handled by > https://patchwork.kernel.org/patch/4792381/ > And it handles Marc's similar problem too. I can confirm that this patch really cures these memleaks, but .... > > And for the last one and the crucial one... > ==5569== Invalid read of size 4 > ==5569== at 0x41E394: decompress (cmds-restore.c:93) > ==5569== by 0x41F291: search_dir (cmds-restore.c:378) > along with > ==5569== Invalid read of size 1 > ==5569== at 0x548DDB6: lzo1x_decompress_safe > ==5569== by 0x41E3BD: decompress (cmds-restore.c:122) > ==5569== by 0x41F291: search_dir (cmds-restore.c:378) > > Sorry, I'm not able to reproduce it yet, it may be just what you've > guessed that corruption happens. But I am sure that there are bugs > around the decompress routine, because I've got "failed to inflate"s too > with a non-corrupted btrfs. I'm going to track it down. this one still exists. It took me a while to reproduce this (actually, find the file which causes it). So we have: ==27292== Invalid read of size 8 ==27292== at 0x57A10D2: lzo1x_decompress_safe (in /usr/lib64/liblzo2.so.2.0.0) ==27292== by 0x41E9ED: decompress (cmds-restore.c:129) ==27292== by 0x41F8A7: search_dir (cmds-restore.c:386) ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) ==27292== by 0x420C6F: cmd_restore (cmds-restore.c:1319) ==27292== by 0x4042FC: main (btrfs.c:247) ==27292== Address 0x6280afc is 24,572 bytes inside a block of size 24,576 alloc'd ==27292== at 0x4C277AB: malloc (in /usr/lib64/valgrind/vgpreload_memcheck- amd64-linux.so) ==27292== by 0x41F577: search_dir (cmds-restore.c:317) ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) ==27292== by 0x420C6F: cmd_restore (cmds-restore.c:1319) ==27292== by 0x4042FC: main (btrfs.c:247) ==27292== ==27292== (action on error) vgdb me ... and the attached debug backtrace is (I attached the full bt): Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000000057a10d2 in lzo1x_decompress_safe () from /usr/lib64/liblzo2.so.2 (gdb) bt #0 0x00000000057a10d2 in lzo1x_decompress_safe () from /usr/lib64/liblzo2.so.2 #1 0x000000000041e9ee in decompress_lzo (decompress_len=0x7feff9f60, compress_len=417, outbuf=0x63229a0 "ource/core/dom/webcore_dom.StaticNodeList.o", inbuf=0x6280a6d "\017ource/core/dom/webl\001") at cmds-restore.c:129 #2 decompress (inbuf=inbuf@entry=0x627ab00 "zU\001", outbuf=outbuf@entry=0x631a9a0 "<X", compress_len=compress_len@entry=24576, decompress_len=decompress_len@entry=0x7feff9f60, compress=compress@entry=2) at cmds-restore.c:155 #3 0x000000000041f8a8 in copy_one_extent (pos=4063232, fi=<optimized out>, leaf=0x5fb58d0, fd=4, root=0x61405c0) at cmds-restore.c:386 #4 copy_file (file=0x66a700 <path_name> "/work/chromium/src/out/Release/.ninja_deps", key=0x7feffb080, fd=4, root=0x61405c0) at cmds-restore.c:659 #5 search_dir (root=root@entry=0x61405c0, key=key@entry=0x7feffc2d0, output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", in_dir=in_dir@entry=0x6602d70 "/chromium/src/out/Release", mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:840 #6 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0, key=key@entry=0x7feffd520, output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", in_dir=in_dir@entry=0x6df4d90 "/chromium/src/out", mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:916 #7 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0, key=key@entry=0x7feffe770, output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", in_dir=in_dir@entry=0x65d7080 "/chromium/src", mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:916 #8 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0, key=key@entry=0x7fefff9c0, output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", in_dir=in_dir@entry=0x6f35ac0 "/chromium", mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:916 #9 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0, key=key@entry=0x7fefffe30, output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", in_dir=in_dir@entry=0x45ab43 "", mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:916 #10 0x0000000000420c70 in cmd_restore (argc=<optimized out>, argv=<optimized out>) at cmds-restore.c:1319 #11 0x00000000004042fd in main (argc=8, argv=0x7feffffa0) at btrfs.c:247 Hope that helps Marc [-- Attachment #2: full-bt.txt --] [-- Type: text/plain, Size: 9356 bytes --] (gdb) bt full #0 0x00000000057a10d2 in lzo1x_decompress_safe () from /usr/lib64/liblzo2.so.2 No symbol table info available. #1 0x000000000041e9ee in decompress_lzo (decompress_len=0x7feff9f60, compress_len=417, outbuf=0x63229a0 "ource/core/dom/webcore_dom.StaticNodeList.o", inbuf=0x6280a6d "\017ource/core/dom/webl\001") at cmds-restore.c:129 ret = <optimized out> new_len = 0 out_len = 32768 tot_in = 24429 #2 decompress (inbuf=inbuf@entry=0x627ab00 "zU\001", outbuf=outbuf@entry=0x631a9a0 "<X", compress_len=compress_len@entry=24576, decompress_len=decompress_len@entry=0x7feff9f60, compress=compress@entry=2) at cmds-restore.c:155 No locals. #3 0x000000000041f8a8 in copy_one_extent (pos=4063232, fi=<optimized out>, leaf=0x5fb58d0, fd=4, root=0x61405c0) at cmds-restore.c:386 device = <optimized out> dev_fd = 5 mirror_num = 1 num_copies = <optimized out> inbuf = 0x627ab00 "zU\001" done = <optimized out> ram_size = 126976 multi = 0x67fa250 outbuf = 0x631a9a0 "<X" total = 0 dev_bytenr = 317671178240 compress = 2 length = 24576 ret = <optimized out> bytenr = 390685646848 size_left = 0 count = 24576 #4 copy_file (file=0x66a700 <path_name> "/work/chromium/src/out/Release/.ninja_deps", key=0x7feffb080, fd=4, root=0x61405c0) at cmds-restore.c:659 fi = <optimized out> ret = <optimized out> compression = 2 found_size = 11632652 leaf = 0x5fb58d0 path = <optimized out> inode_item = <optimized out> extent_type = <optimized out> loops = 33 #5 search_dir (root=root@entry=0x61405c0, key=key@entry=0x7feffc2d0, output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", in_dir=in_dir@entry=0x6602d70 "/chromium/src/out/Release", mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:840 path = <optimized out> leaf = 0x6daaa50 dir_item = <optimized out> location = {objectid = 27472733, type = 108 'l', offset = 0} filename = ".ninja_deps", '\000' <repeats 29 times>, "\021\000\000\000\b\000\000\000\b\000\000\000\020\000\000\000\240r\367\005\000\000\000\000\001\000\000\000\000\000\000\000\300\005\024\006\000\000\000\000\360\225\023\006\000\000\000\000\360M\337\006\000\000\000\000\020w\367\005\000\000\000\000A0\314\005\000\000\000\000@-\024\006\000\000\000\000\030\000\000\000\060\000\000\000\340\260\377\376\a\000\000\000\---Type <return> to continue, or q <return> to quit--- 020\260\377\376\a", '\000' <repeats 20 times>, "\247f\000\000\000\000\000src/out/Release\000\000T\367\005\000\000\000\000\230\260\377\376\a\000\000\000"... name_ptr = <optimized out> name_len = <optimized out> ret = <optimized out> loops = 0 #6 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0, key=key@entry=0x7feffd520, output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", in_dir=in_dir@entry=0x6df4d90 "/chromium/src/out", mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:916 search_root = <optimized out> dir = 0x6602d70 "/chromium/src/out/Release" path = <optimized out> leaf = 0x61395f0 dir_item = <optimized out> location = {objectid = 27470610, type = 96 '`', offset = 0} filename = "Release\000\000\267f", '\000' <repeats 29 times>, "\r\000\000\000\004\000\000\000\004\000\000\000\020\000\000\000\240r\367\005\000\000\000\000\001\000\000\000\000\000\000\000\300\005\024\006\000\000\000\000\020\017\a\006\000\000\000\000\200\234e\006\000\000\000\000\020w\367\005\000\000\000\000A0\314\005\000\000\000\000@-\024\006\000\000\000\000\030\000\000\000\060\000\000\000\060\303\377\376\a\000\000\000`\302\377\376\a", '\000' <repeats 20 times>, "\247f\000\000\000\000\000hromium/src/out\000\000T\367\005\000\000\000\000\002\021\000\000\000\000\000\000"... name_ptr = <optimized out> name_len = <optimized out> ret = <optimized out> loops = 0 #7 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0, key=key@entry=0x7feffe770, output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", in_dir=in_dir@entry=0x65d7080 "/chromium/src", mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:916 search_root = <optimized out> dir = 0x6df4d90 "/chromium/src/out" path = <optimized out> leaf = 0x6070f10 dir_item = <optimized out> location = {objectid = 27469314, type = 96 '`', offset = 0} filename = "out\000\000gnore\000settings", '\000' <repeats 21 times>, "\t\000\000\000\004\000\000\000\004\000\000\000\016\000\000\000\240r\367\005\000\000\000\000\001\000\000\000\000\000\000\000\300\005\024\006\000\000\000\000\000\303\027\a\000\000\000\000\300\226:\006\000\000\000\000\020w\367\005\000\000\000\000A0\314\005\000\000\000\000@-\024\006\000\000\000\000\030\000\000\000\060\000\000\000\200\325\377\376\a\000\000\000\260\324\377\376\a", '\000' <repeats 20 times>, "\247f\000\000\000\000\000ium/src\000\000\000\000\000\000\000\000\000\000T\367\005\000\000\000\000\002\021\000\000\000\000\000\000"... name_ptr = <optimized out> name_len = <optimized out> ret = <optimized out> loops = 0 #8 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0, key=key@entry=0x7fefff9c0, output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", in_dir=in_dir@entry=0x6f35ac0 "/chromium", mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:916 search_root = <optimized out> dir = 0x65d7080 "/chromium/src" path = <optimized out> leaf = 0x717c300 ---Type <return> to continue, or q <return> to quit--- dir_item = <optimized out> location = {objectid = 26833838, type = 96 '`', offset = 0} filename = "src\000ient\000ls", '\000' <repeats 33 times>, "\t\000\000\000\t\000\000\000\n\000\000\000\240r\367\005\000\000\000\000\001\000\000\000\000\000\000\000\300\005\024\006\000\000\000\000\340ȓ\006\000\000\000\000\240N\024\006\000\000\000\000\020w\367\005\000\000\000\000A0\314\005\000\000\000\000@-\024\006\000\000\000\000\030\000\000\000\060\000\000\000\320\347\377\376\a\000\000\000\000\347\377\376\a", '\000' <repeats 20 times>, "\247f\000\000\000\000\000hromium\000\000\000\000\000\000\000\000\000\000T\367\005\000\000\000\000\260\060\375\005\000\000\000\000@"... name_ptr = <optimized out> name_len = <optimized out> ret = <optimized out> loops = 0 #9 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0, key=key@entry=0x7fefffe30, output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", in_dir=in_dir@entry=0x45ab43 "", mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:916 search_root = <optimized out> dir = 0x6f35ac0 "/chromium" path = <optimized out> leaf = 0x693c8e0 dir_item = <optimized out> location = {objectid = 26832818, type = 96 '`', offset = 0} filename = "chromium\000.6.5\000\000\000r_2012_r2_x64_dvd_2707952.iso\000ER_EVAL_DE-DE-IRM_SSS_X64FREE_DE-DE_DV5.ISO\000\000ISO\000\000\002\000\000\000\002\000\000\000\260E\024\006\000\000\000\000\317\003\000\377\a\000\000\000\317\003\000\377\a", '\000' <repeats 31 times>, "\021\000\000\000\021\000\000\000\021\000\000\000\020\000\000\000\020\000\000\000\020\000\000\000\020\000\000\000\020", '\000' <repeats 15 times>... name_ptr = <optimized out> name_len = <optimized out> ret = <optimized out> loops = 0 #10 0x0000000000420c70 in cmd_restore (argc=<optimized out>, argv=<optimized out>) at cmds-restore.c:1319 root = 0x61405c0 key = {objectid = 256, type = 96 '`', offset = 0} dir_name = "/work", '\000' <repeats 122 times> tree_location = <optimized out> fs_location = 0 root_objectid = 0 len = <optimized out> ret = <optimized out> opt = <optimized out> option_index = 0 super_mirror = <optimized out> find_dir = 0 list_roots = 0 match_regstr = 0x7ff0003cf "^/(|temp(|/.*))$" match_cflags = 13 match_reg = {buffer = 0x6142d40 "`.\024\006", allocated = 224, used = 224, syntax = 242620, fastmap = 0x6142c00 "", translate = 0x0, re_nsub = 2, can_be_null = 0, regs_allocated = 0, fastmap_accurate = 1, no_sub = 1, not_bol = 0, not_eol = 0, newline_anchor = 1} mreg = 0x7fefffd60 reg_err = "\377\232f", '\000' <repeats 45 times>, "\370\375\377\376\004\000\000\000H\021\"\004", '\000' <repeats 28 times>, "@\277\0---Type <return> to continue, or q <return> to quit--- 05\004\000\000\000\000\377\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000H\021\"\004\000\000\000\000\377\377\377\377\a\000\000\000\000\375\377\376\a\000\000\000\314?\f\257\000\000\000\000\000T\367\005", '\000' <repeats 12 times>, "\240\024\"\004\000\000\000\000@\375\377\376\a\000\000\000\060\375\377\376\a\000\000\000L\353:}\000\000\000\000"... #11 0x00000000004042fd in main (argc=8, argv=0x7feffffa0) at btrfs.c:247 cmd = 0x6689c8 bname = <optimized out> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-01 8:47 ` Marc Dietrich @ 2014-09-01 9:09 ` Marc Dietrich 2014-09-01 15:25 ` Zooko Wilcox-OHearn 0 siblings, 1 reply; 19+ messages in thread From: Marc Dietrich @ 2014-09-01 9:09 UTC (permalink / raw) To: Gui Hecheng; +Cc: Zooko Wilcox-OHearn, linux-btrfs Am Montag 01 September 2014, 10:47:26 schrieb Marc Dietrich: > Guy, > > Am Donnerstag 28 August 2014, 10:28:02 schrieb Gui Hecheng: > > And for the last one and the crucial one... > > ==5569== Invalid read of size 4 > > ==5569== at 0x41E394: decompress (cmds-restore.c:93) > > ==5569== by 0x41F291: search_dir (cmds-restore.c:378) > > along with > > ==5569== Invalid read of size 1 > > ==5569== at 0x548DDB6: lzo1x_decompress_safe > > ==5569== by 0x41E3BD: decompress (cmds-restore.c:122) > > ==5569== by 0x41F291: search_dir (cmds-restore.c:378) > > > > Sorry, I'm not able to reproduce it yet, it may be just what you've > > guessed that corruption happens. But I am sure that there are bugs > > around the decompress routine, because I've got "failed to inflate"s too > > with a non-corrupted btrfs. I'm going to track it down. > > this one still exists. It took me a while to reproduce this (actually, find > the file which causes it). So we have: > > ==27292== Invalid read of size 8 > ==27292== at 0x57A10D2: lzo1x_decompress_safe (in > /usr/lib64/liblzo2.so.2.0.0) > ==27292== by 0x41E9ED: decompress (cmds-restore.c:129) > ==27292== by 0x41F8A7: search_dir (cmds-restore.c:386) > ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) > ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) > ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) > ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) > ==27292== by 0x420C6F: cmd_restore (cmds-restore.c:1319) > ==27292== by 0x4042FC: main (btrfs.c:247) > ==27292== Address 0x6280afc is 24,572 bytes inside a block of size 24,576 > alloc'd > ==27292== at 0x4C277AB: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck- amd64-linux.so) > ==27292== by 0x41F577: search_dir (cmds-restore.c:317) > ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) > ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) > ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) > ==27292== by 0x41FFE6: search_dir (cmds-restore.c:916) > ==27292== by 0x420C6F: cmd_restore (cmds-restore.c:1319) > ==27292== by 0x4042FC: main (btrfs.c:247) > ==27292== > ==27292== (action on error) vgdb me ... > > and the attached debug backtrace is (I attached the full bt): > > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x00000000057a10d2 in lzo1x_decompress_safe () from /usr/lib64/liblzo2.so.2 > (gdb) bt > #0 0x00000000057a10d2 in lzo1x_decompress_safe () from > /usr/lib64/liblzo2.so.2 after installing debuginfo for liblzo I get #0 lzo1x_decompress_safe (in=0x1 <error: Cannot access memory at address 0x1>, in@entry=0x6280a6d "\017ource/core/dom/webl\001", in_len=103290581, in_len@entry=3176, out=out@entry=0x63229a0 "ource/core/dom/webcore_dom.StaticNodeList.o", out_len=out_len@entry=0x7feff9de0, wrkmem=0x6322a55, wrkmem@entry=0x0) at src/lzo1x_d.ch:184 ip = 0x1 <error: Cannot access memory at address 0x1> ip_end = 0x62816d5 "" op_end = 0x6323ae3 "" I'll keep the debug session open just in case. Marc > #1 0x000000000041e9ee in decompress_lzo (decompress_len=0x7feff9f60, > compress_len=417, > outbuf=0x63229a0 "ource/core/dom/webcore_dom.StaticNodeList.o", > inbuf=0x6280a6d "\017ource/core/dom/webl\001") at cmds-restore.c:129 > #2 decompress (inbuf=inbuf@entry=0x627ab00 "zU\001", > outbuf=outbuf@entry=0x631a9a0 "<X", compress_len=compress_len@entry=24576, > decompress_len=decompress_len@entry=0x7feff9f60, > compress=compress@entry=2) at cmds-restore.c:155 > #3 0x000000000041f8a8 in copy_one_extent (pos=4063232, fi=<optimized out>, > leaf=0x5fb58d0, fd=4, root=0x61405c0) at cmds-restore.c:386 > #4 copy_file (file=0x66a700 <path_name> > "/work/chromium/src/out/Release/.ninja_deps", key=0x7feffb080, fd=4, > root=0x61405c0) > at cmds-restore.c:659 > #5 search_dir (root=root@entry=0x61405c0, key=key@entry=0x7feffc2d0, > output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", > in_dir=in_dir@entry=0x6602d70 "/chromium/src/out/Release", > mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:840 > #6 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0, > key=key@entry=0x7feffd520, > output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", > in_dir=in_dir@entry=0x6df4d90 "/chromium/src/out", > mreg=mreg@entry=0x7fefffd60) at cmds-restore.c:916 > #7 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0, > key=key@entry=0x7feffe770, > output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", > in_dir=in_dir@entry=0x65d7080 "/chromium/src", mreg=mreg@entry=0x7fefffd60) > at cmds-restore.c:916 > #8 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0, > key=key@entry=0x7fefff9c0, > output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", > in_dir=in_dir@entry=0x6f35ac0 "/chromium", mreg=mreg@entry=0x7fefffd60) > at cmds-restore.c:916 > #9 0x000000000041ffe7 in search_dir (root=root@entry=0x61405c0, > key=key@entry=0x7fefffe30, > output_rootdir=output_rootdir@entry=0x7fefffdb0 "/work", > in_dir=in_dir@entry=0x45ab43 "", mreg=mreg@entry=0x7fefffd60) > at cmds-restore.c:916 > #10 0x0000000000420c70 in cmd_restore (argc=<optimized out>, argv=<optimized > out>) at cmds-restore.c:1319 > #11 0x00000000004042fd in main (argc=8, argv=0x7feffffa0) at btrfs.c:247 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-01 9:09 ` Marc Dietrich @ 2014-09-01 15:25 ` Zooko Wilcox-OHearn 2014-09-04 3:00 ` Gui Hecheng 2014-09-18 3:39 ` Gui Hecheng 0 siblings, 2 replies; 19+ messages in thread From: Zooko Wilcox-OHearn @ 2014-09-01 15:25 UTC (permalink / raw) To: Marc Dietrich; +Cc: Gui Hecheng, linux-btrfs I'm more than happy to try out patches and even focus my own brain on diagnosing it, if I can. I'm hoping to regain access to some of my files on my btrfs partition, and also I would enjoy helping get this improved. :-) So if you want me to try an experiment, just email me. Unfortunately I can't just give you a copy of the partition, since it has confidential information on it. Regards, Zooko ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-01 15:25 ` Zooko Wilcox-OHearn @ 2014-09-04 3:00 ` Gui Hecheng 2014-09-04 9:50 ` Marc Dietrich 2014-09-18 3:39 ` Gui Hecheng 1 sibling, 1 reply; 19+ messages in thread From: Gui Hecheng @ 2014-09-04 3:00 UTC (permalink / raw) To: Zooko Wilcox-OHearn; +Cc: Marc Dietrich, linux-btrfs On Mon, 2014-09-01 at 15:25 +0000, Zooko Wilcox-OHearn wrote: > I'm more than happy to try out patches and even focus my own brain on > diagnosing it, if I can. I'm hoping to regain access to some of my > files on my btrfs partition, and also I would enjoy helping get this > improved. :-) > > So if you want me to try an experiment, just email me. Unfortunately I > can't just give you a copy of the partition, since it has confidential > information on it. > > Regards, > > Zooko Hi Zooko, Marc, Firstly, thanks for your backtrace info, Marc. Sorry to reply late, since I'm offline these days. For the restore problem, I'm sure that the lzo decompress routine lacks the ability to handle some specific extent pattern. Here is my test result: I'm using a specific file for test /usr/lib/modules/$(uname -r)/kernel/net/irda/irda.ko. You can get it easily on your own box. # mkfs -t btrfs <dev> # mount -o compress-force=lzo <dev> <mnt> # cp irda.ko <mnt> # umount <dev> # btrfs restore -v <dev> <restore_dir> report: # bad compress length # failed to inflate btrfs-progs version: v3.16.x With the same file under no-compress & zlib-compress, the restore will output a correct copy of irda.ko. I'm not sure whether the problem above has something to do with your problem. Hope that the messages above are helpful. -Gui ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-04 3:00 ` Gui Hecheng @ 2014-09-04 9:50 ` Marc Dietrich 2014-09-12 12:35 ` Marc Dietrich 0 siblings, 1 reply; 19+ messages in thread From: Marc Dietrich @ 2014-09-04 9:50 UTC (permalink / raw) To: Gui Hecheng; +Cc: Zooko Wilcox-OHearn, linux-btrfs [-- Attachment #1: Type: text/plain, Size: 1833 bytes --] Hello Guy, Am Donnerstag, 4. September 2014, 11:00:55 schrieb Gui Hecheng: > On Mon, 2014-09-01 at 15:25 +0000, Zooko Wilcox-OHearn wrote: > > I'm more than happy to try out patches and even focus my own brain on > > diagnosing it, if I can. I'm hoping to regain access to some of my > > files on my btrfs partition, and also I would enjoy helping get this > > improved. :-) > > > > So if you want me to try an experiment, just email me. Unfortunately I > > can't just give you a copy of the partition, since it has confidential > > information on it. > > > > Regards, > > > > Zooko > > Hi Zooko, Marc, > > Firstly, thanks for your backtrace info, Marc. > Sorry to reply late, since I'm offline these days. > For the restore problem, I'm sure that the lzo decompress routine lacks > the ability to handle some specific extent pattern. > > Here is my test result: > I'm using a specific file for test > /usr/lib/modules/$(uname -r)/kernel/net/irda/irda.ko. > You can get it easily on your own box. > > # mkfs -t btrfs <dev> > # mount -o compress-force=lzo <dev> <mnt> > # cp irda.ko <mnt> > # umount <dev> > # btrfs restore -v <dev> <restore_dir> > report: > # bad compress length > # failed to inflate uh, that's really odd. I don't use force compress, but I guess it will also happen with non-forced one if the file is big enough. > btrfs-progs version: v3.16.x > > With the same file under no-compress & zlib-compress, > the restore will output a correct copy of irda.ko. > > I'm not sure whether the problem above has something to do with your > problem. Hope that the messages above are helpful. I also get lot's of "bad compress length", so it might be indeed related. I'm not a programmer, but is it possible that we are just skipping the lzo header (magic + header len + rest of header)? Thanks, Marc [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-04 9:50 ` Marc Dietrich @ 2014-09-12 12:35 ` Marc Dietrich 0 siblings, 0 replies; 19+ messages in thread From: Marc Dietrich @ 2014-09-12 12:35 UTC (permalink / raw) To: Gui Hecheng; +Cc: Zooko Wilcox-OHearn, linux-btrfs [-- Attachment #1: Type: text/plain, Size: 1520 bytes --] Hello Guy, Am Donnerstag, 4. September 2014, 11:50:14 schrieb Marc Dietrich: > Am Donnerstag, 4. September 2014, 11:00:55 schrieb Gui Hecheng: > > Hi Zooko, Marc, > > > > Firstly, thanks for your backtrace info, Marc. > > Sorry to reply late, since I'm offline these days. > > For the restore problem, I'm sure that the lzo decompress routine lacks > > the ability to handle some specific extent pattern. > > > > Here is my test result: > > I'm using a specific file for test > > /usr/lib/modules/$(uname -r)/kernel/net/irda/irda.ko. > > You can get it easily on your own box. > > > > # mkfs -t btrfs <dev> > > # mount -o compress-force=lzo <dev> <mnt> > > # cp irda.ko <mnt> > > # umount <dev> > > # btrfs restore -v <dev> <restore_dir> > > > > report: > > # bad compress length > > # failed to inflate > > uh, that's really odd. I don't use force compress, but I guess it will also > happen with non-forced one if the file is big enough. > > > btrfs-progs version: v3.16.x > > > > With the same file under no-compress & zlib-compress, > > the restore will output a correct copy of irda.ko. > > > > I'm not sure whether the problem above has something to do with your > > problem. Hope that the messages above are helpful. > > I also get lot's of "bad compress length", so it might be indeed related. > > I'm not a programmer, but is it possible that we are just skipping the lzo > header (magic + header len + rest of header)? I'm able to reproduce it. Any improved insight into this problem? Marc [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-01 15:25 ` Zooko Wilcox-OHearn 2014-09-04 3:00 ` Gui Hecheng @ 2014-09-18 3:39 ` Gui Hecheng 2014-09-18 8:16 ` Marc Dietrich 1 sibling, 1 reply; 19+ messages in thread From: Gui Hecheng @ 2014-09-18 3:39 UTC (permalink / raw) To: Zooko Wilcox-OHearn; +Cc: Marc Dietrich, linux-btrfs On Mon, 2014-09-01 at 15:25 +0000, Zooko Wilcox-OHearn wrote: > I'm more than happy to try out patches and even focus my own brain on > diagnosing it, if I can. I'm hoping to regain access to some of my > files on my btrfs partition, and also I would enjoy helping get this > improved. :-) > > So if you want me to try an experiment, just email me. Unfortunately I > can't just give you a copy of the partition, since it has confidential > information on it. > > Regards, > > Zooko Hi, Zooko, Marc, I'm glad that I could send some feedbacks, The following piece deals with the lzo decompress problem with restore https://patchwork.kernel.org/patch/4928831/ Hope that it helps. -Gui ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-18 3:39 ` Gui Hecheng @ 2014-09-18 8:16 ` Marc Dietrich 2014-09-18 12:47 ` Zooko Wilcox-OHearn 0 siblings, 1 reply; 19+ messages in thread From: Marc Dietrich @ 2014-09-18 8:16 UTC (permalink / raw) To: Gui Hecheng; +Cc: Zooko Wilcox-OHearn, linux-btrfs [-- Attachment #1: Type: text/plain, Size: 859 bytes --] Am Donnerstag, 18. September 2014, 11:39:21 schrieb Gui Hecheng: > On Mon, 2014-09-01 at 15:25 +0000, Zooko Wilcox-OHearn wrote: > > I'm more than happy to try out patches and even focus my own brain on > > diagnosing it, if I can. I'm hoping to regain access to some of my > > files on my btrfs partition, and also I would enjoy helping get this > > improved. :-) > > > > So if you want me to try an experiment, just email me. Unfortunately I > > can't just give you a copy of the partition, since it has confidential > > information on it. > > > > Regards, > > > > Zooko > > Hi, Zooko, Marc, > I'm glad that I could send some feedbacks, > The following piece deals with the lzo decompress problem with restore > > https://patchwork.kernel.org/patch/4928831/ > > Hope that it helps. Thanks for finding this issue, Gui! I just started a restore. Marc [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-18 8:16 ` Marc Dietrich @ 2014-09-18 12:47 ` Zooko Wilcox-OHearn 2014-09-19 1:30 ` Gui Hecheng 0 siblings, 1 reply; 19+ messages in thread From: Zooko Wilcox-OHearn @ 2014-09-18 12:47 UTC (permalink / raw) To: Marc Dietrich; +Cc: Gui Hecheng, linux-btrfs Thank you! I will try to restore using this patch. What branch of what btrfs tools git repo should I apply the patch to? Regards, Zooko ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-18 12:47 ` Zooko Wilcox-OHearn @ 2014-09-19 1:30 ` Gui Hecheng 2014-09-22 8:19 ` Marc Dietrich 2014-09-22 15:05 ` Zooko Wilcox-OHearn 0 siblings, 2 replies; 19+ messages in thread From: Gui Hecheng @ 2014-09-19 1:30 UTC (permalink / raw) To: Zooko Wilcox-OHearn; +Cc: Marc Dietrich, linux-btrfs On Thu, 2014-09-18 at 12:47 +0000, Zooko Wilcox-OHearn wrote: > Thank you! I will try to restore using this patch. > > What branch of what btrfs tools git repo should I apply the patch to? > > Regards, > > Zooko At least I think the following repo/v3.17.x branch has all restore-related patches included. git://github.com/kdave/btrfs-progs.git This is a mirror of the latest devel repo that I am on. -Gui ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-19 1:30 ` Gui Hecheng @ 2014-09-22 8:19 ` Marc Dietrich 2014-09-22 8:33 ` Gui Hecheng 2014-09-22 15:05 ` Zooko Wilcox-OHearn 1 sibling, 1 reply; 19+ messages in thread From: Marc Dietrich @ 2014-09-22 8:19 UTC (permalink / raw) To: Gui Hecheng; +Cc: Zooko Wilcox-OHearn, linux-btrfs [-- Attachment #1: Type: text/plain, Size: 635 bytes --] Hi, Am Freitag, 19. September 2014, 09:30:30 schrieb Gui Hecheng: > On Thu, 2014-09-18 at 12:47 +0000, Zooko Wilcox-OHearn wrote: > > Thank you! I will try to restore using this patch. > > > > What branch of what btrfs tools git repo should I apply the patch to? > > > > Regards, > > > > Zooko > > At least I think the following repo/v3.17.x branch has all > restore-related patches included. > > git://github.com/kdave/btrfs-progs.git > > This is a mirror of the latest devel repo that I am on. restore of my corrupted partition finished. No "bad compress" nor valgrind errors anymore. I'll close the bug. Many thanks! Marc [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-22 8:19 ` Marc Dietrich @ 2014-09-22 8:33 ` Gui Hecheng 2014-09-22 8:49 ` Marc Dietrich 0 siblings, 1 reply; 19+ messages in thread From: Gui Hecheng @ 2014-09-22 8:33 UTC (permalink / raw) To: Marc Dietrich; +Cc: Zooko Wilcox-OHearn, linux-btrfs On Mon, 2014-09-22 at 10:19 +0200, Marc Dietrich wrote: > Hi, > > Am Freitag, 19. September 2014, 09:30:30 schrieb Gui Hecheng: > > On Thu, 2014-09-18 at 12:47 +0000, Zooko Wilcox-OHearn wrote: > > > Thank you! I will try to restore using this patch. > > > > > > What branch of what btrfs tools git repo should I apply the patch to? > > > > > > Regards, > > > > > > Zooko > > > > At least I think the following repo/v3.17.x branch has all > > restore-related patches included. > > > > git://github.com/kdave/btrfs-progs.git > > > > This is a mirror of the latest devel repo that I am on. > > restore of my corrupted partition finished. No "bad compress" nor valgrind > errors anymore. I'll close the bug. > > Many thanks! > > Marc Hi Marc, I'm very glad to hear the result. I've sent a v2 patch which adopts your idea. I also add your sign-off-by, please help me to check whether it matches your thoughts, or more could be done to improve. Thanks, -Gui ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-22 8:33 ` Gui Hecheng @ 2014-09-22 8:49 ` Marc Dietrich 2014-09-22 8:55 ` Gui Hecheng 0 siblings, 1 reply; 19+ messages in thread From: Marc Dietrich @ 2014-09-22 8:49 UTC (permalink / raw) To: Gui Hecheng; +Cc: Zooko Wilcox-OHearn, linux-btrfs [-- Attachment #1: Type: text/plain, Size: 1166 bytes --] Am Montag, 22. September 2014, 16:33:56 schrieb Gui Hecheng: > On Mon, 2014-09-22 at 10:19 +0200, Marc Dietrich wrote: > > Hi, > > > > Am Freitag, 19. September 2014, 09:30:30 schrieb Gui Hecheng: > > > On Thu, 2014-09-18 at 12:47 +0000, Zooko Wilcox-OHearn wrote: > > > > Thank you! I will try to restore using this patch. > > > > > > > > What branch of what btrfs tools git repo should I apply the patch to? > > > > > > > > Regards, > > > > > > > > Zooko > > > > > > At least I think the following repo/v3.17.x branch has all > > > restore-related patches included. > > > > > > git://github.com/kdave/btrfs-progs.git > > > > > > This is a mirror of the latest devel repo that I am on. > > > > restore of my corrupted partition finished. No "bad compress" nor valgrind > > errors anymore. I'll close the bug. > > > > Many thanks! > > > > Marc > > Hi Marc, > I'm very glad to hear the result. > I've sent a v2 patch which adopts your idea. I also add your > sign-off-by, please help me to check whether it matches your thoughts, > or more could be done to improve. well, I didn't wrote any code. So it's enough to just add my reviewed-by. Thanks! Marc [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-22 8:49 ` Marc Dietrich @ 2014-09-22 8:55 ` Gui Hecheng 0 siblings, 0 replies; 19+ messages in thread From: Gui Hecheng @ 2014-09-22 8:55 UTC (permalink / raw) To: Marc Dietrich; +Cc: Zooko Wilcox-OHearn, linux-btrfs On Mon, 2014-09-22 at 10:49 +0200, Marc Dietrich wrote: > Am Montag, 22. September 2014, 16:33:56 schrieb Gui Hecheng: > > On Mon, 2014-09-22 at 10:19 +0200, Marc Dietrich wrote: > > > Hi, > > > > > > Am Freitag, 19. September 2014, 09:30:30 schrieb Gui Hecheng: > > > > On Thu, 2014-09-18 at 12:47 +0000, Zooko Wilcox-OHearn wrote: > > > > > Thank you! I will try to restore using this patch. > > > > > > > > > > What branch of what btrfs tools git repo should I apply the patch to? > > > > > > > > > > Regards, > > > > > > > > > > Zooko > > > > > > > > At least I think the following repo/v3.17.x branch has all > > > > restore-related patches included. > > > > > > > > git://github.com/kdave/btrfs-progs.git > > > > > > > > This is a mirror of the latest devel repo that I am on. > > > > > > restore of my corrupted partition finished. No "bad compress" nor valgrind > > > errors anymore. I'll close the bug. > > > > > > Many thanks! > > > > > > Marc > > > > Hi Marc, > > I'm very glad to hear the result. > > I've sent a v2 patch which adopts your idea. I also add your > > sign-off-by, please help me to check whether it matches your thoughts, > > or more could be done to improve. > > well, I didn't wrote any code. So it's enough to just add my reviewed-by. > > Thanks! > > Marc OK, I will add a reviewed-by instead. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-09-19 1:30 ` Gui Hecheng 2014-09-22 8:19 ` Marc Dietrich @ 2014-09-22 15:05 ` Zooko Wilcox-OHearn 1 sibling, 0 replies; 19+ messages in thread From: Zooko Wilcox-OHearn @ 2014-09-22 15:05 UTC (permalink / raw) To: Gui Hecheng; +Cc: Marc Dietrich, linux-btrfs I guess I'll wait until there's a git repo (maybe one of these branches https://github.com/kdave/btrfs-progs/branches/active ?) with the fix integrated and then I'll test "btrfs restore" using that. Thanks! Regards, Zooko ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-08-25 5:08 fs corruption report Zooko Wilcox-OHearn 2014-08-28 2:28 ` Gui Hecheng @ 2014-08-28 2:46 ` Gui Hecheng 2014-08-28 3:23 ` Chris Murphy 1 sibling, 1 reply; 19+ messages in thread From: Gui Hecheng @ 2014-08-28 2:46 UTC (permalink / raw) To: Zooko Wilcox-OHearn; +Cc: linux-btrfs BTW，there is a develop branch from the btrfs-progs's maintainer David: http://github.com/kdave/btrfs-progs.git Maybe you'd like to try it, it may make some differences. -Gui On Mon, 2014-08-25 at 05:08 +0000, Zooko Wilcox-OHearn wrote: > Dear people of linux-btrfs: > > Thank you for btrfs! It is a beautiful thing. I say that in spite of > the fact that it seems to have failed and eaten some of my data. > > I'm writing with two purposes: to get help and advice in recovering my > data, to help debug the software. > > I was running linux 3.12.26 and btrfsprogs 3.14, and I started getting > error messages like these in my syslog: > > syslog.7:Aug 16 02:32:35 spark kernel: [48524.140611] btrfs no csum > found for inode 15537898 start 4096 > > It happened only for one of the three partitions on this SSD, and > smartctl indicated no problem with the disk: > > SMART overall-health self-assessment test result: PASSED > … > Num Test_Description Status Remaining > LifeTime(hours) LBA_of_first_error > # 1 Extended offline Completed without error 00% 6406 - > # 2 Extended captive Completed without error 00% 6405 - > > I upgraded my kernel to 3.16.1 and tried the various techniques > suggested in https://btrfs.wiki.kernel.org/index.php/Btrfsck and > https://btrfs.wiki.kernel.org/index.php/Problem_FAQ , including > `btrfsck check --repair --init-csum-tree`. This didn't fix it. > > I made an image of the filesystem in case someone wants to diagnose it > (78 MB), and I also a made a dd copy of the affected partition. > > The `btrfs restore` command aborts even though I've passed the -i > flag. In fact, I see that on subsequent runs it aborts at different > places. > > Looking at the source code > (http://git.kernel.org/cgit/linux/kernel/git/mason/btrfs-progs.git/tree/cmds-restore.c?id=c17d0a73c11d7cdbdf1582408ec6d168876160ea#n819) > I don't see how -6 from decompress could cause it to stop when I have > set `ignore_errors`, so next I ran it under valgrind. > > Aha. When it is run under valgrind it consistently stops (killing > valgrind, in fact!) in the same way on every run. > > Here's the tail of stdout and stderr when it aborted when run under valgrind: > > Restoring ./sda6-btrfs-restore-3/@home/zooko/.mozilla/firefox/ltjwtkwe.ketotic.org/thumbnails/188888af64f6d2871b0f24e325d8a298.png > Restoring ./sda6-btrfs-restofailed to inflate: -6 > > Full valgrind outputs from such a run is attached to this letter. > > I've spent a little time looking at the stack traces in the valgrind > log, and I *guess* that there is corruption such that the > decompression fails, and I guess it would be possible to make > cmds-restore handle corrupted compressedtext better, so that it would > end up skipping whatever files and directories were unrestorable due > to corruption. However, I don't immediately see how to proceed. > > Regards, > > Zooko Wilcox-O'Hearn > > Founder, CEO, and Customer Support Rep > https://LeastAuthority.com > Freedom matters. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: fs corruption report 2014-08-28 2:46 ` Gui Hecheng @ 2014-08-28 3:23 ` Chris Murphy 0 siblings, 0 replies; 19+ messages in thread From: Chris Murphy @ 2014-08-28 3:23 UTC (permalink / raw) To: Btrfs BTRFS On Aug 27, 2014, at 8:46 PM, Gui Hecheng <guihc.fnst@cn.fujitsu.com> wrote: > BTW，there is a develop branch from the btrfs-progs's maintainer David: > http://github.com/kdave/btrfs-progs.git > > Maybe you'd like to try it, it may make some differences. > I think the current development version is here: git://repo.or.cz/btrfs-progs-unstable/devel.git integration-20140827 And current stable went to v3.16 in master branch here: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git I'd probably try 3.16 first? *shrug* At least do a btrfs check only without --repair and see what it says. Chris Murphy ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2014-09-22 15:05 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-08-25 5:08 fs corruption report Zooko Wilcox-OHearn 2014-08-28 2:28 ` Gui Hecheng 2014-09-01 8:47 ` Marc Dietrich 2014-09-01 9:09 ` Marc Dietrich 2014-09-01 15:25 ` Zooko Wilcox-OHearn 2014-09-04 3:00 ` Gui Hecheng 2014-09-04 9:50 ` Marc Dietrich 2014-09-12 12:35 ` Marc Dietrich 2014-09-18 3:39 ` Gui Hecheng 2014-09-18 8:16 ` Marc Dietrich 2014-09-18 12:47 ` Zooko Wilcox-OHearn 2014-09-19 1:30 ` Gui Hecheng 2014-09-22 8:19 ` Marc Dietrich 2014-09-22 8:33 ` Gui Hecheng 2014-09-22 8:49 ` Marc Dietrich 2014-09-22 8:55 ` Gui Hecheng 2014-09-22 15:05 ` Zooko Wilcox-OHearn 2014-08-28 2:46 ` Gui Hecheng 2014-08-28 3:23 ` Chris Murphy
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.