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? 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> -- 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
