How to make sure that fsck is correcting corruptions while keeping the integrity of file system?
Suppose clients are writing lots of files through NFS to server, and there happens something that caused corruption (dirty shutdown/other kernel panic). So the current state of the filesystem is not known (partial write, etc). Then if we run fsck, it corrects corruptions (e.g. invalid blocks), and the filesystem is now supposed to be up to date. How do I make sure my filesystem *i*s up to date?
In common, I would use diff or dt to check again with the source from which the files were being written. But in this case, let's say that the source is no longer present after writing the files.
Best Answer
Fsck returns your filesystem to a consistent state. This is not necessarily the filesystem's “latest” state, because that state might have been lost in the crash. In fact, if there were half-written files at the time of the crash, then the filesystem was not left in a consistent state, and that is precisely what fsck is designed to repair. In other words, after running fsck, your filesystem is as up-to-date as it can get.
If your application requires feedback as to what is stored on the disk in case of a crash, you'll need to do more work than just writing to a file. You need to call
sync, or betterfsync, after a write operation to ensure that that particular write has been committed to the disk (but if you end up doing this a lot, your performance will drop down, and you'll want to switch to a database engine). You'll need a journaled filesystem configured for maximum crash survival (as opposed to maximum speed).The property that an operation (such as a disk write) that has been performed cannot be undone (even in the event of a system crash) is called durability. It's one of the four fundamental properties of databases (ACID). If you need that property, read up on transactions.
Although filesystems are a kind of database, they're usually not designed to do well with respect to ACID properties: they have more emphasis on flexibility. You'll get better durability from a dedicated database engine. Then consider what happens in case your disk, and not your system crashes: for high durability, you also need replication.