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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
