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
rb_node cannot be an ERR_PTR() here. Both implimentations of __tree_search()
return either a valid pointer or NULL.
It doesn't make a runtime difference but without this patch smatch thinks that
lookup_extent_mapping() can return an ERR_PTR(). It can wait until 2.6.34
obviously.
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
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
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
One of my btrfs filesystems gives the following bug message on access:
Jan 6 23:08:12 datengrab kernel: [ cut here ]
Jan 6 23:08:12 datengrab kernel: kernel BUG at include/linux/spinlock.h:376!
Jan 6 23:08:12 datengrab kernel: invalid opcode: [#1] SMP
Jan 6
