Hi, > So realistically both disk blocks are wrong and there's a window until > the new, correct block is written. That window will only cause problems > if there is a crash and we'll need to recover. My main concern here is > how big the discrepancy between the disks can get, and whether we'll end > up corrupting the filesystem during recovery because we could > potentially be matching metadata from one disk with journal entries from > another. well, I know already people will not believe me, but just this evening, one of the infamous PCs with mismatch count going up and down, could not boot anymore. Reason: you must specifiy the filesystem type So, I started it with a live CD. My first idea was a problem with the RAID (type is 10 f2). This was assembled fine, so I tried to mount it, but mount returned the same error as above. So I tried to mount it specifying "-text3" and it was mounted. Everything seemed to be fine, I backup the data anyhow. Some interesting discoveries: tune2fs -l /dev/md/2_0 returns the FS data, no errors. blkid /dev/md/2_0 does not return anything. Running a fsck did not find anything wrong, but it did not repair anything too. Now, I do not know if this was caused by the situation mentioned above, but for sure is quite fishy... BTW, unrelated to the topic, any idea on how to fix this? Is there any tool that can restore the proper ID or else? Thanks, bye. -- piergiorgio -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
