* Btrfs Storage Array Corrupted
@ 2012-02-29 0:13 Travis Shivers
2012-02-29 0:34 ` Fajar A. Nugraha
2012-02-29 1:41 ` Gurudas Pai
0 siblings, 2 replies; 15+ messages in thread
From: Travis Shivers @ 2012-02-29 0:13 UTC (permalink / raw)
To: linux-btrfs
Recently, I have been having major problems with my RAID 1 btrfs
array. I know that btrfsck is not yet released, which is the main
reason why I cannot repair my filesystem. Is there a way for me to get
my data off the broken filesystem? After a reboot, my btrfs filesystem
was unable to mount and gave this error:
# mount /dev/sdh
mount: wrong fs type, bad option, bad superblock on /dev/sdh,
=A0=A0=A0=A0=A0=A0 missing codepage or helper program, or other error
=A0=A0=A0=A0=A0=A0 In some cases useful info is found in syslog - try
=A0=A0=A0=A0=A0=A0 dmesg | tail=A0 or so
I did as it suggested and took a look at dmesg:
[74702.033750] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 devid
3 transid 43477 /dev/sdh
[74702.037263] btrfs: use lzo compression
[74702.037276] btrfs: enabling inode map caching
[74702.037280] btrfs: allowing degraded mounts
[74702.037287] btrfs: enabling auto recovery
[74702.037290] btrfs: disk space caching is enabled
[74702.083683] parent transid verify failed on 5568194695168 wanted
43477 found 43151
[74702.083697] parent transid verify failed on 5568194695168 wanted
43477 found 43151
[74702.083705] parent transid verify failed on 5568194695168 wanted
43477 found 43151
[74702.083712] parent transid verify failed on 5568194695168 wanted
43477 found 43151
[74702.086495] btrfs: open_ctree failed
It seems that there is a problem with the btrfs ctree. I tried several
things including upgrading my kernel, trying to use recovery and
degraded mount options, trying to mount it on another computer all
without success.
Here is some more information about the problem and some of the things
that I tried:
# btrfs-debug-tree /dev/sdh
couldn't open because of unsupported option features (8).
btrfs-debug-tree: disk-io.c:679: open_ctree_fd: Assertion `!(1)' failed
# ./btrfs-zero-log /dev/sdh
parent transid verify failed on 5568194695168 wanted 43477 found 43151
parent transid verify failed on 5568194695168 wanted 43477 found 43151
parent transid verify failed on 5568194695168 wanted 43477 found 43151
parent transid verify failed on 5568194695168 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568194748416 wanted 43477 found 43151
parent transid verify failed on 5568194748416 wanted 43477 found 43151
parent transid verify failed on 5568194748416 wanted 43477 found 43151
parent transid verify failed on 5568194748416 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568195178496 wanted 43477 found 43151
parent transid verify failed on 5568195178496 wanted 43477 found 43151
parent transid verify failed on 5568195178496 wanted 43477 found 43151
parent transid verify failed on 5568195178496 wanted 43477 found 43151
Ignoring transid failure
Here is some basic information about my system:
Linux server 3.2.8-030208-generic #201202271435 SMP Mon Feb 27
19:36:27 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
In the storage array, I have:
2 (2 TB) drives
2 (500 GB) drives
I have also made a post about this problem on the Ubuntu Forums:
http://ubuntuforums.org/showthread.php?p=3D11726449#post11726449
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
2012-02-29 0:13 Btrfs Storage Array Corrupted Travis Shivers
@ 2012-02-29 0:34 ` Fajar A. Nugraha
2012-02-29 1:41 ` Gurudas Pai
1 sibling, 0 replies; 15+ messages in thread
From: Fajar A. Nugraha @ 2012-02-29 0:34 UTC (permalink / raw)
To: Travis Shivers; +Cc: linux-btrfs
On Wed, Feb 29, 2012 at 7:13 AM, Travis Shivers <ttshivers@gmail.com> wrote:
> # ./btrfs-zero-log /dev/sdh
> parent transid verify failed on 5568194695168 wanted 43477 found 43151
> parent transid verify failed on 5568194695168 wanted 43477 found 43151
> parent transid verify failed on 5568194695168 wanted 43477 found 43151
> parent transid verify failed on 5568194695168 wanted 43477 found 43151
> Ignoring transid failure
Did you try a read-only mount (-o ro) after you run btrfs-zero-log?
--
Fajar
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
2012-02-29 0:13 Btrfs Storage Array Corrupted Travis Shivers
2012-02-29 0:34 ` Fajar A. Nugraha
@ 2012-02-29 1:41 ` Gurudas Pai
2012-02-29 2:50 ` Chris Mason
1 sibling, 1 reply; 15+ messages in thread
From: Gurudas Pai @ 2012-02-29 1:41 UTC (permalink / raw)
To: Travis Shivers; +Cc: linux-btrfs
># btrfs-debug-tree /dev/sdh
couldn't open because of unsupported option features (8).
btrfs-debug-tree: disk-io.c:679: open_ctree_fd: Assertion `!(1)' failed
See if following patch helps.
Author: Chris Mason<chris.mason@oracle.com>
Date: Wed Feb 22 12:36:24 2012 -0500
Btrfs: clear the extent uptodate bits during parent transid failures
If btrfs reads a block and finds a parent transid mismatch, it clears
the uptodate flags on the extent buffer, and the pages inside it. But
we only clear the uptodate bits in the state tree if the block straddles
more than one page.
This is from an old optimization from to reduce contention on the extent
state tree. But it is buggy because the code that retries a read from
a different copy of the block is going to find the uptodate state bits
set and skip the IO.
The end result of the bug is that we'll never actually read the good
copy (if there is one).
The fix here is to always clear the uptodate state bits, which is safe
because this code is only called when the parent transid fails.
Signed-off-by: Chris Mason<chris.mason@oracle.com>
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 1e8d5e5..a4dc892 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3852,10 +3852,9 @@ int clear_extent_buffer_uptodate(struct extent_io_tree *tree,
num_pages = num_extent_pages(eb->start, eb->len);
clear_bit(EXTENT_BUFFER_UPTODATE,&eb->bflags);
- if (eb_straddles_pages(eb)) {
- clear_extent_uptodate(tree, eb->start, eb->start + eb->len - 1,
- cached_state, GFP_NOFS);
- }
+ clear_extent_uptodate(tree, eb->start, eb->start + eb->len - 1,
+ cached_state, GFP_NOFS);
+
for (i = 0; i< num_pages; i++) {
page = extent_buffer_page(eb, i);
if (page)
--
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
2012-02-29 1:41 ` Gurudas Pai
@ 2012-02-29 2:50 ` Chris Mason
2012-02-29 3:00 ` Travis Shivers
0 siblings, 1 reply; 15+ messages in thread
From: Chris Mason @ 2012-02-29 2:50 UTC (permalink / raw)
To: Gurudas Pai; +Cc: Travis Shivers, linux-btrfs
On Tue, Feb 28, 2012 at 05:41:45PM -0800, Gurudas Pai wrote:
>
>
> ># btrfs-debug-tree /dev/sdh
> couldn't open because of unsupported option features (8).
> btrfs-debug-tree: disk-io.c:679: open_ctree_fd: Assertion `!(1)' failed
>
>
>
>
> See if following patch helps.
This patch may just fix things (if we're really lucky). If not, yes we
can help figure out where the problem is and get past it.
-chris
>
> Author: Chris Mason<chris.mason@oracle.com>
> Date: Wed Feb 22 12:36:24 2012 -0500
>
> Btrfs: clear the extent uptodate bits during parent transid failures
>
> If btrfs reads a block and finds a parent transid mismatch, it clears
> the uptodate flags on the extent buffer, and the pages inside it. But
> we only clear the uptodate bits in the state tree if the block straddles
> more than one page.
>
> This is from an old optimization from to reduce contention on the extent
> state tree. But it is buggy because the code that retries a read from
> a different copy of the block is going to find the uptodate state bits
> set and skip the IO.
>
> The end result of the bug is that we'll never actually read the good
> copy (if there is one).
>
> The fix here is to always clear the uptodate state bits, which is safe
> because this code is only called when the parent transid fails.
>
> Signed-off-by: Chris Mason<chris.mason@oracle.com>
>
> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> index 1e8d5e5..a4dc892 100644
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -3852,10 +3852,9 @@ int clear_extent_buffer_uptodate(struct extent_io_tree *tree,
> num_pages = num_extent_pages(eb->start, eb->len);
> clear_bit(EXTENT_BUFFER_UPTODATE,&eb->bflags);
>
> - if (eb_straddles_pages(eb)) {
> - clear_extent_uptodate(tree, eb->start, eb->start + eb->len - 1,
> - cached_state, GFP_NOFS);
> - }
> + clear_extent_uptodate(tree, eb->start, eb->start + eb->len - 1,
> + cached_state, GFP_NOFS);
> +
> for (i = 0; i< num_pages; i++) {
> page = extent_buffer_page(eb, i);
> if (page)
> --
>
> --
> 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
2012-02-29 2:50 ` Chris Mason
@ 2012-02-29 3:00 ` Travis Shivers
2012-02-29 3:16 ` cwillu
0 siblings, 1 reply; 15+ messages in thread
From: Travis Shivers @ 2012-02-29 3:00 UTC (permalink / raw)
To: Chris Mason, Gurudas Pai, Travis Shivers, linux-btrfs
Where should I grab the source from? The main repo that you have
listed on your main wiki page
(https://btrfs.wiki.kernel.org/articles/b/t/r/Btrfs_source_repositories=
=2Ehtml)
is down: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-prog=
s-unstable.git
Has this patch been pushed to a repository where I can grab it?
On Tue, Feb 28, 2012 at 8:50 PM, Chris Mason <chris.mason@oracle.com> w=
rote:
> On Tue, Feb 28, 2012 at 05:41:45PM -0800, Gurudas Pai wrote:
>>
>>
>> ># btrfs-debug-tree /dev/sdh
>> couldn't open because of unsupported option features (8).
>> btrfs-debug-tree: disk-io.c:679: open_ctree_fd: Assertion `!(1)' fai=
led
>>
>>
>>
>>
>> See if following patch helps.
>
> This patch may just fix things (if we're really lucky). =A0If not, ye=
s we
> can help figure out where the problem is and get past it.
>
> -chris
>
>>
>> Author: Chris Mason<chris.mason@oracle.com>
>> Date: =A0 Wed Feb 22 12:36:24 2012 -0500
>>
>> =A0 =A0 Btrfs: clear the extent uptodate bits during parent transid =
failures
>>
>> =A0 =A0 If btrfs reads a block and finds a parent transid mismatch, =
it clears
>> =A0 =A0 the uptodate flags on the extent buffer, and the pages insid=
e it. =A0But
>> =A0 =A0 we only clear the uptodate bits in the state tree if the blo=
ck straddles
>> =A0 =A0 more than one page.
>>
>> =A0 =A0 This is from an old optimization from to reduce contention o=
n the extent
>> =A0 =A0 state tree. =A0But it is buggy because the code that retries=
a read from
>> =A0 =A0 a different copy of the block is going to find the uptodate =
state bits
>> =A0 =A0 set and skip the IO.
>>
>> =A0 =A0 The end result of the bug is that we'll never actually read =
the good
>> =A0 =A0 copy (if there is one).
>>
>> =A0 =A0 The fix here is to always clear the uptodate state bits, whi=
ch is safe
>> =A0 =A0 because this code is only called when the parent transid fai=
ls.
>>
>> =A0 =A0 Signed-off-by: Chris Mason<chris.mason@oracle.com>
>>
>> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
>> index 1e8d5e5..a4dc892 100644
>> --- a/fs/btrfs/extent_io.c
>> +++ b/fs/btrfs/extent_io.c
>> @@ -3852,10 +3852,9 @@ int clear_extent_buffer_uptodate(struct exten=
t_io_tree *tree,
>> =A0 =A0 =A0 num_pages =3D num_extent_pages(eb->start, eb->len);
>> =A0 =A0 =A0 clear_bit(EXTENT_BUFFER_UPTODATE,&eb->bflags);
>>
>> - =A0 =A0 if (eb_straddles_pages(eb)) {
>> - =A0 =A0 =A0 =A0 =A0 =A0 clear_extent_uptodate(tree, eb->start, eb-=
>start + eb->len - 1,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
cached_state, GFP_NOFS);
>> - =A0 =A0 }
>> + =A0 =A0 clear_extent_uptodate(tree, eb->start, eb->start + eb->len=
- 1,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cached_state, =
GFP_NOFS);
>> +
>> =A0 =A0 =A0 for (i =3D 0; i< =A0num_pages; i++) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 page =3D extent_buffer_page(eb, i);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (page)
>> --
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrf=
s" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at =A0http://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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
2012-02-29 3:00 ` Travis Shivers
@ 2012-02-29 3:16 ` cwillu
2012-02-29 3:36 ` Travis Shivers
0 siblings, 1 reply; 15+ messages in thread
From: cwillu @ 2012-02-29 3:16 UTC (permalink / raw)
To: Travis Shivers; +Cc: Chris Mason, Gurudas Pai, linux-btrfs
On Tue, Feb 28, 2012 at 9:00 PM, Travis Shivers <ttshivers@gmail.com> wrote:
> Where should I grab the source from? The main repo that you have
> listed on your main wiki page
> (https://btrfs.wiki.kernel.org/articles/b/t/r/Btrfs_source_repositories.html)
> is down: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git
The btrfs wiki is at http://btrfs.ipv5.de . The kernel.org one is a
static snapshot of the contents made nearly a year ago, prior to the
kernel.org break-in, and should be ignored.
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git is
the development tree, although the above patch is in mainline as of
3.3rc5, which probably makes that the easiest way to try it.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
2012-02-29 3:16 ` cwillu
@ 2012-02-29 3:36 ` Travis Shivers
2012-02-29 13:59 ` Chris Mason
0 siblings, 1 reply; 15+ messages in thread
From: Travis Shivers @ 2012-02-29 3:36 UTC (permalink / raw)
To: cwillu; +Cc: Chris Mason, Gurudas Pai, linux-btrfs
I upgraded my kernel so my version is now:
Linux server 3.3.0-030300rc5-generic #201202251535 SMP Sat Feb 25
20:36:29 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
The problem has not been solved and I still get the previous errors.
# mount /dev/sdh /mnt/main
mount: wrong fs type, bad option, bad superblock on /dev/sdh,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
# dmesg
[ 232.985248] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 devid
4 transid 43477 /dev/sdi
[ 232.985434] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 devid
3 transid 43477 /dev/sdh
[ 233.027881] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 devid
2 transid 43477 /dev/sdg
[ 233.065675] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 devid
1 transid 43476 /dev/sdf
[ 284.384320] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 devid
3 transid 43477 /dev/sdh
[ 284.427076] btrfs: disk space caching is enabled
[ 284.442565] verify_parent_transid: 2 callbacks suppressed
[ 284.442572] parent transid verify failed on 5568194695168 wanted
43477 found 43151
[ 284.442834] parent transid verify failed on 5568194695168 wanted
43477 found 43151
[ 284.443151] parent transid verify failed on 5568194695168 wanted
43477 found 43151
[ 284.443159] parent transid verify failed on 5568194695168 wanted
43477 found 43151
[ 284.445740] btrfs: open_ctree failed
On Tue, Feb 28, 2012 at 9:16 PM, cwillu <cwillu@cwillu.com> wrote:
> On Tue, Feb 28, 2012 at 9:00 PM, Travis Shivers <ttshivers@gmail.com>=
wrote:
>> Where should I grab the source from? The main repo that you have
>> listed on your main wiki page
>> (https://btrfs.wiki.kernel.org/articles/b/t/r/Btrfs_source_repositor=
ies.html)
>> is down: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-p=
rogs-unstable.git
>
> The btrfs wiki is at http://btrfs.ipv5.de . =A0The kernel.org one is =
a
> static snapshot of the contents made nearly a year ago, prior to the
> kernel.org break-in, and should be ignored.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git i=
s
> the development tree, although the above patch is in mainline as of
> 3.3rc5, which probably makes that the easiest way to try it.
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
2012-02-29 3:36 ` Travis Shivers
@ 2012-02-29 13:59 ` Chris Mason
2012-02-29 21:57 ` Travis Shivers
0 siblings, 1 reply; 15+ messages in thread
From: Chris Mason @ 2012-02-29 13:59 UTC (permalink / raw)
To: Travis Shivers; +Cc: cwillu, Gurudas Pai, linux-btrfs
On Tue, Feb 28, 2012 at 09:36:35PM -0600, Travis Shivers wrote:
> I upgraded my kernel so my version is now:
> Linux server 3.3.0-030300rc5-generic #201202251535 SMP Sat Feb 25
> 20:36:29 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>=20
> The problem has not been solved and I still get the previous errors.
Ok,
Step one is to grab the development version of btrfs-progs, which
currently sits in the dangerdonteveruse branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git dan=
gerdonteveruse
Run btrfs-debug-tree -R /dev/sdh
and then run btrfs-debug-tree -b 5568194695168 /dev/sdh
and then run btrfsck /dev/sdh
Send the results of all three here, it should tell us which tree that
block belongs to, and from there we'll figure out the best way to fix
it.
-chris
>=20
> # mount /dev/sdh /mnt/main
> mount: wrong fs type, bad option, bad superblock on /dev/sdh,
> missing codepage or helper program, or other error
> In some cases useful info is found in syslog - try
> dmesg | tail or so
>=20
> # dmesg
> [ 232.985248] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 devid
> 4 transid 43477 /dev/sdi
> [ 232.985434] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 devid
> 3 transid 43477 /dev/sdh
> [ 233.027881] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 devid
> 2 transid 43477 /dev/sdg
> [ 233.065675] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 devid
> 1 transid 43476 /dev/sdf
> [ 284.384320] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 devid
> 3 transid 43477 /dev/sdh
> [ 284.427076] btrfs: disk space caching is enabled
> [ 284.442565] verify_parent_transid: 2 callbacks suppressed
> [ 284.442572] parent transid verify failed on 5568194695168 wanted
> 43477 found 43151
> [ 284.442834] parent transid verify failed on 5568194695168 wanted
> 43477 found 43151
> [ 284.443151] parent transid verify failed on 5568194695168 wanted
> 43477 found 43151
> [ 284.443159] parent transid verify failed on 5568194695168 wanted
> 43477 found 43151
> [ 284.445740] btrfs: open_ctree failed
>=20
>=20
> On Tue, Feb 28, 2012 at 9:16 PM, cwillu <cwillu@cwillu.com> wrote:
> > On Tue, Feb 28, 2012 at 9:00 PM, Travis Shivers <ttshivers@gmail.co=
m> wrote:
> >> Where should I grab the source from? The main repo that you have
> >> listed on your main wiki page
> >> (https://btrfs.wiki.kernel.org/articles/b/t/r/Btrfs_source_reposit=
ories.html)
> >> is down: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs=
-progs-unstable.git
> >
> > The btrfs wiki is at http://btrfs.ipv5.de . =A0The kernel.org one i=
s a
> > static snapshot of the contents made nearly a year ago, prior to th=
e
> > kernel.org break-in, and should be ignored.
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git=
is
> > the development tree, although the above patch is in mainline as of
> > 3.3rc5, which probably makes that the easiest way to try it.
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
2012-02-29 13:59 ` Chris Mason
@ 2012-02-29 21:57 ` Travis Shivers
2012-02-29 22:14 ` Chris Mason
0 siblings, 1 reply; 15+ messages in thread
From: Travis Shivers @ 2012-02-29 21:57 UTC (permalink / raw)
To: Chris Mason, Travis Shivers, cwillu, Gurudas Pai, linux-btrfs
Here is the output from the commands:
# ./btrfs-debug-tree -R /dev/sdh
failed to read /dev/sr0: No medium found
failed to read /dev/sde: No medium found
failed to read /dev/sdd: No medium found
failed to read /dev/sdc: No medium found
failed to read /dev/sdb: No medium found
failed to read /dev/sda: No medium found
parent transid verify failed on 5568194695168 wanted 43477 found 43151
parent transid verify failed on 5568194695168 wanted 43477 found 43151
parent transid verify failed on 5568194695168 wanted 43477 found 43151
parent transid verify failed on 5568194695168 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568194748416 wanted 43477 found 43151
parent transid verify failed on 5568194748416 wanted 43477 found 43151
parent transid verify failed on 5568194748416 wanted 43477 found 43151
parent transid verify failed on 5568194748416 wanted 43477 found 43151
Ignoring transid failure
root tree: 5568194412544 level 1
chunk tree: 20979712 level 1
extent tree key (EXTENT_TREE ROOT_ITEM 0) 5568194416640 level 3
device tree key (DEV_TREE ROOT_ITEM 0) 4895076519936 level 1
fs tree key (FS_TREE ROOT_ITEM 0) 4895092506624 level 2
checksum tree key (CSUM_TREE ROOT_ITEM 0) 5568194695168 level 0
parent transid verify failed on 5568194801664 wanted 43477 found 43151
parent transid verify failed on 5568194801664 wanted 43477 found 43151
parent transid verify failed on 5568194801664 wanted 43477 found 43151
parent transid verify failed on 5568194801664 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568194674688 wanted 43477 found 43151
parent transid verify failed on 5568194674688 wanted 43477 found 43151
parent transid verify failed on 5568194674688 wanted 43477 found 43151
parent transid verify failed on 5568194674688 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568194678784 wanted 43477 found 43151
parent transid verify failed on 5568194678784 wanted 43477 found 43151
parent transid verify failed on 5568194678784 wanted 43477 found 43151
parent transid verify failed on 5568194678784 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568194809856 wanted 43477 found 43151
parent transid verify failed on 5568194809856 wanted 43477 found 43151
parent transid verify failed on 5568194809856 wanted 43477 found 43151
parent transid verify failed on 5568194809856 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568194875392 wanted 43477 found 42983
parent transid verify failed on 5568194875392 wanted 43477 found 42983
parent transid verify failed on 5568194875392 wanted 43477 found 42983
parent transid verify failed on 5568194875392 wanted 43477 found 42983
Ignoring transid failure
parent transid verify failed on 5568195104768 wanted 43477 found 43151
parent transid verify failed on 5568195104768 wanted 43477 found 43151
parent transid verify failed on 5568195104768 wanted 43477 found 43151
parent transid verify failed on 5568195104768 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568195043328 wanted 43477 found 43151
parent transid verify failed on 5568195162112 wanted 43477 found 43175
parent transid verify failed on 5568195162112 wanted 43477 found 43175
parent transid verify failed on 5568195162112 wanted 43477 found 43175
parent transid verify failed on 5568195162112 wanted 43477 found 43175
Ignoring transid failure
parent transid verify failed on 5568195166208 wanted 43477 found 43175
parent transid verify failed on 5568195166208 wanted 43477 found 43175
parent transid verify failed on 5568195166208 wanted 43477 found 43175
parent transid verify failed on 5568195166208 wanted 43477 found 43175
Ignoring transid failure
btrfs root backup slot 0
tree root gen 9799893461141291008 block 0
extent root gen 67174399 block 9799996369115086847
chunk root gen 18446605274118684671 block 9799972705260=
863487
device root gen 9799997658994114559 block 1844663853462=
8474880
csum root gen 94490787839 block 18446638559949619199
fs root gen 262144 block 1048576
9799994850661629952 used 0 total 9799997659432419327 de=
vices
btrfs root backup slot 1
tree root gen 16777216 block 38655295488
extent root gen 1179648 block 6989415099341275135
chunk root gen 18446605285113004031 block 9799997659432=
353792
device root gen 9223372036861329408 block 0
csum root gen 65535 block 9799997659424489472
fs root gen 4295032832 block 25769803776
282399669551104 used 282400664715264 total
9799892621752008704 devices
btrfs root backup slot 2
tree root gen 65535 block 18446744073709551615
extent root gen 9799997659447099391 block 9799997659447=
033856
chunk root gen 0 block 0
device root gen 9799997659449196543 block 9799997659449=
196543
csum root gen 9799997659450703872 block 901956960255
fs root gen 9799997659448147967 block 97999976594481479=
67
9799893460940029951 used 9799997659450769407 total 6553=
5 devices
btrfs root backup slot 3
tree root gen 0 block 0
extent root gen 65535 block 9799979012494262271
chunk root gen 9799979012481613824 block 0
device root gen 65535 block 9799892621364101119
csum root gen 9799997659461255167 block 979999765946118=
9632
fs root gen 9799997659459158015 block 97999976594590924=
80
131071 used 9799892620200181759 total
9799997659463286784 devices
total bytes 5001013592064
bytes used 1186021638144
uuid 2c11a326-5630-484e-9f1d-9dab777a1028
Btrfs Btrfs v0.19
# ./btrfs-debug-tree -b 5568194695168 /dev/sdh
failed to read /dev/sr0: No medium found
failed to read /dev/sde: No medium found
failed to read /dev/sdd: No medium found
failed to read /dev/sdc: No medium found
failed to read /dev/sdb: No medium found
failed to read /dev/sda: No medium found
parent transid verify failed on 5568194695168 wanted 43477 found 43151
parent transid verify failed on 5568194695168 wanted 43477 found 43151
parent transid verify failed on 5568194695168 wanted 43477 found 43151
parent transid verify failed on 5568194695168 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568194748416 wanted 43477 found 43151
parent transid verify failed on 5568194748416 wanted 43477 found 43151
parent transid verify failed on 5568194748416 wanted 43477 found 43151
parent transid verify failed on 5568194748416 wanted 43477 found 43151
Ignoring transid failure
leaf 5568194695168 items 31 free space 2073 generation 43151 owner 2
fs uuid 2c11a326-5630-484e-9f1d-9dab777a1028
chunk uuid eb803623-85bd-4854-b39a-5c8126133242
item 0 key (5670333079552 EXTENT_ITEM 524288) itemoff 3958 item=
size 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818740224 count 1
item 1 key (5670333603840 EXTENT_ITEM 524288) itemoff 3921 item=
size 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818740224 count 1
item 2 key (5670334128128 EXTENT_ITEM 524288) itemoff 3884 item=
size 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818740224 count 1
item 3 key (5670334652416 EXTENT_ITEM 524288) itemoff 3847 item=
size 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818740224 count 1
item 4 key (5670335176704 EXTENT_ITEM 524288) itemoff 3810 item=
size 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818740224 count 1
item 5 key (5670335700992 EXTENT_ITEM 4096) itemoff 3773 itemsi=
ze 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306856251392 count 1
item 6 key (5670335705088 EXTENT_ITEM 4096) itemoff 3736 itemsi=
ze 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306856251392 count 1
item 7 key (5670335709184 EXTENT_ITEM 4096) itemoff 3699 itemsi=
ze 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306856251392 count 1
item 8 key (5670335713280 EXTENT_ITEM 4096) itemoff 3662 itemsi=
ze 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306856251392 count 1
item 9 key (5670335717376 EXTENT_ITEM 4096) itemoff 3625 itemsi=
ze 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818945024 count 1
item 10 key (5670335721472 EXTENT_ITEM 4096) itemoff 3588 items=
ize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818945024 count 1
item 11 key (5670335725568 EXTENT_ITEM 4096) itemoff 3551 items=
ize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818945024 count 1
item 12 key (5670335729664 EXTENT_ITEM 4096) itemoff 3514 items=
ize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306819330048 count 1
item 13 key (5670335733760 EXTENT_ITEM 4096) itemoff 3477 items=
ize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306819330048 count 1
item 14 key (5670335737856 EXTENT_ITEM 4096) itemoff 3440 items=
ize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306819330048 count 1
item 15 key (5670335741952 EXTENT_ITEM 4096) itemoff 3403 items=
ize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306820034560 count 1
item 16 key (5670335746048 EXTENT_ITEM 118784) itemoff 3366 ite=
msize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306850168832 count 1
item 17 key (5670335864832 EXTENT_ITEM 118784) itemoff 3329 ite=
msize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306850168832 count 1
item 18 key (5670335983616 EXTENT_ITEM 4096) itemoff 3292 items=
ize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306815574016 count 1
item 19 key (5670335987712 EXTENT_ITEM 4096) itemoff 3255 items=
ize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306815574016 count 1
item 20 key (5670335991808 EXTENT_ITEM 4096) itemoff 3218 items=
ize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306815574016 count 1
item 21 key (5670335995904 EXTENT_ITEM 4096) itemoff 3181 items=
ize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306858049536 count 1
item 22 key (5670336000000 EXTENT_ITEM 4096) itemoff 3144 items=
ize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306822180864 count 1
item 23 key (5670336004096 EXTENT_ITEM 4096) itemoff 3107 items=
ize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306820034560 count 1
item 24 key (5670336008192 EXTENT_ITEM 53248) itemoff 3070 item=
size 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306820165632 count 1
item 25 key (5670336061440 EXTENT_ITEM 4096) itemoff 3033 items=
ize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306858049536 count 1
item 26 key (5670336065536 EXTENT_ITEM 4096) itemoff 2996 items=
ize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306820034560 count 1
item 27 key (5670336069632 EXTENT_ITEM 4096) itemoff 2959 items=
ize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306820034560 count 1
item 28 key (5670336073728 EXTENT_ITEM 126976) itemoff 2922 ite=
msize 37
extent refs 1 gen 42845 flags 1
shared data backref parent 5306845855744 count 1
item 29 key (5670336200704 EXTENT_ITEM 122880) itemoff 2885 ite=
msize 37
extent refs 1 gen 42845 flags 1
shared data backref parent 5306845855744 count 1
item 30 key (5670336401408 EXTENT_ITEM 122880) itemoff 2848 ite=
msize 37
extent refs 1 gen 42845 flags 1
shared data backref parent 5306845855744 count 1
# ./btrfsck /dev/sdh
failed to read /dev/sr0: No medium found
failed to read /dev/sde: No medium found
failed to read /dev/sdd: No medium found
failed to read /dev/sdc: No medium found
failed to read /dev/sdb: No medium found
failed to read /dev/sda: No medium found
failed to read /dev/sr0: No medium found
failed to read /dev/sde: No medium found
failed to read /dev/sdd: No medium found
failed to read /dev/sdc: No medium found
failed to read /dev/sdb: No medium found
failed to read /dev/sda: No medium found
parent transid verify failed on 5568194695168 wanted 43477 found 43151
parent transid verify failed on 5568194695168 wanted 43477 found 43151
parent transid verify failed on 5568194695168 wanted 43477 found 43151
parent transid verify failed on 5568194695168 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568194748416 wanted 43477 found 43151
parent transid verify failed on 5568194748416 wanted 43477 found 43151
parent transid verify failed on 5568194748416 wanted 43477 found 43151
parent transid verify failed on 5568194748416 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568194801664 wanted 43477 found 43151
parent transid verify failed on 5568194801664 wanted 43477 found 43151
parent transid verify failed on 5568194801664 wanted 43477 found 43151
parent transid verify failed on 5568194801664 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568194674688 wanted 43477 found 43151
parent transid verify failed on 5568194674688 wanted 43477 found 43151
parent transid verify failed on 5568194674688 wanted 43477 found 43151
parent transid verify failed on 5568194674688 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568194678784 wanted 43477 found 43151
parent transid verify failed on 5568194678784 wanted 43477 found 43151
parent transid verify failed on 5568194678784 wanted 43477 found 43151
parent transid verify failed on 5568194678784 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568194809856 wanted 43477 found 43151
parent transid verify failed on 5568194809856 wanted 43477 found 43151
parent transid verify failed on 5568194809856 wanted 43477 found 43151
parent transid verify failed on 5568194809856 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568194875392 wanted 43477 found 42983
parent transid verify failed on 5568194875392 wanted 43477 found 42983
parent transid verify failed on 5568194875392 wanted 43477 found 42983
parent transid verify failed on 5568194875392 wanted 43477 found 42983
Ignoring transid failure
parent transid verify failed on 5568195104768 wanted 43477 found 43151
parent transid verify failed on 5568195104768 wanted 43477 found 43151
parent transid verify failed on 5568195104768 wanted 43477 found 43151
parent transid verify failed on 5568195104768 wanted 43477 found 43151
Ignoring transid failure
parent transid verify failed on 5568195043328 wanted 43477 found 43151
parent transid verify failed on 5568195162112 wanted 43477 found 43175
parent transid verify failed on 5568195162112 wanted 43477 found 43175
parent transid verify failed on 5568195162112 wanted 43477 found 43175
parent transid verify failed on 5568195162112 wanted 43477 found 43175
Ignoring transid failure
parent transid verify failed on 5568195166208 wanted 43477 found 43175
parent transid verify failed on 5568195166208 wanted 43477 found 43175
parent transid verify failed on 5568195166208 wanted 43477 found 43175
parent transid verify failed on 5568195166208 wanted 43477 found 43175
Ignoring transid failure
parent transid verify failed on 5568195178496 wanted 43477 found 43151
parent transid verify failed on 5568195178496 wanted 43477 found 43151
parent transid verify failed on 5568195178496 wanted 43477 found 43151
parent transid verify failed on 5568195178496 wanted 43477 found 43151
Ignoring transid failure
leaf 5568195178496 items 33 free space 1487 generation 43151 owner 2
fs uuid 2c11a326-5630-484e-9f1d-9dab777a1028
chunk uuid eb803623-85bd-4854-b39a-5c8126133242
item 0 key (4788521545728 EXTENT_ITEM 4096) itemoff 3944 itemsi=
ze 51
extent refs 1 gen 43146 flags 2
tree block key (5650061463552 a8 126976) level 0
tree block backref root 2
item 1 key (4788521578496 EXTENT_ITEM 4096) itemoff 3893 itemsi=
ze 51
extent refs 1 gen 43146 flags 2
tree block key (5689786920960 a8 524288) level 0
tree block backref root 2
item 2 key (4788521582592 EXTENT_ITEM 4096) itemoff 3842 itemsi=
ze 51
extent refs 1 gen 43146 flags 2
tree block key (5690869415936 c0 1073741824) level 0
tree block backref root 2
item 3 key (4788521607168 EXTENT_ITEM 4096) itemoff 3791 itemsi=
ze 51
extent refs 1 gen 43146 flags 2
tree block key (4895059722240 a8 4096) level 0
tree block backref root 2
item 4 key (4788521615360 EXTENT_ITEM 4096) itemoff 3740 itemsi=
ze 51
extent refs 1 gen 43080 flags 2
tree block key (5412215951360 a8 524288) level 0
tree block backref root 2
item 5 key (4788521648128 EXTENT_ITEM 4096) itemoff 3689 itemsi=
ze 51
extent refs 1 gen 43066 flags 2
tree block key (18446744073709551606 80 2302121607168) =
level 2
tree block backref root 7
item 6 key (4788521652224 EXTENT_ITEM 4096) itemoff 3638 itemsi=
ze 51
extent refs 1 gen 43066 flags 2
tree block key (18446744073709551606 80 2303572869120) =
level 1
tree block backref root 7
item 7 key (4788521656320 EXTENT_ITEM 4096) itemoff 3587 itemsi=
ze 51
extent refs 1 gen 43066 flags 2
tree block key (18446744073709551606 80 2303659085824) =
level 0
tree block backref root 7
item 8 key (4788521660416 EXTENT_ITEM 4096) itemoff 3536 itemsi=
ze 51
extent refs 1 gen 43066 flags 2
tree block key (18446744073709551606 80 4605637316608) =
level 2
tree block backref root 7
item 9 key (4788521664512 EXTENT_ITEM 4096) itemoff 3485 itemsi=
ze 51
extent refs 1 gen 43066 flags 2
tree block key (18446744073709551606 80 4619434360832) =
level 1
tree block backref root 7
item 10 key (4788521668608 EXTENT_ITEM 4096) itemoff 3434 items=
ize 51
extent refs 1 gen 43066 flags 2
tree block key (18446744073709551606 80 4619539591168) =
level 0
tree block backref root 7
item 11 key (4788521672704 EXTENT_ITEM 4096) itemoff 3383 items=
ize 51
extent refs 1 gen 43146 flags 2
tree block key (4895089258496 a8 4096) level 0
tree block backref root 2
item 12 key (4788521684992 EXTENT_ITEM 4096) itemoff 3332 items=
ize 51
extent refs 1 gen 43146 flags 2
tree block key (4895175733248 a8 4096) level 0
tree block backref root 2
item 13 key (4788521693184 EXTENT_ITEM 4096) itemoff 3281 items=
ize 51
extent refs 1 gen 38544 flags 2
tree block key (5038561599488 a8 524288) level 0
tree block backref root 2
item 14 key (4788521701376 EXTENT_ITEM 4096) itemoff 3230 items=
ize 51
extent refs 1 gen 38544 flags 2
tree block key (5038573133824 a8 524288) level 0
tree block backref root 2
item 15 key (4788521709568 EXTENT_ITEM 4096) itemoff 3179 items=
ize 51
extent refs 1 gen 43146 flags 2
tree block key (4895187546112 a8 4096) level 0
tree block backref root 2
item 16 key (4788521713664 EXTENT_ITEM 4096) itemoff 3128 items=
ize 51
extent refs 1 gen 43146 flags 2
tree block key (4895194083328 a8 4096) level 0
tree block backref root 2
item 17 key (4788521717760 EXTENT_ITEM 4096) itemoff 3077 items=
ize 51
extent refs 1 gen 41843 flags 2
tree block key (2258862821376 a8 4096) level 0
tree block backref root 2
item 18 key (4788521721856 EXTENT_ITEM 4096) itemoff 3026 items=
ize 51
extent refs 1 gen 43146 flags 2
tree block key (4895209906176 a8 4096) level 0
tree block backref root 2
item 19 key (4788521750528 EXTENT_ITEM 4096) itemoff 2975 items=
ize 51
extent refs 1 gen 42948 flags 2
tree block key (4665125572608 a8 4096) level 0
tree block backref root 2
item 20 key (4788521762816 EXTENT_ITEM 4096) itemoff 2924 items=
ize 51
extent refs 1 gen 42957 flags 2
tree block key (5701354262528 a8 524288) level 0
tree block backref root 2
item 21 key (4788521766912 EXTENT_ITEM 4096) itemoff 2873 items=
ize 51
extent refs 1 gen 42957 flags 2
tree block key (5701371514880 a8 524288) level 0
tree block backref root 2
item 22 key (4788521803776 EXTENT_ITEM 4096) itemoff 2822 items=
ize 51
extent refs 1 gen 43145 flags 2
tree block key (4895112712192 a8 4096) level 0
tree block backref root 2
item 23 key (4788521807872 EXTENT_ITEM 4096) itemoff 2771 items=
ize 51
extent refs 1 gen 43145 flags 2
tree block key (4895100817408 a8 4096) level 0
tree block backref root 2
item 24 key (4788521852928 EXTENT_ITEM 4096) itemoff 2720 items=
ize 51
extent refs 1 gen 38079 flags 2
tree block key (5122365489152 a8 524288) level 0
tree block backref root 2
item 25 key (4788521857024 EXTENT_ITEM 4096) itemoff 2669 items=
ize 51
extent refs 1 gen 38079 flags 2
tree block key (5123019517952 a8 524288) level 0
tree block backref root 2
item 26 key (4788521865216 EXTENT_ITEM 4096) itemoff 2618 items=
ize 51
extent refs 1 gen 42388 flags 2
tree block key (4713088446464 a8 4096) level 0
tree block backref root 2
item 27 key (4788521893888 EXTENT_ITEM 4096) itemoff 2567 items=
ize 51
extent refs 1 gen 43145 flags 2
tree block key (5562510573568 a8 524288) level 0
tree block backref root 2
item 28 key (4788521902080 EXTENT_ITEM 4096) itemoff 2516 items=
ize 51
extent refs 1 gen 43147 flags 2
tree block key (4788458668032 a8 4096) level 0
tree block backref root 2
item 29 key (4788521906176 EXTENT_ITEM 4096) itemoff 2465 items=
ize 51
extent refs 1 gen 43145 flags 2
tree block key (18446744073709551606 80 5562460946432) =
level 1
tree block backref root 7
item 30 key (4788521910272 EXTENT_ITEM 4096) itemoff 2414 items=
ize 51
extent refs 1 gen 43145 flags 2
tree block key (18446744073709551606 80 5562515656704) =
level 0
tree block backref root 7
item 31 key (4788521930752 EXTENT_ITEM 4096) itemoff 2363 items=
ize 51
extent refs 1 gen 43145 flags 2
tree block key (18446744073709551606 80 5625948966912) =
level 0
tree block backref root 7
item 32 key (4788521938944 EXTENT_ITEM 4096) itemoff 2312 items=
ize 51
extent refs 1 gen 43145 flags 2
tree block key (5627336638464 a8 524288) level 0
tree block backref root 2
failed to find block number 4895076519936
Aborted
On Wed, Feb 29, 2012 at 7:59 AM, Chris Mason <chris.mason@oracle.com> w=
rote:
> On Tue, Feb 28, 2012 at 09:36:35PM -0600, Travis Shivers wrote:
>> I upgraded my kernel so my version is now:
>> Linux server 3.3.0-030300rc5-generic #201202251535 SMP Sat Feb 25
>> 20:36:29 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>>
>> The problem has not been solved and I still get the previous errors.
>
> Ok,
>
> Step one is to grab the development version of btrfs-progs, which
> currently sits in the dangerdonteveruse branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git d=
angerdonteveruse
>
> Run btrfs-debug-tree -R /dev/sdh
>
> and then run btrfs-debug-tree -b 5568194695168 /dev/sdh
>
> and then run btrfsck /dev/sdh
>
> Send the results of all three here, it should tell us which tree that
> block belongs to, and from there we'll figure out the best way to fix
> it.
>
> -chris
>
>>
>> # mount /dev/sdh /mnt/main
>> mount: wrong fs type, bad option, bad superblock on /dev/sdh,
>> =A0 =A0 =A0 =A0missing codepage or helper program, or other error
>> =A0 =A0 =A0 =A0In some cases useful info is found in syslog - try
>> =A0 =A0 =A0 =A0dmesg | tail =A0or so
>>
>> # dmesg
>> [ =A0232.985248] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 de=
vid
>> 4 transid 43477 /dev/sdi
>> [ =A0232.985434] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 de=
vid
>> 3 transid 43477 /dev/sdh
>> [ =A0233.027881] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 de=
vid
>> 2 transid 43477 /dev/sdg
>> [ =A0233.065675] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 de=
vid
>> 1 transid 43476 /dev/sdf
>> [ =A0284.384320] device fsid 2c11a326-5630-484e-9f1d-9dab777a1028 de=
vid
>> 3 transid 43477 /dev/sdh
>> [ =A0284.427076] btrfs: disk space caching is enabled
>> [ =A0284.442565] verify_parent_transid: 2 callbacks suppressed
>> [ =A0284.442572] parent transid verify failed on 5568194695168 wante=
d
>> 43477 found 43151
>> [ =A0284.442834] parent transid verify failed on 5568194695168 wante=
d
>> 43477 found 43151
>> [ =A0284.443151] parent transid verify failed on 5568194695168 wante=
d
>> 43477 found 43151
>> [ =A0284.443159] parent transid verify failed on 5568194695168 wante=
d
>> 43477 found 43151
>> [ =A0284.445740] btrfs: open_ctree failed
>>
>>
>> On Tue, Feb 28, 2012 at 9:16 PM, cwillu <cwillu@cwillu.com> wrote:
>> > On Tue, Feb 28, 2012 at 9:00 PM, Travis Shivers <ttshivers@gmail.c=
om> wrote:
>> >> Where should I grab the source from? The main repo that you have
>> >> listed on your main wiki page
>> >> (https://btrfs.wiki.kernel.org/articles/b/t/r/Btrfs_source_reposi=
tories.html)
>> >> is down: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrf=
s-progs-unstable.git
>> >
>> > The btrfs wiki is at http://btrfs.ipv5.de . =A0The kernel.org one =
is a
>> > static snapshot of the contents made nearly a year ago, prior to t=
he
>> > kernel.org break-in, and should be ignored.
>> >
>> > git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.gi=
t is
>> > the development tree, although the above patch is in mainline as o=
f
>> > 3.3rc5, which probably makes that the easiest way to try it.
--
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
2012-02-29 21:57 ` Travis Shivers
@ 2012-02-29 22:14 ` Chris Mason
2012-02-29 23:11 ` Travis Shivers
0 siblings, 1 reply; 15+ messages in thread
From: Chris Mason @ 2012-02-29 22:14 UTC (permalink / raw)
To: Travis Shivers; +Cc: cwillu, Gurudas Pai, linux-btrfs
On Wed, Feb 29, 2012 at 03:57:19PM -0600, Travis Shivers wrote:
> Here is the output from the commands:
>
> # ./btrfs-debug-tree -R /dev/sdh
> failed to read /dev/sr0: No medium found
> failed to read /dev/sde: No medium found
> failed to read /dev/sdd: No medium found
> failed to read /dev/sdc: No medium found
> failed to read /dev/sdb: No medium found
> failed to read /dev/sda: No medium found
> parent transid verify failed on 5568194695168 wanted 43477 found 43151
So far all the blocks that have come up look like they are in the extent
allocation tree. This helps because it is the easiest to recover.
I can also make a patch for you against 3.3-rc that skips reading it
entirely, which should make it possible to copy things off.
But before I do that, could you describe the raid array? Was it
mirrored or raid10? What exactly happened when it stopped working?
-chris
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
2012-02-29 22:14 ` Chris Mason
@ 2012-02-29 23:11 ` Travis Shivers
2012-02-29 23:44 ` Chris Mason
0 siblings, 1 reply; 15+ messages in thread
From: Travis Shivers @ 2012-02-29 23:11 UTC (permalink / raw)
To: Chris Mason, Travis Shivers, cwillu, Gurudas Pai, linux-btrfs
Thank you all for helping. My btrfs array consists of 4 disks: 2 (2
TB) disks and 2(500 GB) disks. Since I have disks of different sizes,
I have the array being mirrored so that there are two copies of a file
on two separate disks. The data and metadata are mirrored.
I originally made the array by using this command:
# mkfs.btrfs -m raid1 -d raid1 /dev/sd[abcd]
(The drives were originally those letters)
All of the disks sit in an external 4 bay ESATA enclosure going into a
PCI-E RAID card set up as JBOD, so I can use btrfs' software
mirroring. This is the enclosure that I have:
http://www.newegg.com/Product/Product.aspx?Item=3DN82E16816132029
The corruption was unexpected. I am not entirely sure what caused it,
but a few days before the corruption, there were several power
outages. I do not think that the problem is with the actual hard drive
hardware since they are fairly new (6 months old) and they pass all
SMART tests. After a reboot, the btrfs array refused to mount and
started giving off errors. I do weekly scrubs, balances, and
defragmentation.
Here is what btrfs filesystem show says:
# btrfs filesystem show
Label: none uuid: 2c11a326-5630-484e-9f1d-9dab777a1028
Total devices 4 FS bytes used 1.08TB
devid 1 size 1.82TB used 1.08TB path /dev/sdf
devid 2 size 1.82TB used 1.08TB path /dev/sdg
devid 3 size 465.76GB used 8.00MB path /dev/sdh
devid 4 size 465.76GB used 8.00MB path /dev/sdi
Btrfs Btrfs v0.19
These are my normal mount line for the array in /etc/fstab
UUID=3D2c11a326-5630-484e-9f1d-9dab777a1028 /mnt/main btrfs
noatime,nodiratime,compress=3Dlzo,space_cache,inode_cache 0 1
On Wed, Feb 29, 2012 at 4:14 PM, Chris Mason <chris.mason@oracle.com> w=
rote:
> On Wed, Feb 29, 2012 at 03:57:19PM -0600, Travis Shivers wrote:
>> Here is the output from the commands:
>>
>> # ./btrfs-debug-tree -R /dev/sdh
>> failed to read /dev/sr0: No medium found
>> failed to read /dev/sde: No medium found
>> failed to read /dev/sdd: No medium found
>> failed to read /dev/sdc: No medium found
>> failed to read /dev/sdb: No medium found
>> failed to read /dev/sda: No medium found
>> parent transid verify failed on 5568194695168 wanted 43477 found 431=
51
>
> So far all the blocks that have come up look like they are in the ext=
ent
> allocation tree. =A0This helps because it is the easiest to recover.
>
> I can also make a patch for you against 3.3-rc that skips reading it
> entirely, which should make it possible to copy things off.
>
> But before I do that, could you describe the raid array? =A0Was it
> mirrored or raid10? =A0What exactly happened when it stopped working?
>
> -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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
2012-02-29 23:11 ` Travis Shivers
@ 2012-02-29 23:44 ` Chris Mason
2012-02-29 23:58 ` Travis Shivers
0 siblings, 1 reply; 15+ messages in thread
From: Chris Mason @ 2012-02-29 23:44 UTC (permalink / raw)
To: Travis Shivers; +Cc: cwillu, Gurudas Pai, linux-btrfs
On Wed, Feb 29, 2012 at 05:11:24PM -0600, Travis Shivers wrote:
> Thank you all for helping. My btrfs array consists of 4 disks: 2 (2
> TB) disks and 2(500 GB) disks. Since I have disks of different sizes,
> I have the array being mirrored so that there are two copies of a file
> on two separate disks. The data and metadata are mirrored.
>
> I originally made the array by using this command:
>
> # mkfs.btrfs -m raid1 -d raid1 /dev/sd[abcd]
> (The drives were originally those letters)
>
>
> All of the disks sit in an external 4 bay ESATA enclosure going into a
> PCI-E RAID card set up as JBOD, so I can use btrfs' software
> mirroring. This is the enclosure that I have:
> http://www.newegg.com/Product/Product.aspx?Item=N82E16816132029
>
> The corruption was unexpected. I am not entirely sure what caused it,
> but a few days before the corruption, there were several power
> outages. I do not think that the problem is with the actual hard drive
> hardware since they are fairly new (6 months old) and they pass all
> SMART tests. After a reboot, the btrfs array refused to mount and
> started giving off errors. I do weekly scrubs, balances, and
> defragmentation.
Ok, all of this should have worked. Which kernel were you running when
you had the power outages?
I'm testing out the patch to skip the extent allocation tree at mount.
That will be the easiest way to get to the data (readonly, but it'll
work).
-chris
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
2012-02-29 23:44 ` Chris Mason
@ 2012-02-29 23:58 ` Travis Shivers
2012-03-16 17:30 ` Travis Shivers
[not found] ` <CAPeorG-Zrr-fTaYmHHKQ5=0jL9ZqjbTypGzo7je3g=MJDPmXcA@mail.gmail.com>
0 siblings, 2 replies; 15+ messages in thread
From: Travis Shivers @ 2012-02-29 23:58 UTC (permalink / raw)
To: Chris Mason, Travis Shivers, cwillu, Gurudas Pai, linux-btrfs
I was running a fairly old version of the kernel:
Linux server 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux
On Wed, Feb 29, 2012 at 5:44 PM, Chris Mason <chris.mason@oracle.com> w=
rote:
> On Wed, Feb 29, 2012 at 05:11:24PM -0600, Travis Shivers wrote:
>> Thank you all for helping. My btrfs array consists of 4 disks: 2 (2
>> TB) disks and 2(500 GB) disks. Since I have disks of different sizes=
,
>> I have the array being mirrored so that there are two copies of a fi=
le
>> on two separate disks. The data and metadata are mirrored.
>>
>> I originally made the array by using this command:
>>
>> # mkfs.btrfs -m raid1 -d raid1 /dev/sd[abcd]
>> (The drives were originally those letters)
>>
>>
>> All of the disks sit in an external 4 bay ESATA enclosure going into=
a
>> PCI-E RAID card set up as JBOD, so I can use btrfs' software
>> mirroring. This is the enclosure that I have:
>> http://www.newegg.com/Product/Product.aspx?Item=3DN82E16816132029
>>
>> The corruption was unexpected. I am not entirely sure what caused it=
,
>> but a few days before the corruption, there were several power
>> outages. I do not think that the problem is with the actual hard dri=
ve
>> hardware since they are fairly new (6 months old) and they pass all
>> SMART tests. After a reboot, the btrfs array refused to mount and
>> started giving off errors. I do weekly scrubs, balances, and
>> defragmentation.
>
> Ok, all of this should have worked. =A0Which kernel were you running =
when
> you had the power outages?
>
> I'm testing out the patch to skip the extent allocation tree at mount=
=2E
> That will be the easiest way to get to the data (readonly, but it'll
> work).
>
> -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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
2012-02-29 23:58 ` Travis Shivers
@ 2012-03-16 17:30 ` Travis Shivers
[not found] ` <CAPeorG-Zrr-fTaYmHHKQ5=0jL9ZqjbTypGzo7je3g=MJDPmXcA@mail.gmail.com>
1 sibling, 0 replies; 15+ messages in thread
From: Travis Shivers @ 2012-03-16 17:30 UTC (permalink / raw)
To: linux-btrfs
When you finish the patch, where should I get it from? Is it a general
btrfs patch, and I would grab it in the next kernel release, or is it
a specific patch for me, and I would grab it from a btrfs repository?
Thanks again for all of your help.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Btrfs Storage Array Corrupted
[not found] ` <CAPeorG-Zrr-fTaYmHHKQ5=0jL9ZqjbTypGzo7je3g=MJDPmXcA@mail.gmail.com>
@ 2012-03-26 23:15 ` Travis Shivers
0 siblings, 0 replies; 15+ messages in thread
From: Travis Shivers @ 2012-03-26 23:15 UTC (permalink / raw)
To: Chris Mason, Travis Shivers, cwillu, Gurudas Pai, linux-btrfs
Hello,
I was just wondering what the status of the patch that would fix my
problem is. I have not heard from anyone in over a month, and I just
wanted to check in and see how it is progressing, or if you have put
it on hold for more important work like kernel 3.4. Thank you again
for helping me.
On Fri, Mar 16, 2012 at 12:26 PM, Travis Shivers <ttshivers@gmail.com> =
wrote:
>
> When you finish the patch, where should I get it from? Is it a genera=
l btrfs patch, and I would grab it in the next kernel release, or is it=
a specific patch for me, and I would grab it from a btrfs repository? =
Thanks again for all of your help.
>
>
> On Wed, Feb 29, 2012 at 5:58 PM, Travis Shivers <ttshivers@gmail.com>=
wrote:
>>
>> I was running a fairly old version of the kernel:
>> Linux server 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC
>> 2012 x86_64 x86_64 x86_64 GNU/Linux
>>
>> On Wed, Feb 29, 2012 at 5:44 PM, Chris Mason <chris.mason@oracle.com=
> wrote:
>> > On Wed, Feb 29, 2012 at 05:11:24PM -0600, Travis Shivers wrote:
>> >> Thank you all for helping. My btrfs array consists of 4 disks: 2 =
(2
>> >> TB) disks and 2(500 GB) disks. Since I have disks of different si=
zes,
>> >> I have the array being mirrored so that there are two copies of a=
file
>> >> on two separate disks. The data and metadata are mirrored.
>> >>
>> >> I originally made the array by using this command:
>> >>
>> >> # mkfs.btrfs -m raid1 -d raid1 /dev/sd[abcd]
>> >> (The drives were originally those letters)
>> >>
>> >>
>> >> All of the disks sit in an external 4 bay ESATA enclosure going i=
nto a
>> >> PCI-E RAID card set up as JBOD, so I can use btrfs' software
>> >> mirroring. This is the enclosure that I have:
>> >> http://www.newegg.com/Product/Product.aspx?Item=3DN82E16816132029
>> >>
>> >> The corruption was unexpected. I am not entirely sure what caused=
it,
>> >> but a few days before the corruption, there were several power
>> >> outages. I do not think that the problem is with the actual hard =
drive
>> >> hardware since they are fairly new (6 months old) and they pass a=
ll
>> >> SMART tests. After a reboot, the btrfs array refused to mount and
>> >> started giving off errors. I do weekly scrubs, balances, and
>> >> defragmentation.
>> >
>> > Ok, all of this should have worked. =A0Which kernel were you runni=
ng when
>> > you had the power outages?
>> >
>> > I'm testing out the patch to skip the extent allocation tree at mo=
unt.
>> > That will be the easiest way to get to the data (readonly, but it'=
ll
>> > work).
>> >
>> > -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
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-03-26 23:15 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-29 0:13 Btrfs Storage Array Corrupted Travis Shivers
2012-02-29 0:34 ` Fajar A. Nugraha
2012-02-29 1:41 ` Gurudas Pai
2012-02-29 2:50 ` Chris Mason
2012-02-29 3:00 ` Travis Shivers
2012-02-29 3:16 ` cwillu
2012-02-29 3:36 ` Travis Shivers
2012-02-29 13:59 ` Chris Mason
2012-02-29 21:57 ` Travis Shivers
2012-02-29 22:14 ` Chris Mason
2012-02-29 23:11 ` Travis Shivers
2012-02-29 23:44 ` Chris Mason
2012-02-29 23:58 ` Travis Shivers
2012-03-16 17:30 ` Travis Shivers
[not found] ` <CAPeorG-Zrr-fTaYmHHKQ5=0jL9ZqjbTypGzo7je3g=MJDPmXcA@mail.gmail.com>
2012-03-26 23:15 ` Travis Shivers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).