2009/11/12 Chris Mason <chris.mason@xxxxxxxxxx>: > On Thu, Nov 12, 2009 at 06:43:00PM +0300, Alexander Beregalov wrote: >> 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. > > The wanted is always the same but the found is always different? Yes, exactly. The bits marked as X look as random. > >> > >> > 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? > > We can check, I'll make a program to map a logical block number to the > physical sector. Ok, thanks, I will not reboot it. -- 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
