On Fri, Dec 10, 2021 at 10:27:11AM -0800, Chanchal Mathew wrote: > Hi > > A question for the developers - > > Is there a reason why a clean unmount on an XFS filesystem would > not reset the log numbers to 0? The xfs_logprint output shows the > head and tail log numbers to have the same number > 0 and as > CLEAN. But the log number is not reset to 0 without running a > xfs_repair -L. Is there a reason it’s not done as part of the > unmount? Yes. Log sequence numbers are a persistent record of when a given metadata object was modified. They are stored in all metadata, not just the log, and are used to determine if the modification in the log found at recovery time is already present in the on-disk metadata or not. Resetting the number back to zero basically breaks this recovery ordering verification, and takes us back to the bad old days of the v4 filesystem format where log recovery could overwrite newer changes in metadata. That could cause data loss and corruption problems when recovering newly allocated inodes and subsequent changes.... > The problem I’m noticing is, the higher the log number, it takes > longer for it to be mounted. Most time seems spent on the > xlog_find_tail() call. The log sequence number has nothign to do with how long xlog_find_tail() takes to run. entirely dependent on the size of the log and time it takes to binary search the journal to find the head. The head then points at the tail, which then gets verified. Once the head and tail are found, the journal contents between the head and tail are CRC checked, and the time this takes is entirely dependent on the distance between the head and tail of the log (i.e. up to 2GB of journal space might get CRC'd here). But at no point do larger LSNs make this take any longer. The upper 32 bits of the LSN is just a cycle number, and it is always interpreted as "past, current, next" by the xlog_find_tail() process no matter what it's magnitude is. i.e. log recvoery only has 3 cycle states it cares about, regardless of how many cycles the log has actually run. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
