2009/11/12 Chris Mason <chris.mason@xxxxxxxxxx>: > On Thu, Nov 12, 2009 at 05:16:34PM +0300, Alexander Beregalov wrote: >> 2009/11/12 Chris Mason <chris.mason@xxxxxxxxxx>: >> > On Thu, Nov 12, 2009 at 05:08:53AM +0300, Alexander Beregalov wrote: >> >> # for i in `seq 1 20`; do btrfsck /dev/sde|grep "checksum verify >> >> failed";echo; done >> >> checksum verify failed on 31945617408 wanted 6607632D found 9CC3ED0 >> >> checksum verify failed on 31945617408 wanted 6607632D found AFBBF41 >> > >> > Was your filesystem mounted at the time? It's strange that the checksum >> > keeps changing, that points to the data in the block changing. >> >> It was not. >> Any tips how I can try to find a root cause? >> It is raid0 of two disks. > > Well, I'd start by looking for anything else that could be touching the > FS or the devices. You shouldn't see more than two different csums in this > configuration (one from each disk). I always see only these two blocks in output. > > Somehow the disk is giving us different answers each time, which points > to a problem in the storage stack. Hm, I will try to check discs by "badblocks" with few cycles of write-read. > > Otherwise it is possible that block 31945617408 is multiply linked and > is actually in use somehow else. btrfsck is a readonly operation > though, it doesn't change the FS while it is running. Can it be a bug in the filesystem itself - in checksum calculation code, wrong pointer to data or something else? -- 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
