On Tue, Oct 11, 2011 at 11:21:45PM +0200, Francesco Riosa wrote: > 2011/10/7 Josef Bacik <jo...@redhat.com>: > > 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 > > > > I've tried, w/o luck > > explanation come from 2011-06-21 thread; > http://thread.gmane.org/gmane.comp.file-systems.btrfs/11435 > the following refer to a copy of that system > > Label: space02 uuid: f752def1-1abc-48c7-8ebb-47ba37b8ffa6 > Total devices 7 FS bytes used 173.12GB > devid 6 size 488.94GB used 60.25GB path /dev/sdd7 > devid 2 size 487.65GB used 58.76GB path /dev/sdd8 > devid 7 size 487.65GB used 0.00 path /dev/sdf7 > devid 3 size 487.65GB used 60.26GB path /dev/sdf8 > devid 7 size 487.65GB used 1.50GB path /dev/sdg7 > devid 5 size 488.94GB used 58.75GB path /dev/sdb7 > devid 4 size 487.65GB used 60.26GB path /dev/sdb8 > > # ./restore /dev/sdd7 /tmp/restore > failed to read /dev/sr0 > failed to read /dev/sr0 > restore: volumes.c:1367: btrfs_read_sys_array: Assertion `!(ret)' failed. > Aborted >
So this is kind of a problem since you have multiple disks. We maybe could get away with ignoring a failure, but the problem is if you have data on a disk where we couldn't read the chunk then the chances are we won't be able to map that file and read the data off. That being said, theres no harm in trying ;). Can you make btrfs_read_sys_array complain about failing, but not actually BUG? See if that helps you. 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
