On 3/16/2013 10:56 AM, Subranshu Patel wrote: > This question is related to xfs_repair (recovery) and journalling. > > I powered off (improper shut down) the system when the IO was > undergoing on mounted XFS filesystem. > > Then I tried to recover the inconsistent filesystem using xfs_repair, > after powering on the same machine. The whole point of a journaling filesystem is to recover automatically after an unclean shutdown and put the filesystem in a consistent state. > The XFS filesystem didn’t get recovered which was not expected. This is because you short circuited the automatic recovery process. The journal is replayed and the filesystem made consistent at the next mount after unclean shutdown. You prevented this next mount. > The output displayed by xfs_repair is as follows: > > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > ERROR: The filesystem has valuable metadata changes in a log which needs to > be replayed. Mount the filesystem to replay the log, and unmount it before > re-running xfs_repair. If you are unable to mount the filesystem, then use > the -L option to destroy the log and attempt a repair. > Note that destroying the log may cause corruption -- please attempt a mount > of the filesystem before doing this. XFS is telling you to do what you should have done in the first place: mount the filesystem so it can perform log recovery and make the XFS consistent once again. > The question that arises here is that why xfs_repair should be re-run > after mounting and unmounting the XFS filesystem. According to my > understanding, when we perform mount operation, recovery is > automatically done if the filesystem is in inconsistent state. Then > what is the need of re-running xfs_repair after mount is being > performed? Does xfs_repair recovers something indifferent from the one > recovered on mount? What exactly happens when we mount and unmount XFS > filesystem? No, the question that arises here is why you are intentionally short circuiting the recovery process and immediately trying to run xfs_repair. When a system is configured properly, write barriers or BBWC are working properly, etc, one should never need to run xfs_repair after an unclean shutdown, as recovery is automatic. In fact, in general use, one should rarely, if ever, need to run xfs_repair. I've been using XFS on production servers for a little over 3 years and I've never needed to run xfs_repair, and yes, I've had at least two unclean shutdowns in that time. -- Stan _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
