On 22.11.2011 04:19, Erik Jensen wrote:> I have a corrupted multi-device file system that got corrupted ages
> ago (as I recall, one of the drives stopped responding, causing btrfs
> to panic). I am hoping to recover some of the data. For what it''s
> worth, here is the dmesg output from trying to mount the file system
> on a 3.0 kernel:
>
> device label Media devid 6 transid 816153 /dev/sdq
> device label Media devid 7 transid 816153 /dev/sdl
> device label Media devid 11 transid 816153 /dev/sdj
> device label Media devid 9 transid 816153 /dev/sdk
> device label Media devid 10 transid 816153 /dev/sdi
> device label Media devid 3 transid 816152 /dev/sdh
> device label Media devid 4 transid 816152 /dev/sdf
> device label Media devid 1 transid 816152 /dev/sdg
> device label Media devid 2 transid 816152 /dev/sde
> device label Media devid 8 transid 816153 /dev/sdb
> parent transid verify failed on 47051597279232 wanted 816153 found 816151
> parent transid verify failed on 47051597279232 wanted 816153 found 816151
> parent transid verify failed on 47051597279232 wanted 816153 found 816151
>
> Most of the data is unimportant at this point, and I don''t have
enough
> extra space elsewhere to store it all anyway. Is there any way I could
> get a read-only view of the file system to pull off the bits I need?
There are some patches in preparation that should help you
recover from this situation. The solution is to mount with
a superblock of generation 816152, but the current set of
tools won''t allow for that.
>
> Any help would be greatly appreciated.
>
> Thanks.
>
> -- Erik Jensen
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html