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? > > > > 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. -chris -- 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
