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