Segfault in btrfsck

Segfault in btrfsck

[Steve Freitas]

I've got a Debian unstable system (kernel is 2.6.32-trunk-amd64) with
the root partition running btrfs. Used it for a few weeks with no large
problems, but had to reboot it this morning after it became unresponsive
simultaneous with unexplained constant disk access. It wouldn't reboot
-- it loaded the kernel fine off the ext3 /boot partition but couldn't
mount root.

Booted into the Karmic live disk (2.6.31-14, also amd64). Ran their
stock btrfsck and it crashed. Pulled the latest from unstable git and it
did the same.

I didn't build btrfsck with debug enabled, so if you want that let me
know how to change the Makefile (or whatever). I can also supply the
core file if you like. Also, smartctl is telling me this hard drive has
lots of bad sectors :-D, but don't know if that's relevant here.

Thanks!

- Steve

root@ubuntu:~# btrfsck /dev/sda3
leaf 72134656 items 26 free space 2019 generation 29647 owner 2
fs uuid c43fe29d-d95c-4a33-8097-f5c61dfc77ed
chunk uuid 6a52db0a-04d3-4a1e-8e27-f73306b28a51
	item 0 key (69120000 EXTENT_ITEM 4096) itemoff 3944 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (204066004992 a8 8192) level 0
		tree block backref root 2
	item 1 key (69124096 EXTENT_ITEM 4096) itemoff 3893 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (204069421056 a8 524288) level 0
		tree block backref root 2
	item 2 key (69128192 EXTENT_ITEM 4096) itemoff 3842 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (204071538688 a8 81920) level 0
		tree block backref root 2
	item 3 key (69132288 EXTENT_ITEM 4096) itemoff 3791 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (204075094016 a8 16384) level 0
		tree block backref root 2
	item 4 key (69136384 EXTENT_ITEM 4096) itemoff 3740 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (204078809088 a8 49152) level 0
		tree block backref root 2
	item 5 key (69144576 EXTENT_ITEM 4096) itemoff 3689 itemsize 51
		extent refs 1 gen 28342 flags 2
		tree block key (214869 54 2384640830) level 2
		tree block backref root 5
	item 6 key (69148672 EXTENT_ITEM 4096) itemoff 3638 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (204124024832 a8 8192) level 0
		tree block backref root 2
	item 7 key (69152768 EXTENT_ITEM 4096) itemoff 3587 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (204131520512 a8 20480) level 0
		tree block backref root 2
	item 8 key (69156864 EXTENT_ITEM 4096) itemoff 3536 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (204142813184 a8 421888) level 1
		tree block backref root 2
	item 9 key (69160960 EXTENT_ITEM 4096) itemoff 3485 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (204142813184 a8 421888) level 0
		tree block backref root 2
	item 10 key (69165056 EXTENT_ITEM 4096) itemoff 3434 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (204149268480 a8 507904) level 0
		tree block backref root 2
	item 11 key (69169152 EXTENT_ITEM 4096) itemoff 3383 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (204154077184 a8 65536) level 0
		tree block backref root 2
	item 12 key (69173248 EXTENT_ITEM 4096) itemoff 3332 itemsize 51
		extent refs 1 gen 28052 flags 2
		tree block key (18446744073709551606 80 223654449152) level 1
		tree block backref root 7
	item 13 key (69177344 EXTENT_ITEM 4096) itemoff 3281 itemsize 51
		extent refs 1 gen 28052 flags 2
		tree block key (18446744073709551606 80 223726600192) level 0
		tree block backref root 7
	item 14 key (69181440 EXTENT_ITEM 4096) itemoff 3230 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (18446744073709551606 80 204194607104) level 1
		tree block backref root 7
	item 15 key (69185536 EXTENT_ITEM 4096) itemoff 3179 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (18446744073709551606 80 204258570240) level 0
		tree block backref root 7
	item 16 key (69189632 EXTENT_ITEM 4096) itemoff 3128 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (18446744073709551606 80 204256403456) level 0
		tree block backref root 7
	item 17 key (69193728 EXTENT_ITEM 4096) itemoff 3077 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (18446744073709551606 80 204252368896) level 0
		tree block backref root 7
	item 18 key (69197824 EXTENT_ITEM 4096) itemoff 3026 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (18446744073709551606 80 204248334336) level 0
		tree block backref root 7
	item 19 key (69201920 EXTENT_ITEM 4096) itemoff 2975 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (18446744073709551606 80 204244299776) level 0
		tree block backref root 7
	item 20 key (69206016 EXTENT_ITEM 4096) itemoff 2924 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (18446744073709551606 80 204243025920) level 0
		tree block backref root 7
	item 21 key (69210112 EXTENT_ITEM 4096) itemoff 2873 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (18446744073709551606 80 204238987264) level 0
		tree block backref root 7
	item 22 key (69214208 EXTENT_ITEM 4096) itemoff 2822 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (18446744073709551606 80 204234952704) level 0
		tree block backref root 7
	item 23 key (69218304 EXTENT_ITEM 4096) itemoff 2771 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (18446744073709551606 80 204229103616) level 0
		tree block backref root 7
	item 24 key (69222400 EXTENT_ITEM 4096) itemoff 2720 itemsize 51
		extent refs 1 gen 25448 flags 2
		tree block key (18446744073709551606 80 204225191936) level 0
		tree block backref root 7
	item 25 key (69226496 EXTENT_ITEM 4096) itemoff 2669 itemsize 51
		extent refs 1 gen 28342 flags 2
		tree block key (216906 54 775391778) level 1
		tree block backref root 5
