Hi Subranshu,
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.
You are 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. This is one part. But there can be other file corruption as well
> and these can be handled by xfs_repair.
As Dave mentioned, XFS only journals metadata. Unwritten cached file contents
will not be recovered in this situation.
> 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)
If you are set up correctly, (e.g. write caches are turned off on your disk)
you shouldn't even need to unmount the filesystem an run xfs_repair.
See this section of the xfs faq for more about write caches:
http://www.xfs.org/index.php/XFS_FAQ#Q:_What_is_the_problem_with_the_write_cache_on_journaled_filesystems.3F
> 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.
I can't speak for ext4. I do think that your expectation that fsck/repair be
able to replay a journal is pretty reasonable. That's just not how it is
implemented here. In xfs, log recovery is in the kernel and xfs_repair knows
just enough about the log to avoid clobbering your precious metadata when it
needs to be recovered. There was some discussion in the past about making
xfs_repair able to recover the log but I wouldn't expect that any time soon.
Regards,
Ben
|