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, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail 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=11726449#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
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 failureDid you try a read-only mount (-o ro) after you run btrfs-zero-log? -- Fajar -- 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
># btrfs-debug-tree /dev/sdhcouldn''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) -- -- 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 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-- 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
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 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> wrote:> 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-- 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 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.gitThe 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. -- 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 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_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.
--
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 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 dangerdonteveruse 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, > 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_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.-- 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
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 9799972705260863487
device root gen 9799997658994114559 block 18446638534628474880
csum root gen 94490787839 block 18446638559949619199
fs root gen 262144 block 1048576
9799994850661629952 used 0 total 9799997659432419327 devices
btrfs root backup slot 1
tree root gen 16777216 block 38655295488
extent root gen 1179648 block 6989415099341275135
chunk root gen 18446605285113004031 block 9799997659432353792
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 9799997659447033856
chunk root gen 0 block 0
device root gen 9799997659449196543 block 9799997659449196543
csum root gen 9799997659450703872 block 901956960255
fs root gen 9799997659448147967 block 9799997659448147967
9799893460940029951 used 9799997659450769407 total 65535 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 9799997659461189632
fs root gen 9799997659459158015 block 9799997659459092480
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 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818740224 count 1
item 1 key (5670333603840 EXTENT_ITEM 524288) itemoff 3921 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818740224 count 1
item 2 key (5670334128128 EXTENT_ITEM 524288) itemoff 3884 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818740224 count 1
item 3 key (5670334652416 EXTENT_ITEM 524288) itemoff 3847 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818740224 count 1
item 4 key (5670335176704 EXTENT_ITEM 524288) itemoff 3810 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818740224 count 1
item 5 key (5670335700992 EXTENT_ITEM 4096) itemoff 3773 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306856251392 count 1
item 6 key (5670335705088 EXTENT_ITEM 4096) itemoff 3736 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306856251392 count 1
item 7 key (5670335709184 EXTENT_ITEM 4096) itemoff 3699 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306856251392 count 1
item 8 key (5670335713280 EXTENT_ITEM 4096) itemoff 3662 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306856251392 count 1
item 9 key (5670335717376 EXTENT_ITEM 4096) itemoff 3625 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818945024 count 1
item 10 key (5670335721472 EXTENT_ITEM 4096) itemoff 3588 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818945024 count 1
item 11 key (5670335725568 EXTENT_ITEM 4096) itemoff 3551 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306818945024 count 1
item 12 key (5670335729664 EXTENT_ITEM 4096) itemoff 3514 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306819330048 count 1
item 13 key (5670335733760 EXTENT_ITEM 4096) itemoff 3477 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306819330048 count 1
item 14 key (5670335737856 EXTENT_ITEM 4096) itemoff 3440 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306819330048 count 1
item 15 key (5670335741952 EXTENT_ITEM 4096) itemoff 3403 itemsize 37
extent refs 1 gen 42674 flags 1
shared data backref parent 5306820034560 count 1
item 16 key (5670335746048 EXTENT_ITEM 118784) itemoff 3366 itemsize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306850168832 count 1
item 17 key (5670335864832 EXTENT_ITEM 118784) itemoff 3329 itemsize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306850168832 count 1
item 18 key (5670335983616 EXTENT_ITEM 4096) itemoff 3292 itemsize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306815574016 count 1
item 19 key (5670335987712 EXTENT_ITEM 4096) itemoff 3255 itemsize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306815574016 count 1
item 20 key (5670335991808 EXTENT_ITEM 4096) itemoff 3218 itemsize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306815574016 count 1
item 21 key (5670335995904 EXTENT_ITEM 4096) itemoff 3181 itemsize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306858049536 count 1
item 22 key (5670336000000 EXTENT_ITEM 4096) itemoff 3144 itemsize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306822180864 count 1
item 23 key (5670336004096 EXTENT_ITEM 4096) itemoff 3107 itemsize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306820034560 count 1
item 24 key (5670336008192 EXTENT_ITEM 53248) itemoff 3070 itemsize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306820165632 count 1
item 25 key (5670336061440 EXTENT_ITEM 4096) itemoff 3033 itemsize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306858049536 count 1
item 26 key (5670336065536 EXTENT_ITEM 4096) itemoff 2996 itemsize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306820034560 count 1
item 27 key (5670336069632 EXTENT_ITEM 4096) itemoff 2959 itemsize 37
extent refs 1 gen 42683 flags 1
shared data backref parent 5306820034560 count 1
item 28 key (5670336073728 EXTENT_ITEM 126976) itemoff 2922 itemsize 37
extent refs 1 gen 42845 flags 1
shared data backref parent 5306845855744 count 1
item 29 key (5670336200704 EXTENT_ITEM 122880) itemoff 2885 itemsize 37
extent refs 1 gen 42845 flags 1
shared data backref parent 5306845855744 count 1
item 30 key (5670336401408 EXTENT_ITEM 122880) itemoff 2848 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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 itemsize 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>
wrote:> 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
dangerdonteveruse
>
> 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,
>> 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_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.
--
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, 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 43151So 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 -- 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
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.
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=2c11a326-5630-484e-9f1d-9dab777a1028 /mnt/main btrfs
noatime,nodiratime,compress=lzo,space_cache,inode_cache 0 1
On Wed, Feb 29, 2012 at 4:14 PM, Chris Mason <chris.mason@oracle.com>
wrote:> 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
--
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, 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 -- 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 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 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-- 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
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. -- 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
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 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. > > > 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 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 > >-- 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