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. Correct. > 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 > writes. 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 corruption.... > 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 on disk. 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 > checks/recovery. > 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. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
