On Mon, Jun 05, 2023 at 08:36:06AM -0700, Darrick J. Wong wrote: > Hi all, > > This series fixes numerous flag handling bugs in the rmapbt key code. > The most serious transgression is that key comparisons completely strip > out all flag bits from rm_offset, including the ones that participate in > record lookups. The second problem is that for years we've been letting > the unwritten flag (which is an attribute of a specific record and not > part of the record key) escape from leaf records into key records. > > The solution to the second problem is to filter attribute flags when > creating keys from records, and the solution to the first problem is to > preserve *only* the flags used for key lookups. The ATTR and BMBT flags > are a part of the lookup key, and the UNWRITTEN flag is a record > attribute. > > This has worked for years without generating user complaints because > ATTR and BMBT extents cannot be shared, so key comparisons succeed > solely on rm_startblock. Only file data fork extents can be shared, and > those records never set any of the three flag bits, so comparisons that > dig into rm_owner and rm_offset work just fine. > > A filesystem written with an unpatched kernel and mounted on a patched > kernel will work correctly because the ATTR/BMBT flags have been > conveyed into keys correctly all along, and we still ignore the > UNWRITTEN flag in any key record. This was what doomed my previous > attempt to correct this problem in 2019. > > A filesystem written with a patched kernel and mounted on an unpatched > kernel will also work correctly because unpatched kernels ignore all > flags. > > With this patchset applied, the scrub code gains the ability to detect > rmap btrees with incorrectly set attr and bmbt flags in the key records. > After three years of testing, I haven't encountered any problems. > Online scrub is amended to recommend rebuilding of rmap btrees with the > unwritten flag set in key records. > > The xfsprogs counterpart to this series amends xfs_repair to report key > records with the unwritten flag bit set, just prior to rebuilding the > rmapbt. It also exposes the bit via xfs_db to enable testing back and > forth. > > If you're going to start using this mess, you probably ought to just > pull from my git trees, which are linked below. > > This is an extraordinary way to destroy everything. Enjoy! > Comments and questions are, as always, welcome. Looks good, will test: Reviewed-by: Carlos Maiolino <cmaiolino@xxxxxxxxxx> > > --D > > kernel git tree: > https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=rmap-btree-fix-key-handling > > xfsprogs git tree: > https://git.kernel.org/cgit/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=rmap-btree-fix-key-handling > --- > db/btblock.c | 4 ++++ > repair/scan.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 63 insertions(+), 1 deletion(-) >
