tree root
Hi!
I have a broken btrfs unable to mount because it is unable to find the tree root. Using find-root I find the following:
Well block 14102764707840 seems great, but generation doesn't match, have=109268, want=109269
Because the filesystem was last in use with a pre 3.2-kernel I am unable to use mount -o recovery, but restore seems to work when I specify the previous tree-root. My problem is however that the btrfs is so large I have nowhere to temporarily put all the files. I am currently running kernel 3.5. Does mount have an option to manually tell it to use the tree root at block 14102764707840?
Signature · 2 lines
Best regards Øystein Middelthun
Quoted 8 lines · Øystein Sættem Middelthun
Hi!
I have a broken btrfs unable to mount because it is unable to find the tree root. Using find-root I find the following:
Well block 14102764707840 seems great, but generation doesn't match, have=109268, want=109269
Quoted 7 lines
Because the filesystem was last in use with a pre 3.2-kernel I am unable to use mount -o recovery, but restore seems to work when I specify the previous tree-root. My problem is however that the btrfs is so large I have nowhere to temporarily put all the files. I am currently running kernel 3.5. Does mount have an option to manually tell it to use the tree root at block 14102764707840?
If you do not have a suitable backup for these files, please make an effort to do what you can with restore. Some of the repair methods out there have a possibility to make the situation worse.
Quoted 3 lines · Mitch Harder
If you do not have a suitable backup for these files, please make an effort to do what you can with restore. Some of the repair methods out there have a possibility to make the situation worse.
We are talking about something like 50TB, so there is just no way I have the available space on other disks for temporary storage.
So in effect you are saying that there are no other available options than a restore? If I understand correctly a feature along the lines of "mount -o tree_root=14102764707840 /dev/ /path/" would solve my problem.
The fs is unmountable because of a temporary loss of connection with an underlying disk controller, and I don't think the device has a lot of errors besides not being able to find the latest tree root.
Signature · 2 lines
Best regards Øystein Middelthun
Quoted 10 lines · Øystein Sættem Middelthun
Quoted 4 lines · Mitch Harder
If you do not have a suitable backup for these files, please make an effort to do what you can with restore. Some of the repair methods out there have a possibility to make the situation worse.
We are talking about something like 50TB, so there is just no way I have the available space on other disks for temporary storage.
Quoted 8 lines
So in effect you are saying that there are no other available options than a restore? If I understand correctly a feature along the lines of "mount -o tree_root=14102764707840
/dev//path/" would solve my problem.The fs is unmountable because of a temporary loss of connection with an underlying disk controller, and I don't think the device has a lot of errors besides not being able to find the latest tree root.
You should probably try to supply some more information about your situation.
Was this btrfs volume build with RAID-1?
If so, we should be able to mount in degraded mode.
Even so, when I see the words "unable to find the tree root" and "temporary loss of connection with an underlying disk controller" along with the implication that you have no reliable backup of this data, I worry that your situation is potentially precarious.
The possibility exists that recovering your data is your best option (as opposed to restoring to previous working condition).
Using backup tree-roots and super-blocks has the potential to do irreversible damage.
Quoted 9 lines · Øystein Sættem Middelthun
Well block 14102764707840 seems great, but generation doesn't match, have=109268, want=109269
Because the filesystem was last in use with a pre 3.2-kernel I am unable to use mount -o recovery, but restore seems to work when I specify the previous tree-root. My problem is however that the btrfs is so large I have nowhere to temporarily put all the files. I am currently running kernel 3.5. Does mount have an option to manually tell it to use the tree root at block 14102764707840?
It's not possible to supply the tree_root via mount option, but it should be possible to modify the superblock to point the tree_root to the one you've found, in a similar way that the -o recovery does that, but this hasn't been done before and "minor" details may make it complicated (like getting the transaction number in sync, as the tree_root has latest-1).
david