On Fri, May 10, 2024 at 05:34:26PM -0700, Wengang Wang wrote:
> when writting super block to disk (in xfs_log_sb), sb_fdblocks is fetched from
> m_fdblocks without any lock. As m_fdblocks can experience a positive -> negativ
> -> positive changing when the FS reaches fullness (see xfs_mod_fdblocks)
> So there is a chance that sb_fdblocks is negative, and because sb_fdblocks is
> type of unsigned long long, it reads super big. And sb_fdblocks being bigger
> than sb_dblocks is a problem during log recovery, xfs_validate_sb_write()
> complains.
>
> Fix:
> As sb_fdblocks will be re-calculated during mount when lazysbcount is enabled,
> We just need to make xfs_validate_sb_write() happy -- make sure sb_fdblocks is
> not genative.
Ok, I have no problems with the change being made, but I'm unclear
on why we care if these values get logged as large positive numbers?
The comment above this code explains that these counts are known to
be inaccurate and so are not trusted. i.e. they will be corrected
post-log recovery if they are recovered from the log:
* Lazy sb counters don't update the in-core superblock so do that now.
* If this is at unmount, the counters will be exactly correct, but at
* any other time they will only be ballpark correct because of
* reservations that have been taken out percpu counters. If we have an
* unclean shutdown, this will be corrected by log recovery rebuilding
* the counters from the AGF block counts.
IOWs journal recovery doesn't actually care what these values are,
so what actually goes wrong if this sum returns a negative value?
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
