On Thu, Sep 17 2009, Markus Trippelsdorf wrote: > On Thu, Sep 17, 2009 at 08:44:56AM +0200, Jens Axboe wrote: > > On Thu, Sep 17 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 hit the same problem again today: > > > > > > btrfs csum failed ino 1826333 off 150208512 csum 4148434891 private 1660028275 > > > > > > The file in question is: > > > ./.git/objects/pack/pack-a2330b703d5a7fd62626b39a5fdfb6eecf739d0d.pack > > > > > > I can't read the file directly, because of the csum mismatch: > > > > Chris, is there a way to force reading the file? Seems like that would > > be a very handy feature. > > > > Markus, not sure if that works, but you could always try and remount > > with data checksumming disabled. > > > > mount /dev/fooX -o remount,rw,nodatasum > > > > should do the trick. > > That doesn't work unfortunately, btrfs still calculates and compares the > checksums (it won't write new ones I guess). Ah ok, as mentioned I wasn't sure whether that would work or not. I'll defer to Chris :-) -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
