On Mon, Nov 01, 2010 at 12:02:10PM CET, cwillu wrote:
Ahhh, and that makes this make sense:
Andreas, have you checked which file(s) are giving the errors? if
not, you can use find /whatever/mountpoint -xdev -inum 5098 -print
to get the filename. And I would bet that it's small enough
To follow up on this matter, I have created another two btrfs volumes (also
plain - no options - also on two external USB-SATA disks), and am at the moment
copying heaps of data between these two. No errors as of yet. All copies are
verified by md5sum after the deed.
The volume in question can
On 1 November 2010 00:35, Andreas Bauer a...@voltage.de wrote:
So I conclude that these messages are faulty because data is read correctly.
In addition, when you have more than one btrfs you cannot see from the
message
which fs it is refering to.
Is this a raid1 or a dup array?
No,
On Mon, Nov 1, 2010 at 4:55 AM, Daniel J Blueman
daniel.blue...@gmail.com wrote:
On 1 November 2010 00:35, Andreas Bauer a...@voltage.de wrote:
So I conclude that these messages are faulty because data is read correctly.
In addition, when you have more than one btrfs you cannot see from the
Hi everybody,
Today while playing around with btrfs I uncovered what must be a bug in the
btrfs checksum code. My kernel log received a couple of these messages with
various ino and off numbers:
btrfs csum failed ino 5098 off 524288 csum 2981133980 private 959545494
[..]
This happens on
Today while playing around with btrfs I uncovered what must be a bug in the
btrfs checksum code. My kernel log received a couple of these messages with
various ino and off numbers:
btrfs csum failed ino 5098 off 524288 csum 2981133980 private 959545494
[..]
This happens on reading from
