4

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.

3
  • Title can be read as : How to test "File system correction done by fsck".
    – user4858
    Mar 5, 2011 at 10:16
  • @user4858: I've tried to make your question more readable. I don't understand the expression “in common”. Note that if you want to fix a mistake in your question, you can edit it (just click the “edit” button) — don't leave a comment with a correction to your own post. Mar 5, 2011 at 13:00
  • 2
    Newbie in crusade. I will surely improve.
    – user4858
    Mar 6, 2011 at 7:14

2 Answers 2

3

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 better fsync, 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.

2
  • Gilles - Thanks for the response. Yes, thats exactly what I have read. Real question is - How to make sure or test that -- file system is consistent NOT by just relying on fsck's o/p. Does fsck's success means FS is in good shape, every time? I would like to hear about any methods or tools that validates fsck or likes of it. As KerxPhilo mentioned -N options was good start for me to write a tool to validate data/metadata by making a copy of it before running fsck and then comparing results after fsck.
    – user4858
    Mar 6, 2011 at 7:29
  • If fsck does its job, it brings the filesystem to a consistent state. Are you trying to validate fsck, i.e. make sure it is not buggy? (That's not what I understood from your question, so my answer doesn't address this.) If so, the first step should surely to keep a copy of the pre-fsck filesystem state. Mar 6, 2011 at 11:23
2

-N Don't execute, just show what would be done.

Again, you would just do something along the lines of: shell> fsck -N /dev/sda1

1
  • My reputation is also small as yours. So I cant vote this answer up. -N seems good start for me. Thanks.
    – user4858
    Mar 6, 2011 at 7:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .