Yeah, it's that time of the year again. Jorb's place had a brown-out and associated server restart again, and the filesystem decided to take game data along with it. This is actually very, very unconvincing, and it seems I'll have to investigate if I can really continue using XFS as the filesystem for the game data.
So far, the following data has been found to be missing. I'll keep the list updated as I find out more.
- Hearth secrets are gone and will have to be reentered.
- Charter stones will have to be reactivated.
- Map data is gone for the following areas of tiles (same coordinate system as last time):
- (0, -6000) - (2000, -5000)
- (7000, 7000) - (9000, 8000)
- (7000, -7000) - (7000, -6000)
- (8000, -10000) - (9000, -9000)
- (-4000, -5000) - (-3000, -4000)
- Five houses were internally damaged and rolled back to the backup. Some others may have been left unreachable due to broken references, but I don't quite know how many.
- Village data for the following villages: Steve, Xanadu, Prontera, River Tree Valley, Whatever, River Tree Mine, ItsMine, Barukha, Ironwell, Silent Hill, Mine of Everlook, Crossroads, New Dragon Republic, ZoZo, Null, Tear, River Tree Lake, Farvilla, Mesopotamia, Stonefall, No minerals found and Alcom, and 4 other villages that didn't exist 4 days ago in the backup.
The technical details, for anyone interested, is that I do the traditional procedure for atomic file replacement on Unix whenever I write out any data to disk; that is, I write the data to a new file, and then (once all data has been written successfully) I atomically replace the old file with the new one, with the rename(2) syscall. It seems that XFS' journalling is only keeping the file replacement intact, and not the file data, however (seeing how some files are empty). Ext3 did not have this problem. It might be that XFS only keeps journal of filesystem metadata and not file contents (but even then I'm quite surprised that they haven't made atomic renames work as expected).
