On Tue, Sep 08, 2009 at 10:32:14PM +0200, Jens Axboe wrote: > On Tue, Sep 08 2009, Markus Trippelsdorf wrote: > > On Tue, Sep 08, 2009 at 10:00:42PM +0200, Jens Axboe wrote: > > > On Mon, Sep 07 2009, Markus Trippelsdorf wrote: > > > > Just got this error today in my dmesg: > > > > btrfs csum failed ino 1483065 off 158482432 csum 4283543305 private > > > > 43905798 > > > > > > > > linux % find . -inum 1483065 > > > > ./.git/objects/pack/pack-f9251bcc6a8afe3c92193e14d1d742f2f0182ce5.pack > > > > > > > > It's the main pack file from my git linux kernel tree: > > > > > > > > > > Hmm, I ran into something very similar. Care to check what the corrupted > > > block of data looks like (and how big it is)? > > > > I've already deleted the file in question unfortunately. > > On IRC Chris decided that either bad RAM or a harddrive error was the > > most likely reason for this chechsum mismatch. > > Darn, that's too bad. The corruption issue I had was also in a git pack > file. It was fine one day, bad the next. Turned out to be 16kb of 0xff > in the file, and I blamed it on the (cheap) SSD drive that hosted the > local git repo. It's still the most likely explanation given the nature > of the problem, however it would have been really interesting to see > what corruption you had.
If by cheap SSD drive you mean an Indilinx Barefoot based one, we might be using the same hardware (30GB Vertex in my case). What a strange coincidence that it affected git pack files in both cases. It's almost too improbable... -- Markus -- 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
