Finally made some more progress on one of my melted down btrfs from
earlier this year.
First I hacked find-root.c to not stop scanning the disk when it
thinks it has found the real root. I wanted it to print out all
possible roots. I saved the stderr output to a logfile. About 1226
possible
I made a little bit of progress recovering this mess, seems
btrfs-progs has improved since I last tried.
# ./btrfs-find-root /dev/mapper/tr5ut-vicep--library
[..]
Well block 317865713664 seems great, but generation doesn't match, have=574372,
want=575931
Well block 317874491392 seems great, but
On Sun, Feb 12, 2012 at 10:31:34AM -0600, Ryan C. Underwood wrote:
So, I examined the below filesystem, the one of the two that I would
really like to restore. There is basically nothing but zeros, and
very occasionally a sparse string of data, until exactly 0x20
offset,
This matches
So, I examined the below filesystem, the one of the two that I would
really like to restore. There is basically nothing but zeros, and
very occasionally a sparse string of data, until exactly 0x20
offset, at which point the data is suddenly very packed and looks like
usual compressed data
Ryan C. Underwood posted on Mon, 06 Feb 2012 21:39:45 -0600 as excerpted:
Does anyone have any idea how I should proceed with the below quoted
situation? Unfortunately, I am going to have to give up on btrfs if it
is really so fragile. I am using kernel 3.2.2 and btrfs-tools from
November.
Unfortunately, I am going to have to give up on btrfs if it
is really so fragile.
However, complaining about the fragility of a still in development
and
marked experimental filesystem would seem disingenuous at best.
[snip paragraphs of tut-tutting]
IOW, yes, btrfs is to be
On Tue, Feb 7, 2012 at 8:04 AM, Ryan C. Underwood
nemesis-li...@icequake.net wrote:
Unfortunately, I am going to have to give up on btrfs if it
is really so fragile.
However, complaining about the fragility of a still in development
and
marked experimental filesystem would seem
On Tue, Feb 07, 2012 at 12:17:23PM +0800, Liu Bo wrote:
The failure occurred while the volumes were online and in use, so in
addition to what was unreadable, all pending writes to the device
between the failure and when the problem was discovered were lost as
well.
Hi Ryan,
So
On Tue, Feb 07, 2012 at 08:36:15AM -0600, Mitch Harder wrote:
Since you're getting failed to read /dev/sr0 messages, that might be
an indication there are some newer btrfs-progs tools available.
You might want to try the building btrfs-progs from the git repository:
Output of 'restore':
# /usr/local/btrfs-progs/bin/restore -v /dev/mapper/tr5ut-vicep--clones /mnt2
No valid Btrfs found on /dev/mapper/tr5ut-vicep--clones
Could not open root, trying backup super
Check tree block failed, want=298807296, have=13791616683601169802
Check tree block failed,
On Tuesday 07 February 2012 20:53:59 Duncan wrote:
Kernel 3.2.2 is relatively recent altho you could
try the latest 3.3 rc or git kernel as well
Please keep in mind that work done in git does not appear to get
backported to the stable updates for releases (such as 3.2.x), in
other words
Does anyone have any idea how I should proceed with the below quoted
situation? Unfortunately, I am going to have to give up on btrfs if
it is really so fragile. I am using kernel 3.2.2 and btrfs-tools
from November.
On Sun, Feb 05, 2012 at 12:41:28PM -0600, Ryan C. Underwood wrote:
Hi,
On 02/07/2012 11:39 AM, Ryan C. Underwood wrote:
Does anyone have any idea how I should proceed with the below quoted
situation? Unfortunately, I am going to have to give up on btrfs if
it is really so fragile. I am using kernel 3.2.2 and btrfs-tools
from November.
On Sun, Feb 05, 2012 at
13 matches
Mail list logo