failed to find block number 69140480
Aborted (core dumped)

btrfs volume mounts and dies (was Re: Segfault in btrfsck)

[Steve Freitas]

Got some more information. I installed Debian on another disk ("rescue")
running 2.6.32, pulled the latest btrfs module code from git, applied an
earlier mentioned patch[1], then compiled and loaded the new module.
It's able to mount the volume initially...

Jan  3 14:46:57 rescue kernel: [   25.984141] Btrfs loaded
Jan  3 14:46:57 rescue kernel: [   25.984711] device fsid
334a5cd99de23fc4-ed77fc1dc6f59780 devid 1 transid 29665 /dev/sdb3
Jan  3 14:46:57 rescue kernel: [   25.985137] btrfs: use compression

But after a little activity (chrooting in and running "apt-get update"),
the apt-get freezes and I get many hundreds of thousands of these:

Jan  3 14:47:30 rescue kernel: [   59.275031] parent transid verify
failed on 111181824 wanted 29645 found 27038

Eventually, I get this:

Jan  3 14:50:31 rescue kernel: [  240.364274] INFO: task
btrfs-transacti:1400 blocked for more than 120 seconds.
Jan  3 14:50:31 rescue kernel: [  240.364337] "echo 0
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan  3 14:50:31 rescue kernel: [  240.364399] btrfs-transac D
0000000000000000     0  1400      2 0x00000000
Jan  3 14:50:31 rescue kernel: [  240.364515]  ffff88021f06b880
0000000000000046 0000000000000000 ffffffffa02d4e98
Jan  3 14:50:31 rescue kernel: [  240.364692]  ffffea0007646b10
0000000000000000 000000000000f8a0 ffff88021cb75fd8
Jan  3 14:50:31 rescue kernel: [  240.364867]  00000000000155c0
00000000000155c0 ffff88021dc37810 ffff88021dc37b08
Jan  3 14:50:31 rescue kernel: [  240.365042] Call Trace:
Jan  3 14:50:31 rescue kernel: [  240.365097]  [<ffffffffa02d4e98>] ?
update_block_group+0x1b1/0x1d3 [btrfs]
Jan  3 14:50:31 rescue kernel: [  240.365150]  [<ffffffff8106bebd>] ?
ktime_get_ts+0x68/0xb2
Jan  3 14:50:31 rescue kernel: [  240.365201]  [<ffffffff810989b2>] ?
delayacct_end+0x74/0x7f
Jan  3 14:50:31 rescue kernel: [  240.365251]  [<ffffffff810b2c91>] ?
sync_page+0x0/0x46
Jan  3 14:50:31 rescue kernel: [  240.365300]  [<ffffffff812e412e>] ?
io_schedule+0x73/0xb7
Jan  3 14:50:31 rescue kernel: [  240.365349]  [<ffffffff810b2cd2>] ?
sync_page+0x41/0x46
Jan  3 14:50:31 rescue kernel: [  240.365397]  [<ffffffff812e462e>] ?
__wait_on_bit+0x41/0x70
Jan  3 14:50:31 rescue kernel: [  240.365447]  [<ffffffff810b2e56>] ?
wait_on_page_bit+0x6b/0x71
Jan  3 14:50:31 rescue kernel: [  240.365496]  [<ffffffff81064a9c>] ?
wake_bit_function+0x0/0x23
Jan  3 14:50:31 rescue kernel: [  240.365547]  [<ffffffff810ba94e>] ?
pagevec_lookup_tag+0x1a/0x21
Jan  3 14:50:31 rescue kernel: [  240.365596]  [<ffffffff810b35f2>] ?
wait_on_page_writeback_range+0x69/0x11b
Jan  3 14:50:31 rescue kernel: [  240.365655]  [<ffffffffa02f83d9>] ?
btrfs_wait_ordered_range+0x6b/0x112 [btrfs]
Jan  3 14:50:31 rescue kernel: [  240.365725]  [<ffffffffa02f865e>] ?
btrfs_run_ordered_operations+0x12d/0x1b6 [btrfs]
Jan  3 14:50:31 rescue kernel: [  240.365794]  [<ffffffffa02e353f>] ?
btrfs_commit_transaction+0x29f/0x618 [btrfs]
Jan  3 14:50:31 rescue kernel: [  240.365857]  [<ffffffff81064a6e>] ?
autoremove_wake_function+0x0/0x2e
Jan  3 14:50:31 rescue kernel: [  240.365913]  [<ffffffffa02df2cf>] ?
transaction_kthread+0x173/0x204 [btrfs]
Jan  3 14:50:31 rescue kernel: [  240.365970]  [<ffffffffa02df15c>] ?
transaction_kthread+0x0/0x204 [btrfs]
Jan  3 14:50:31 rescue kernel: [  240.366021]  [<ffffffff810647a1>] ?
kthread+0x79/0x81
Jan  3 14:50:31 rescue kernel: [  240.366070]  [<ffffffff81011b6a>] ?
child_rip+0xa/0x20
Jan  3 14:50:31 rescue kernel: [  240.366118]  [<ffffffff81064728>] ?
kthread+0x0/0x81
Jan  3 14:50:31 rescue kernel: [  240.366166]  [<ffffffff81011b60>] ?
child_rip+0x0/0x20
Jan  3 14:50:31 rescue kernel: [  240.366214] INFO: task apt-get:1411
blocked for more than 120 seconds.
Jan  3 14:50:31 rescue kernel: [  240.366264] "echo 0
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan  3 14:50:31 rescue kernel: [  240.366326] apt-get       D
0000000000000002     0  1411   1407 0x00000004
Jan  3 14:50:31 rescue kernel: [  240.366433]  ffff88021dc32a60
0000000000000082 0000005001c9f000 0000000001c9f000
Jan  3 14:50:31 rescue kernel: [  240.366608]  0000000000000000
0000000000000000 000000000000f8a0 ffff88021b869fd8
Jan  3 14:50:31 rescue kernel: [  240.366782]  00000000000155c0
00000000000155c0 ffff88021c3d69f0 ffff88021c3d6ce8
Jan  3 14:50:31 rescue kernel: [  240.366957] Call Trace:
Jan  3 14:50:31 rescue kernel: [  240.367002]  [<ffffffff810b7df3>] ?
__pagevec_free+0x69/0x80
Jan  3 14:50:31 rescue kernel: [  240.367051]  [<ffffffff81017131>] ?
read_tsc+0xa/0x20
Jan  3 14:50:31 rescue kernel: [  240.367100]  [<ffffffff810b2c91>] ?
sync_page+0x0/0x46
Jan  3 14:50:31 rescue kernel: [  240.367148]  [<ffffffff812e412e>] ?
io_schedule+0x73/0xb7
Jan  3 14:50:31 rescue kernel: [  240.367197]  [<ffffffff810b2cd2>] ?
sync_page+0x41/0x46
Jan  3 14:50:31 rescue kernel: [  240.367245]  [<ffffffff812e462e>] ?
__wait_on_bit+0x41/0x70
Jan  3 14:50:31 rescue kernel: [  240.367294]  [<ffffffff810b2e56>] ?
wait_on_page_bit+0x6b/0x71
Jan  3 14:50:31 rescue kernel: [  240.367343]  [<ffffffff81064a9c>] ?
wake_bit_function+0x0/0x23
Jan  3 14:50:31 rescue kernel: [  240.367393]  [<ffffffff810bb33e>] ?
lock_page+0x9/0x1f
Jan  3 14:50:31 rescue kernel: [  240.367441]  [<ffffffff810bba88>] ?
truncate_inode_pages_range+0x257/0x2b0
Jan  3 14:50:31 rescue kernel: [  240.367500]  [<ffffffffa02e9881>] ?
btrfs_delete_inode+0x27/0x132 [btrfs]
Jan  3 14:50:31 rescue kernel: [  240.367557]  [<ffffffffa02e985a>] ?
btrfs_delete_inode+0x0/0x132 [btrfs]
Jan  3 14:50:31 rescue kernel: [  240.367609]  [<ffffffff810fd840>] ?
generic_delete_inode+0xdc/0x168
Jan  3 14:50:31 rescue kernel: [  240.367659]  [<ffffffff810fa1ff>] ?
d_kill+0x34/0x55
Jan  3 14:50:31 rescue kernel: [  240.367707]  [<ffffffff810fbd76>] ?
dput+0x13d/0x149
Jan  3 14:50:31 rescue kernel: [  240.367755]  [<ffffffff810f651c>] ?
sys_renameat+0x184/0x1e9
Jan  3 14:50:31 rescue kernel: [  240.367804]  [<ffffffff81064a6e>] ?
autoremove_wake_function+0x0/0x2e
Jan  3 14:50:31 rescue kernel: [  240.367854]  [<ffffffff8106bebd>] ?
ktime_get_ts+0x68/0xb2
Jan  3 14:50:31 rescue kernel: [  240.367904]  [<ffffffff810ec812>] ?
vfs_read+0xca/0xff
Jan  3 14:50:31 rescue kernel: [  240.367953]  [<ffffffff81010b02>] ?
system_call_fastpath+0x16/0x1b

