On Sun, Mar 17, 2013 at 05:12:36PM +0530, Subranshu Patel wrote:
> What I understand is that, XFS being a journalling filesystem makes running
> xfs_repair after a unclean unmount unnecessary.
> After a system crash or force power down, one can mount the filesystem
> which causes the journal to be replayed and handles the half finished
What "half finished writes"? The journal replays only completely
written checkpoints. It tosses away half written writes because they
are not complete and so replaying them will result in filesystem
> This is one part. But there can be other file corruption as well
> and these can be handled by xfs_repair.
I think you don't understand how OS level writeback caching works.
You will *lose* data on a power failure unless the application
spcifically writes it to disk with fdatasync/fsync(). This has
nothing to do with the filesystem, nor journal replay. If the
application uses fsync, then the data on disk is consistent with
what is in the journal, so after journal replay, the data is there
xfs_reapir is not full of magic pixie dust that miraculously
recovers data that was never written to disk....
> In case of EXT4, journal will not be replayed on performing mount. One need
> to invoke fsck which performs journal playback and then other corruption
> Correct me if I am wrong.
ext4 behaves like this, but your basic assumption that fsck.ext4
performs data recovery/repair is wrong, same as for your assumption
that xfs_repair does this for XFS.