On Mon, 2014-08-25 at 10:58 +0200, Marc Dietrich wrote: > Am Freitag 22 August 2014, 10:42:18 schrieb Marc Dietrich: > > Am Freitag, 22. August 2014, 14:43:45 schrieb Gui Hecheng: > > > On Thu, 2014-08-21 at 16:19 +0200, Marc Dietrich wrote: > > > > Am Donnerstag, 21. August 2014, 17:52:16 schrieb Gui Hecheng: > > > > > On Mon, 2014-08-18 at 11:25 +0200, Marc Dietrich wrote: > > > > > > Hi, > > > > > > > > > > > > I did a checkout of the latest btrfs progs to repair my damaged > > > > > > filesystem. > > > > > > Running btrfs restore gives me several failed to inflate: -6 and > > > > > > crashes > > > > > > with some memory corruption. I ran it again with valgrind and got: > > > > > > > > > > > > valgrind --log-file=x2 -v --leak-check=yes btrfs restore /dev/sda9 > > > > > > /mnt/backup > > > > > > > > > > > > ==8528== Memcheck, a memory error detector > > > > > > ==8528== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et > > > > > > al. > > > > > > ==8528== Using Valgrind-3.8.1 and LibVEX; rerun with -h for > > > > > > copyright > > > > > > info > > > > > > ==8528== Command: btrfs restore /dev/sda9 /mnt/backup > > > > > > ==8528== Parent PID: 8453 > > > > > > ==8528== > > > > > > ==8528== Syscall param pwrite64(buf) points to uninitialised byte(s) > > > > > > ==8528== at 0x59BE3C3: __pwrite_nocancel (in > > > > > > /lib64/libpthread-2.18.so) > > > > > > ==8528== by 0x41F22F: search_dir (cmds-restore.c:392) > > > > > > ==8528== by 0x41F8D0: search_dir (cmds-restore.c:895) > > > > > > ==8528== by 0x41F8D0: search_dir (cmds-restore.c:895) > > > > > > ==8528== by 0x41F8D0: search_dir (cmds-restore.c:895) > > > > > > ==8528== by 0x41F8D0: search_dir (cmds-restore.c:895) > > > > > > ==8528== by 0x41F8D0: search_dir (cmds-restore.c:895) > > > > > > ==8528== by 0x4204B8: cmd_restore (cmds-restore.c:1284) > > > > > > ==8528== by 0x4043FE: main (btrfs.c:286) > > > > > > ==8528== Address 0x66956a0 is 7,056 bytes inside a block of size > > > > > > 8,192 > > > > > > alloc'd > > > > > > ==8528== at 0x4C277AB: malloc (in > > > > > > /usr/lib64/valgrind/vgpreload_memcheck- amd64-linux.so) > > > > > > ==8528== by 0x41EEAD: search_dir (cmds-restore.c:316) > > > > > > ==8528== by 0x41F8D0: search_dir (cmds-restore.c:895) > > > > > > ==8528== by 0x41F8D0: search_dir (cmds-restore.c:895) > > > > > > ==8528== by 0x41F8D0: search_dir (cmds-restore.c:895) > > > > > > ==8528== by 0x41F8D0: search_dir (cmds-restore.c:895) > > > > > > ==8528== by 0x41F8D0: search_dir (cmds-restore.c:895) > > > > > > ==8528== by 0x4204B8: cmd_restore (cmds-restore.c:1284) > > > > > > ==8528== by 0x4043FE: main (btrfs.c:286) > > > > > > > > > > -------------------[snip]--------------------------------- > > > > > .... leaks ... > > > > > ---------------------------------------------------------- > > > > > > For the leak below... > > > I've no idea why the @decompress_lzo() is not statisfied with @inbuf > > > with the exact size of the disk bytes. > > > Or maybe the compressed data had just sufferred damages... > > > > > > BTW, when you wrote your data, did that kernel has the following commit > > > for btrfs? > > > > > > commit: 59516f6017c589e7316418fda6128ba8f829a77f > > > > mmh, I used the master branch which is still on 3.14.2 (from k.org). > > > > Ah, there is a development branch on another repo (repo.or.cz). Why oh why? > > Guy, > > sorry to quote an earlier mail, I forgot to add you as CC on you latest post > and I'm not subscribed to the list. > > > There is a development branch for btrfs-progs from david: > > http://github.com/kdave/btrfs-progs.git if you would like to try. > > ok, thanks will try. > > > But here, what I mean is your *kernel* version when you wrote your data. > > I'm using btrfs since 3.14 or so (and maybe also some random distro kernel > based on 3.11). The partition contained a lot of larger git trees and virtual > machines - yes, not ideal for btrfs but a nice testcase ... > > > There is a change for btrfs-restore which depends on a kernel commit. > > If you wrote your data with a older kernel and apply the 3.14.2 > > btrfs-progs to restore, then there may be wandering stuffs. > > wow. That should never happend I think. Userspace should always be able to > fix > corruptions made by earlier kernels (except disk layout changes maybe). > > > Now, I am just suspecting such a scenario. > > Possbile. So how to proceed? If I checkout the latest brtfs from the repo > above and restore again, are you still interested in the results?
Ah, I think you could clone the progs from the repo and apply the two small pieces that I mentioned before. Yes, I am still trying to follow the issues with restore. It seems btrfs-restore needs more effect from btrfs developers since it doesn't survive tough scenarioes. > It seems there are lots of people reporting corruptions on the list and also > lots of fixes posted. Maybe it's better to restart from new (format a the > partiton) and report problems happen after that. What do you think? Oh, I think you've just found a really good case for btrfs-restore. Maybe you could keep a image of that, just like Zooko did here: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg36701.html Thanks, -Gui > Marc -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
