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? -- Best regards Øystein Middelthun -- 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
On Wed, Oct 3, 2012 at 11:35 AM, Øystein Sættem Middelthun <oystein@middelthun.no> wrote:> 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? >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. -- 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
On 10/03/2012 07:29 PM, Mitch Harder wrote:> 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. -- Best regards Øystein Middelthun -- 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
On Wed, Oct 3, 2012 at 5:11 PM, Øystein Sættem Middelthun <oystein@middelthun.no> wrote:> On 10/03/2012 07:29 PM, Mitch Harder wrote: >> >> 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. >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. -- 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
On Wed, Oct 03, 2012 at 06:35:00PM +0200, Øystein Sættem Middelthun wrote:> 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 -- 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