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 writes. This is one part. But there can be other file corruption as well and these can be handled by xfs_repair.
So the crux is to mount the filesystem so that journal will be replayed, and then unmount the filesystem and run xfs_repair. (Assuming xfs_repair may not be a mandatory step always)
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.
On Sun, Mar 17, 2013 at 10:56 AM, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> wrote:
>
> On 3/16/2013 10:56 AM, Subranshu Patel wrote:
>
> > This is not observed in EXT4, fsck successfully recovers without
> > mounting the filesystem.
>
> And this is the real problem. You're *assuming* XFS should behave in
> the same manner as EXT4. Why would you assume a Ferrari should behave
> like a Tata Nano?
>
> XFS is far more sophisticated than EXT4 in many, many ways, including
> recovery after unclean shutdown. XFS kernel code performs journal
> playback/recovery automatically when the filesystem is mounted.
> xfs_repair is a tool for fixing filesystems that are broken, not simply
> in need of journal playback. Thus xfs_repair has no code to perform
> journal recovery.
>
> EXT4 (and EXT3) lacks this sophistication and must call a user space
> tool, e2fsck, to perform journal playback/recovery.
>
> XFS is the Ferrari of Linux filesystems and EXT is the Tata. Keep that
> in mind as you discover many of the other differences in the future.
>
> --
> Stan
>
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
