Re: XFS journal log resetting

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com