Any ideas? I'm happy to apply any patches you suggest and try again...

Steve

[1]http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg03686.html

Re: btrfs volume mounts and dies (was Re: Segfault in btrfsck)

[Steve Freitas]

On Sun, 2010-01-03 at 14:57 -0800, Steve Freitas wrote:
> Got some more information. I installed Debian on another disk ("rescue")
> running 2.6.32, pulled the latest btrfs module code from git, applied an
> earlier mentioned patch[1], then compiled and loaded the new module.
> It's able to mount the volume initially...

I've just tried it again with the pure git pull, no patch, and the
result (of an "ls -R /mnt/btrfs_vol") was the same. 'Cept this time it
never gave me a kernel traceback, just unending lines like:

Jan  3 16:36:36 rescue kernel: [ 1046.494252] parent transid verify
failed on 69140480 wanted 28342 found 29646

Steve

Re: btrfs volume mounts and dies (was Re: Segfault in btrfsck)

[Steve Freitas]

Should I take it by the lack of list response that I should just flush
this partition down the toilet and start over? Or is everybody either
flummoxed or on vacation?

Steve

On Sun, 2010-01-03 at 16:37 -0800, Steve Freitas wrote:
> On Sun, 2010-01-03 at 14:57 -0800, Steve Freitas wrote:
> > Got some more information. I installed Debian on another disk ("rescue")
> > running 2.6.32, pulled the latest btrfs module code from git, applied an
> > earlier mentioned patch[1], then compiled and loaded the new module.
> > It's able to mount the volume initially...
> 
> I've just tried it again with the pure git pull, no patch, and the
> result (of an "ls -R /mnt/btrfs_vol") was the same. 'Cept this time it
> never gave me a kernel traceback, just unending lines like:
> 
> Jan  3 16:36:36 rescue kernel: [ 1046.494252] parent transid verify
> failed on 69140480 wanted 28342 found 29646
> 
> Steve
> 
> --
> 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

