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 0000 |….?..’RPL…..
010: 0000 024d 6163 506f 7274 1233 3455 362e |…MyFile-9.6.
020: 302d 2222 2e35 1ca4 656f 7061 7264 2e64 |0-Leopard.d
030: 6d67 0404 084e 5453 4400 0000 0000 0000 |mg…NTSD…….
040: 0000 0000 0000 0000 0000 0000 0000 0000 |…………….
050: 0000 0000 0000 0000 0000 0000 0000 0000 |…………….
The string to the right of the | and between the … characters can then be used to obtain a file name. Using that file name you can then put humpty dumpty back together. If you have a lot of corruption that cvfsck has fixed then you can have a lot of recompiling and therefore would want to automate the task in a script.