tag name | log-recovery-defer-capture-5.16_2021-09-23 (1c501f081c98eb7e17e8f9af48183d38a81a797e) |
tag date | 2021-09-23 18:20:41 -0700 |
tagged by | Darrick J. Wong <djwong@kernel.org> |
tagged object | commit 8cbebb7265... |
xfs: refactor log recovery resource capture
During review of Allison's logged xattrs patchset last cycle, I noticed
that there was an opportunity to clean up some code structure
differences between how regular runtime deferred attributes hold on to
resources across a transaction roll, and how it's done during log
recovery. This series, in cleaning that up, should shorten her
patchset and simplify it a bit.
During regular operation, transactions are allowed to hold up to two
inodes and two buffers across a transaction roll to finish deferred log
items. This implies that log recovery of a log intent item ought to be
able to do the same. However, current log recovery code open-codes
saving only a single inode, because that was all that was required.
With atomic extent swapping and logged extended attributes upon us, it
has become evident that we need to use the same runtime mechanisms
during recovery. Refactor the deferred ops code to use the same
resource capture mechanisms for both.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmFNJ+kACgkQ+H93GTRK
tOsP2w/8De045UfT7ufBX54qg36xpmd7TRkbG/OYph4GC/pxZp5shlqv6NCHUWGV
jzxYqi41Fs6KLJWK0x+1/ybIQIPFK5WXAQraJ0OnAzVCBmzUGeI4PFm+7bklrOhn
M28OEzRwXzWXBbQEhSU8MU3eZ+Gdg0QnRc8ZLBh2R8BiQVqqI0UpLMcTrOYwRoOe
sKAnjLJ6XK2S2/zs9fjb0JAa4qhYKuCKyLs+mbknjB3SSxqAimFQbPm3eSKPs6ys
6y6W03fyTgW8rXCd7N61dQadAN/d3+flyb+7LXt6zFCEwgXa2ui47qnLAqhxL4Bc
auf9mxEeS77J7hb0M31JamOmR8Dc0Ekbi0c7Gq0UfCB64W1/7jDnRHHlkEqSj7S+
tcOwjsvI+LDfAJtF6U1De4TJWMjb9FCA8LNPfAn+UmgLFIrRS/thGqdYplcB9grj
06qpGwV4enchHtNLtDg3NH1Xfqh+QsKgyyLKerdfi+XHmIf4HIKjem5YXAtH/oSv
oIZQMg8Sj7mhBzwsBrZiwaSLtaMSifWpMWm7NNgp+/Zcf5pG3hdtj3m7MZY1yf+b
AZCUdMZXNmuzWo9Zot5aunUpXEdNzclXr7w8mQ+Ycz2tLkpp0OVUAQ1OalqUwuyb
k5ZOuBbBz+TCzdpKK6Sw/uEdwFwIQay7XPgwzR3jLeT5CCYnCuk=
=8Ppp
-----END PGP SIGNATURE-----