I’ve noticed a couple of occasions where data corruption in Xsan causes a perceived data loss on a volume. This does not always mean that you have to restore from backup. Given the cvfsck output, you can isolate the iNodes using the following: cat cvfsck.txt | grep *Error* | cut -c 27-36 > iNodeList.txt Once isolated you can then use the cvfsdb tool to correlate this to file names. For example, if you have an iNode of 0x20643c8 then you can convert this into a file name using the following: cvfsdb> show inode 0x20643c8 The output will be similar to the following: 000: 0100 8000 3f04 0327 5250 2daa 0000…
-
-
Xsan: Corruption
Volumes can become corrupt no matter what file system you are talking about (er, there might a magical file system out there that cannot become corrupted but I’ve never heard of it and would like to sell a certain bridge to you if you have). Xsan is no different and so you need to be ready to use the command line to combat said corruption. fsck is the traditional *nix tool to fix issues with volume corruption. cvfsck is the weird cousin that’s used for Xsan. If you see any iNode errors in your logs, corruption errors, high latency or just too many weird issues to shake a stick at…