Btrfs devel - Dec 2011 - FS won't mount, open_ctree failed, Assertion !(path->slots[0] == 0) failed

So I''m having a bit of trouble with one of my btrfs filesystems.  It
isn''t mounting after a power failure.  I can''t get restore or
btrfsck to run, even on backup supers.  I''ve pasted some output below. 
My btrfs-progs below come from git this morning, running on linux 3.2.0.

# mount /dev/md2 /media/test/
mount: wrong fs type, bad option, bad superblock on /dev/md2,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

dmesg:
[26423.775471] device label LUMBERYARD devid 1 transid 1268960 /dev/md2
[26423.860966] parent transid verify failed on 25487586828288 wanted 1268960
found 1246404
[26423.860974] parent transid verify failed on 25487586828288 wanted 1268960
found 1246404
[26423.860979] parent transid verify failed on 25487586828288 wanted 1268960
found 1246404
[26423.872936] btrfs: open_ctree failed

# ./btrfsck /dev/md2
parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
Ignoring transid failure
btrfsck: root-tree.c:46: btrfs_find_last_root: Assertion `!(path->slots[0] ==
0)'' failed.
Aborted
# ./btrfsck -s 1 /dev/md2
using SB copy 1, bytenr 67108864
parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
Ignoring transid failure
btrfsck: root-tree.c:46: btrfs_find_last_root: Assertion `!(path->slots[0] ==
0)'' failed.
Aborted
# ./btrfsck -s 2 /dev/md2
using SB copy 2, bytenr 274877906944
parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
Ignoring transid failure
btrfsck: root-tree.c:46: btrfs_find_last_root: Assertion `!(path->slots[0] ==
0)'' failed.
Aborted

# ./find-root /dev/md2
http://pastebin.com/3umfQHhh

# ./restore -i -f 25483145760768 /dev/md2 /tmp
parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
Ignoring transid failure
restore: root-tree.c:46: btrfs_find_last_root: Assertion `!(path->slots[0] ==
0)'' failed.
Aborted
# ./restore -i -u 1 /dev/md2 /tmp
parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
Ignoring transid failure
restore: root-tree.c:46: btrfs_find_last_root: Assertion `!(path->slots[0] ==
0)'' failed.
Aborted
# ./restore -i -u 1 -f 25483145760768 /dev/md2 /tmp
parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
Ignoring transid failure
restore: root-tree.c:46: btrfs_find_last_root: Assertion `!(path->slots[0] ==
0)'' failed.
Aborted

All further restores with various combinations of superblocks and
bytenr''s I tried produced output identical to one of the restores
above.

As the newest data on this filesystem had not been backed up, it would be nice
if I could either return the filesystem to a mountable state, or recover
specific files to another filesystem.  Any ideas?

-- David Smith


--
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

<dsmith <at> tgen.org> writes:
> 
> So I''m having a bit of trouble with one of my btrfs filesystems. 
It isn''t
mounting after a power failure.  I
> can''t get restore or btrfsck to run, even on backup supers. 
I''ve pasted some
output below.  My btrfs-progs
> below come from git this morning, running on linux 3.2.0.
> 
> # mount /dev/md2 /media/test/
> mount: wrong fs type, bad option, bad superblock on /dev/md2,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
> 
> dmesg:
> [26423.775471] device label LUMBERYARD devid 1 transid 1268960 /dev/md2
> [26423.860966] parent transid verify failed on 25487586828288 wanted
1268960
found 1246404
> [26423.860974] parent transid verify failed on 25487586828288 wanted
1268960
found 1246404
> [26423.860979] parent transid verify failed on 25487586828288 wanted
1268960
found 1246404
> [26423.872936] btrfs: open_ctree failed
> 
> # ./btrfsck /dev/md2
> parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
> parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
> parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
> parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
> Ignoring transid failure
> btrfsck: root-tree.c:46: btrfs_find_last_root: Assertion
`!(path->slots[0] =0)'' failed.
> Aborted
> # ./btrfsck -s 1 /dev/md2
> using SB copy 1, bytenr 67108864
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
> Ignoring transid failure
> btrfsck: root-tree.c:46: btrfs_find_last_root: Assertion
`!(path->slots[0] =0)'' failed.
> Aborted
> # ./btrfsck -s 2 /dev/md2
> using SB copy 2, bytenr 274877906944
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
> Ignoring transid failure
> btrfsck: root-tree.c:46: btrfs_find_last_root: Assertion
`!(path->slots[0] =0)'' failed.
> Aborted
> 
> # ./find-root /dev/md2
> http://pastebin.com/3umfQHhh
> 
> # ./restore -i -f 25483145760768 /dev/md2 /tmp
> parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
> parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
> parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
> parent transid verify failed on 25487586828288 wanted 1268960 found 1246404
> Ignoring transid failure
> restore: root-tree.c:46: btrfs_find_last_root: Assertion
`!(path->slots[0] =0)'' failed.
> Aborted
> # ./restore -i -u 1 /dev/md2 /tmp
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
> Ignoring transid failure
> restore: root-tree.c:46: btrfs_find_last_root: Assertion
`!(path->slots[0] =0)'' failed.
> Aborted
> # ./restore -i -u 1 -f 25483145760768 /dev/md2 /tmp
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268949
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
> parent transid verify failed on 25483242758144 wanted 1268944 found 1268957
> Ignoring transid failure
> restore: root-tree.c:46: btrfs_find_last_root: Assertion
`!(path->slots[0] =0)'' failed.
> Aborted
> 
> All further restores with various combinations of superblocks and
bytenr''s I
tried produced output
> identical to one of the restores above.
> 
> As the newest data on this filesystem had not been backed up, it would be
nice
if I could either return the
> filesystem to a mountable state, or recover specific files to another
filesystem.  Any ideas?
> 
I''m having the very same issue as you. I''ve tried all the
latest btrfs tools,
btrfsck, btrfs-zero-log, restore, find-root etc etc.

