On Fri, Feb 26, 2010 at 1:45 AM, Chris Mason <chris.ma...@oracle.com> wrote: > On Thu, Feb 25, 2010 at 10:34:22AM +0100, Leszek Ciesielski wrote: >> (My previous post seems to have been discarded because of the >> attachment size, I'm resending it without the dmesg output - which can >> be found @ http://pastebin.com/T0J3z59j ) >> >> Hi, >> >> yesterday I updated my kernel (clean clone from >> mason/btrfs-unstable.gi), pulling in the single latest change I have >> been missing ( >> http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commit;h=3f6fae9559225741c91f1320090b285da1413290 >> ) and adding my patch from http://patchwork.kernel.org/patch/81547/ . >> Previous kernel version (without my patch - could this be my fault?) >> has been running fine for 14 days, but after recompiling and >> rebooting, my dmesg output is full of "btrfs no csum found for inode >> 386 start 0" and "btrfs csum failed ino 386 extent 65191274496 csum >> 1851253866 wanted 0 mirror 1" and "btrfs csum failed ino 82619 off >> 8749056 csum 2686054019 private 0", > > Yes, but did you verify your data?
Part of the data stored on the volume consisted of video recordings - after copying out and back onto the volume, they play back fine, without video or audio glitches. Which I am aware does not mean they are intact, just "good enough to work". I had also some important data there, which is backed up to another location - I will verify it's integrity with rsync during the weekend. > > I don't think your patch alone could have caused this. Has anything > else strange been happening on this machine? Not really. The FS was created with metadata=mirror data=mirror on a single drive, then a second (larger) drive was added and the fs was rebalanced. Compression is enabled. No problems until the last kernel update. After the recovery - no new csum failures. > > The fact that all your files are wrong is especially strange. Have you > ever mounted this FS with mount -o nodatasum? Only once, after the problem occured - yesterday, when I was trying to copy the data out. Only read access was performed (although the fs was mounted rw). Regards, Leszek 'skolima' Ciesielski -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html