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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
