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).

-- 
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

Reply via email to