Xfs_repair and journalling

[Subranshu Patel]

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 at hardwarefreak.com>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20130317/01d4530d/attachment-0001.html>