On 3/17/2013 6:42 AM, 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
> 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
> Correct me if I am wrong.
Enough with the foreplay. Get to your point please. I'm assuming you
think you have an exception, a bug, to report.
> On Sun, Mar 17, 2013 at 10:56 AM, Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
>> 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.
> xfs mailing list