On Fri, Feb 26, 2010 at 5:19 PM, Chris Mason <chris.ma...@oracle.com> wrote: > On Fri, Feb 26, 2010 at 11:51:35AM +0100, Leszek Ciesielski wrote: >> 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. > > Ok, what does btrfsck say about the FS now? > > -chris >
49MB of errors, 3.5MB compressed file. So I guess it's not too good ;-) Log uploaded here: http://cid-3e1bf92365ec19a2.skydrive.live.com/self.aspx/.Public/btrfscfk.txt.gz -- 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
