Hello Shawn, it's now performing a sequential read of the volume, which will probably take significantly more time for you than for me (where I was dealing with an image of a 16GB SD card, stored on a recent mechanical SATA disk). I'm a bit confused by what happens while reading the "potential supers". At first the blocks appear valid, then they are all "misplaced" (meaning the bytenr field != the bytenr from which the block has been read, IOW the block is most probably not part of btrfs structures, from what I understand). From the output before the "will attempt to find useful trees" messages, it seems btrfsck is now doing a sequential read not just of /dev/sde, but also every single block device ? disk-io.c: try_emergency_tree_fixup() is probably now a bit too silent for your use case at the moment. You might want to uncomment the commented out fprintf there; this will make it very verbose (an extra line per structure block) but will provide clues as to where on disk is it working. -- Cyrille Le jeudi 27 janvier 2011 Ã 01:18 -0500, Shawn Stricker a Ãcrit : > any chance of getting a little more informative output? > I started the command at about 2250 Eastern and now at 0117 Eastern the command is still running and all of the attached output happened in the first few minutes (under 5). > On Jan 26, 2011, at 2:46 AM, Cyrille ChÃpÃlov wrote: > > > Le mardi 25 janvier 2011 Ã 23:38 -0500, Shawn Stricker a Ãcrit : > >> Not sure where you pulled your source from but a fresh checkout of either master or next of git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git does not compile properly. > >> They both fail with > >> > >> cc1: warnings being treated as errors > >> disk-io.c: In function âbtrfs_read_dev_superâ: > >> disk-io.c:937: error: format â%luâ expects type âlong unsigned intâ, but argument 4 has type âunsigned intâ > >> disk-io.c:957: error: implicit declaration of function âuuid_unparseâ > >> > >> am I patching/compiling from the wrong source or is there something I am missing? > > > > uh, I had been compiling with CFLAGS=-g, where the makefile specifies > > "-O2 -Werror" > > > > -Werror causes warnings to be treated as errors, which is a good thing > > in a way (makes sure stuff as this gets caught :) ) > > > > fixes are: > > * line 937 (patched), should be %llu instead of %lu > > * line 957, there should be a prototype for uuid_unparse(), most > > certainly by including <uuid/uuid.h> > > > > please try this patch instead. > > > > Thanks for the feedback! > > > > -- Cyrille > > > >> On Jan 25, 2011, at 1:46 PM, Cyrille ChÃpÃlov wrote: > >> > >>> Hello all, > >>> > >>> Last Friday, the /var and /home partition on one of my appliances became > >>> full. This should normally not be much of a problem, except that after > >>> the incident, I had been unable to mount the partition back again. > >>> > >>> The appliance runs 2.6.32 as provided by Debian during the last two > >>> months. > >>> The rescue computer runs 2.6.37; both exhibited the same behaviour at > >>> mount: an infinite loop-and-abort cycle (I unfortunately did not write > >>> down the exact messages, but in a nutshell, there was not enough free > >>> space to replay the log, so it aborted). > >>> > >>> After pulling the SD card (yes) to break the loop, I ended up with a > >>> corrupt file system. Any attempt to mount, debug or fsck (using > >>> btrfs-tools 0.19+20100601 as shipped by Debian, or compiled from git > >>> 1b444cd2e6ab8dcafdd) aborted with the following message: > >>> btrfs-debug-tree: disk-io.c:741: open_ctree_fd: Assertion `!(! > >>> tree_root->node)' failed. > >>> > >>> After much scavenging on the disk image, I finally managed to recover, > >>> using the (dirty) patch attached here. Since apparently other people had > >>> similar issues, I'm posting it in the hope it might be useful. > >>> > >>> -- Cyrille > >>> > >>> PS: Chris, if btrfs-images of "before" and "after" my butcher fix would > >>> be useful to you, just let me know. > >>> <scavenge.patch> > >> > > > > <scavenge-2.patch> > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