All to no avail. only err output is always 

"" btrfs_find_last_root: Assertion `!(path->slots[0] ==
0)'' failed. ""

This is a very cryptic error that doesn''t tell me anything. and it
seems to be
the only error that is ever thrown when transaction id''s get out of
sync.

Is there ANY way to even recover ANY files at all from these btrfs filesystems
that lose transid sync? mine occurred simply from a loose sata cable falling out
of one of my drives while the system was running.

This is extremely frustrating, but I guess I have no one to blame but myself. I
do have a backup but its about a month old (my cron backup script died for some
reason and I didn''t notice). So I''m faced with losing a months
worth of work :(

Please help us, anyone!



--
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 Fri, Dec 23, 2011 at 09:37:28AM +0000, Evan LeCompte
wrote:
> I''m having the very same issue as you. I''ve tried all the
latest btrfs tools,
> btrfsck, btrfs-zero-log, restore, find-root etc etc.
> 
> All to no avail. only err output is always 
> 
> "" btrfs_find_last_root: Assertion `!(path->slots[0] ==
0)'' failed. ""
> 
> This is a very cryptic error that doesn''t tell me anything. and it
seems to be
> the only error that is ever thrown when transaction id''s get out
of sync.
> 
> Is there ANY way to even recover ANY files at all from these btrfs
filesystems
> that lose transid sync? mine occurred simply from a loose sata cable
falling out
> of one of my drives while the system was running.
> 
> This is extremely frustrating, but I guess I have no one to blame but
myself. I
> do have a backup but its about a month old (my cron backup script died for
some
> reason and I didn''t notice). So I''m faced with losing a
months worth of work :(
> 
> Please help us, anyone!
Which kernel are you running?  If you''re on a 3.2 kernel or you have a
recent pull of my git tree, you can try mount -o recovery.

My guess is that your machine went down pretty quickly after the loose
sata cable fell out?  In that case mount -o recovery should work.

Otherwise we can work through the copy out recovery tools.

-chris

--
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 12/23/2011 06:15 PM, Chris Mason wrote:
> On Fri, Dec 23, 2011 at 09:37:28AM +0000, Evan LeCompte wrote:
>> I''m having the very same issue as you. I''ve tried all
the latest btrfs tools,
>> btrfsck, btrfs-zero-log, restore, find-root etc etc.
>>
>> All to no avail. only err output is always
>>
>> "" btrfs_find_last_root: Assertion `!(path->slots[0] ==
0)'' failed. ""
>>
>> This is a very cryptic error that doesn''t tell me anything.
and it seems to be
>> the only error that is ever thrown when transaction id''s get
out of sync.
>>
>> Is there ANY way to even recover ANY files at all from these btrfs
filesystems
>> that lose transid sync? mine occurred simply from a loose sata cable
falling out
>> of one of my drives while the system was running.
>>
>> This is extremely frustrating, but I guess I have no one to blame but
myself. I
>> do have a backup but its about a month old (my cron backup script died
for some
>> reason and I didn''t notice). So I''m faced with losing
a months worth of work :(
>>
>> Please help us, anyone!
>
> Which kernel are you running?  If you''re on a 3.2 kernel or you
have a
> recent pull of my git tree, you can try mount -o recovery.
>
> My guess is that your machine went down pretty quickly after the loose
> sata cable fell out?  In that case mount -o recovery should work.
>
> Otherwise we can work through the copy out recovery tools.
>
> -chris
>
> --
> 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
>
I''m running on a ubuntu 11.10 livecd with kernel 3.0.0
Downloaded your latest git tree but

mount -o recovery failed

Is there anythng else I can do? I suppose I could try and build a livecd 
with kernel 3.2 on it but thats pretty damn new so I''d have
to engineer one from scratch or have another linux installation somewhere...

-- 
--
Evan LeCompte

--
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 12/23/2011 06:15 PM, Chris Mason wrote:
> On Fri, Dec 23, 2011 at 09:37:28AM +0000, Evan LeCompte wrote:
>> I''m having the very same issue as you. I''ve tried all
the latest btrfs tools,
>> btrfsck, btrfs-zero-log, restore, find-root etc etc.
>>
>> All to no avail. only err output is always
>>
>> "" btrfs_find_last_root: Assertion `!(path->slots[0] ==
0)'' failed. ""
>>
>> This is a very cryptic error that doesn''t tell me anything.
and it seems to be
>> the only error that is ever thrown when transaction id''s get
out of sync.
>>
>> Is there ANY way to even recover ANY files at all from these btrfs
filesystems
>> that lose transid sync? mine occurred simply from a loose sata cable
falling out
>> of one of my drives while the system was running.
>>
>> This is extremely frustrating, but I guess I have no one to blame but
myself. I
>> do have a backup but its about a month old (my cron backup script died
for some
>> reason and I didn''t notice). So I''m faced with losing
a months worth of work :(
>>
>> Please help us, anyone!
>
> Which kernel are you running?  If you''re on a 3.2 kernel or you
have a
> recent pull of my git tree, you can try mount -o recovery.
>
> My guess is that your machine went down pretty quickly after the loose
> sata cable fell out?  In that case mount -o recovery should work.
>
> Otherwise we can work through the copy out recovery tools.
>
> -chris
>
> --
> 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
>
I''m running on a ubuntu 11.10 livecd (kernel 3.0.0) but I did clone
your
git repo and make && make install it.

however

mount -t btrfs -o recovery /dev/sda4 /mnt  failed
same error , bad superblock

also, this was a btrfs raid0 setup so it could be mounted via
/dev/sda4 or /dev/sdb, however after that sata cable came loose
I cannot mount either.

Is there anything else we can do? I''ve screwed myself twice now using 
btrfs raid0 so I think its time to call it quits and use something else
for a while. but I''d really like to at least get my old data off this
because my last backup is a month behind :(

-- 
--
Evan LeCompte

--
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 12/23/2011 06:15 PM, Chris Mason wrote:
> On Fri, Dec 23, 2011 at 09:37:28AM +0000, Evan LeCompte wrote:
>> I''m having the very same issue as you. I''ve tried all
the latest btrfs tools,
>> btrfsck, btrfs-zero-log, restore, find-root etc etc.
>>
>> All to no avail. only err output is always
>>
>> "" btrfs_find_last_root: Assertion `!(path->slots[0] ==
0)'' failed. ""
>>
>> This is a very cryptic error that doesn''t tell me anything.
and it seems to be
>> the only error that is ever thrown when transaction id''s get
out of sync.
>>
>> Is there ANY way to even recover ANY files at all from these btrfs
filesystems
>> that lose transid sync? mine occurred simply from a loose sata cable
falling out
>> of one of my drives while the system was running.
>>
>> This is extremely frustrating, but I guess I have no one to blame but
myself. I
>> do have a backup but its about a month old (my cron backup script died
for some
>> reason and I didn''t notice). So I''m faced with losing
a months worth of work :(
>>
>> Please help us, anyone!
>
> Which kernel are you running?  If you''re on a 3.2 kernel or you
have a
> recent pull of my git tree, you can try mount -o recovery.
>
> My guess is that your machine went down pretty quickly after the loose
> sata cable fell out?  In that case mount -o recovery should work.
>
> Otherwise we can work through the copy out recovery tools.
>
> -chris
>
> --
> 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
>
Chris,
Can you help me work through the copy out recovery tools that you mentioned?

I can''t seem to get anything else to work, if I could just recover the 
files so I don''t lose a month''s work I''d be so
happy...

Thank you.

--
Evan LeCompte
--
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

Am Montag, 26. Dezember 2011 schrieb Evan LeCompte:
> On 12/23/2011 06:15 PM, Chris Mason wrote:
> > On Fri, Dec 23, 2011 at 09:37:28AM +0000, Evan LeCompte wrote:
> >> I''m having the very same issue as you. I''ve
tried all the latest
> >> btrfs tools, btrfsck, btrfs-zero-log, restore, find-root etc etc.
> >> 
> >> All to no avail. only err output is always
> >> 
> >> "" btrfs_find_last_root: Assertion `!(path->slots[0]
== 0)'' failed.
> >> ""
> >> 
> >> This is a very cryptic error that doesn''t tell me
anything. and it
> >> seems to be the only error that is ever thrown when transaction
> >> id''s get out of sync.
> >> 
> >> Is there ANY way to even recover ANY files at all from these btrfs
> >> filesystems that lose transid sync? mine occurred simply from a
> >> loose sata cable falling out of one of my drives while the system
> >> was running.
> >> 
> >> This is extremely frustrating, but I guess I have no one to blame
> >> but myself. I do have a backup but its about a month old (my cron
> >> backup script died for some reason and I didn''t notice).
So I''m
> >> faced with losing a months worth of work :(
> >> 
> >> Please help us, anyone!
> > 
> > Which kernel are you running?  If you''re on a 3.2 kernel or
you have
> > a recent pull of my git tree, you can try mount -o recovery.
> > 
> > My guess is that your machine went down pretty quickly after the
> > loose sata cable fell out?  In that case mount -o recovery should
> > work.
> > 
> > Otherwise we can work through the copy out recovery tools.
[…]
> Chris,
> Can you help me work through the copy out recovery tools that you
> mentioned?
> 
> I can''t seem to get anything else to work, if I could just recover
the
> files so I don''t lose a month''s work I''d be so
happy...
For starters I think it would be good when you explain exactly, what tools 
you tried and what errors you have gotten (copy&paste the relevant parts!) 
by doing so. It also makes sense to do this with a recent copy of btrfs-
tools.

I am no expert in BTRFS recovery but I think its easier to work from 
there.

Aside from that, backup or not, I wouldn´t put important data on a RAID 0 
across several devices and when it usually just is for saving on backup 
restauration time in case one of the devices fails. Better have some 
redundant RAID *and* a backup. Or if "RAID 0" at least BTRFS on *one* 
device, instead of mutiple. Or otherwise said: I would use RAID-0 across 
mutiple disks just for scratch data that I can easily afford to loose.

-- 
Martin ''Helios'' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
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

Am Montag, 26. Dezember 2011 schrieb Evan LeCompte:
> On 12/23/2011 06:15 PM, Chris Mason wrote:
> > On Fri, Dec 23, 2011 at 09:37:28AM +0000, Evan LeCompte wrote:
> >> I''m having the very same issue as you. I''ve
tried all the latest
> >> btrfs tools, btrfsck, btrfs-zero-log, restore, find-root etc etc.
> >> 
> >> All to no avail. only err output is always
[…]
> >> Is there ANY way to even recover ANY files at all from these btrfs
> >> filesystems that lose transid sync? mine occurred simply from a
> >> loose sata cable falling out of one of my drives while the system
> >> was running.
[…]
> >> Please help us, anyone!
> > 
> > Which kernel are you running?  If you''re on a 3.2 kernel or
you have
> > a recent pull of my git tree, you can try mount -o recovery.
[…]
> Chris,
> Can you help me work through the copy out recovery tools that you
> mentioned?
If all else fails depending of the file formats of the files you want to 
recover you can also try some of the forensic tools like photorec from 
testdisk or foremost. I believe there is a third one. This should get you 
the files, although the filenames and directory structure will likely be 
lost. And it takes quite long on higher capacity or slow drives.

With photorec I managed to recover 100 images from a smartmedia card that 
appeared empty on Linux - while the digital camera still saw the images.

-- 
Martin ''Helios'' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
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