On 10/06/2011 04:56 PM, Francesco Riosa wrote: > 2011/10/6 Andi Kleen <a...@firstfloor.org>: >> Jeff Putney <jeffrey.put...@gmail.com> writes: >>> >>> http://en.wikipedia.org/wiki/Release_early,_release_often >> >> Well the other principle in free software you're forgetting >> is: >> >> "It will be released when it's ready" >> >> If you don't like Chris' ways to do releases you're free to write >> something on your own or pay someone to do so. Otherwise >> you just have to deal with his time frames, as shifty >> as they may be. > > I did a different thing, I've offered Chris money to help rescue an > hosed btrfs or to point to someone who could do, we ended in doing > some tests (for free) but nothing else materialized. > While the time passed has diminished the value of the data to be > rescued I'm more on the "show us some code we can start from" than "it > will be released when ready" vagon. >
If you still need that data, clone this repo git://github.com/josefbacik/btrfs-progs.git run make, and then run ./restore /dev/whatever /some/dir and it will try and suck all of your data off the disk and dump it in that directory. If you have snapshots it will skip them by default, so if you have snapshots that have useful data in them you'll want to use the -s option. If you run into random errors that you think are recoverable, or if you don't care about the file that's being recovered, you can run with -i which will ignore errors and keep trying to recover your files. Thanks, Josef -- 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