Re: btrfs volume mounts and dies (was Re: Segfault in btrfsck)

[Sander]

Hello Steve,

Steve Freitas wrote (ao):
> Should I take it by the lack of list response that I should just flush
> this partition down the toilet and start over? Or is everybody either
> flummoxed or on vacation?

I don't have your original mail, but I think I remember you mentioned a
lot of bad sectors on that disk reported by SMART.

If that is indeed the case it might be dificult for the people who might
be able to help you, to help you.

Please ignore me if I confused your mail with another.

	With kind regard, Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net

Re: btrfs volume mounts and dies (was Re: Segfault in btrfsck)

[Steve Freitas]

Hi Sander,

On Wed, 2010-01-06 at 08:52 +0100, Sander wrote:
> I don't have your original mail, but I think I remember you mentioned a
> lot of bad sectors on that disk reported by SMART.
> 
> If that is indeed the case it might be dificult for the people who might
> be able to help you, to help you.

Thanks for your  response. You're correct about the bad sector warning.
So please correct me if I have some mistaken assumptions. I thought
btrfs would be tolerant of that -- if a block failed the checksum test,
it would reconstruct and remap it. (Also, I assumed that if a drive
hadn't filled its bad sector remapping table, it could handle it at the
hardware level, and SMART's warning was just that -- a warning, not a
dire pronouncement of utter unsuitability -- but that's something else.)

Steve

Re: btrfs volume mounts and dies (was Re: Segfault in btrfsck)

[Johannes Hirte]

Am Mittwoch 06 Januar 2010 16:59:55 schrieb Steve Freitas:
> Hi Sander,
> 
> On Wed, 2010-01-06 at 08:52 +0100, Sander wrote:
> > I don't have your original mail, but I think I remember you mentioned a
> > lot of bad sectors on that disk reported by SMART.
> >
> > If that is indeed the case it might be dificult for the people who might
> > be able to help you, to help you.
> 
> Thanks for your  response. You're correct about the bad sector warning.
> So please correct me if I have some mistaken assumptions. I thought
> btrfs would be tolerant of that -- if a block failed the checksum test,
> it would reconstruct and remap it. 
Only if enough redundancy is left. And with the default setup btrfs is only 
mirroring the metadata not the data.

> (Also, I assumed that if a drive
> hadn't filled its bad sector remapping table, it could handle it at the
> hardware level, and SMART's warning was just that -- a warning, not a
> dire pronouncement of utter unsuitability -- but that's something else.)

Bad sectors are only remapped by the drive on write time. As long as this 
isn't the case, they are only marked as pending. As you have written, that 
SMART detected many bad blocks, I suspect the FS is really damaged. And as 
btrfsck is limited, I don't think it can fix this.

regards,
  Johannes

Re: btrfs volume mounts and dies (was Re: Segfault in btrfsck)

[Steve Freitas]

Hi Johannes,

On Wed, 2010-01-06 at 18:24 +0100, Johannes Hirte wrote:
> Am Mittwoch 06 Januar 2010 16:59:55 schrieb Steve Freitas:
> > Thanks for your  response. You're correct about the bad sector warning.
> > So please correct me if I have some mistaken assumptions. I thought
> > btrfs would be tolerant of that -- if a block failed the checksum test,
> > it would reconstruct and remap it. 
> Only if enough redundancy is left. And with the default setup btrfs is only 
> mirroring the metadata not the data.

Okay. What capacity does btrfs have for reconstructing data, and how do
I enable it (if any) for a new partition? I think I've confused
checksums with magical ponies.

> Bad sectors are only remapped by the drive on write time. As long as this 
> isn't the case, they are only marked as pending. As you have written, that 
> SMART detected many bad blocks, I suspect the FS is really damaged. And as 
> btrfsck is limited, I don't think it can fix this.

Alright, I'll trash it and start over with a different drive.

Thanks,

Steve

Re: btrfs volume mounts and dies (was Re: Segfault in btrfsck)

[Sander]

Hello Steve,

Steve Freitas wrote (ao):
> Alright, I'll trash it and start over with a different drive.

With the danger of mentioning the obvious: you could do a few
destructive badblocks runs on that disk to see if SMART keeps adding up
to the bad blocks list.

	With kind regards, Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net

What protection does btrfs checksumming currently give? (Was Re: btrfs volume mounts and dies (was Re: Segfault in btrfsck))

[Steve Freitas]

Hi all,

I was under the mistaken impression that btrfs checksumming, in its
current default configuration, protected your data from bitrot. It
appears this is not the case:

On Wed, 2010-01-06 at 18:24 +0100, Johannes Hirte wrote:
> Am Mittwoch 06 Januar 2010 16:59:55 schrieb Steve Freitas:
> > So please correct me if I have some mistaken assumptions. I thought
> > btrfs would be tolerant of that -- if a block failed the checksum test,
> > it would reconstruct and remap it. 

> Only if enough redundancy is left. And with the default setup btrfs is only 
> mirroring the metadata not the data.

So can someone please tell me what the current state-of-the-art is of
data protection with btrfs? Does it differ with single-device versus
multiple-device configurations? Is it possible to enable data
checksumming now? Under what conditions? And will it do what a naive
user would expect it to do, namely, correct for diverse kinds of errors
in your storage subsystem? If not, what does it do? Etc...

Any and all information is much appreciated.

Thanks!

Steve

Re: What protection does btrfs checksumming currently give? (Was Re: btrfs volume mounts and dies (was Re: Segfault in btrfsck))

[jim owens]

Steve Freitas wrote:
> Hi all,
> 
> I was under the mistaken impression that btrfs checksumming, in its
> current default configuration, protected your data from bitrot. It
> appears this is not the case:
> 
> On Wed, 2010-01-06 at 18:24 +0100, Johannes Hirte wrote:
>> Am Mittwoch 06 Januar 2010 16:59:55 schrieb Steve Freitas:
>>> So please correct me if I have some mistaken assumptions. I thought
>>> btrfs would be tolerant of that -- if a block failed the checksum test,
>>> it would reconstruct and remap it. 
> 
>> Only if enough redundancy is left. And with the default setup btrfs is only 
>> mirroring the metadata not the data.
> 
> So can someone please tell me what the current state-of-the-art is of
> data protection with btrfs? Does it differ with single-device versus
> multiple-device configurations? Is it possible to enable data
> checksumming now? Under what conditions? And will it do what a naive
> user would expect it to do, namely, correct for diverse kinds of errors
> in your storage subsystem? If not, what does it do? Etc...

First, understand that a checksum only says "this block is good or bad".

The checksum can not be used to "reconstruct" the data.

Checksums are present for all btrfs blocks unless you explicitly shut
them off with mount/ioctl/fcntl options.

To have a good copy you can use as a replacement block, you must
use either btrfs raid1 or raid10.  You can use raid1 with 1 drive,
in a mode called "dup" where both copies are made to that device.

By default with 1 drive, btrfs uses "dup" for metadata and 1 copy
(nodup) for file data blocks. To get file data "dup", you just use
"mkfs.btrfs -d raid1".

If you have btrfs raid, it will find the good block on a read, but
AFAIK we don't have tools yet to automatically reallocate the bad one.

jim

Re: What protection does btrfs checksumming currently give? (Was Re: btrfs volume mounts and dies (was Re: Segfault in btrfsck))

[Johannes Hirte]

Am Donnerstag 07 Januar 2010 20:29:49 schrieb jim owens:
> Steve Freitas wrote:
> > Hi all,
> >
> > I was under the mistaken impression that btrfs checksumming, in its
> > current default configuration, protected your data from bitrot. It
> > appears this is not the case:
> >
> > On Wed, 2010-01-06 at 18:24 +0100, Johannes Hirte wrote:
> >> Am Mittwoch 06 Januar 2010 16:59:55 schrieb Steve Freitas:
> >>> So please correct me if I have some mistaken assumptions. I thought
> >>> btrfs would be tolerant of that -- if a block failed the checksum test,
> >>> it would reconstruct and remap it.
> >>
> >> Only if enough redundancy is left. And with the default setup btrfs is
> >> only mirroring the metadata not the data.
> >
> > So can someone please tell me what the current state-of-the-art is of
> > data protection with btrfs? Does it differ with single-device versus
> > multiple-device configurations? Is it possible to enable data
> > checksumming now? Under what conditions? And will it do what a naive
> > user would expect it to do, namely, correct for diverse kinds of errors
> > in your storage subsystem? If not, what does it do? Etc...
> 
> First, understand that a checksum only says "this block is good or bad".
> 
> The checksum can not be used to "reconstruct" the data.
> 
> Checksums are present for all btrfs blocks unless you explicitly shut
> them off with mount/ioctl/fcntl options.
> 
> To have a good copy you can use as a replacement block, you must
> use either btrfs raid1 or raid10.  You can use raid1 with 1 drive,
> in a mode called "dup" where both copies are made to that device.
> 
> By default with 1 drive, btrfs uses "dup" for metadata and 1 copy
> (nodup) for file data blocks. To get file data "dup", you just use
> "mkfs.btrfs -d raid1".
> 
> If you have btrfs raid, it will find the good block on a read, but
> AFAIK we don't have tools yet to automatically reallocate the bad one.
> 
> jim

Additionally I repeat the suggestion from Sander, check your drive for bad 
blocks. It sounds very likely that your drive is bad and you will get into 
trouble again with the new created FS. And the Oops you've posted smells like 
a bug in btrfs code.

regards,
  Johannes