rattrs: Replaced LFS3_tag_TAIL with single-recurse LFS3_tag_RATTRS

This originally started as an attempt to drop LFS3_tag_TAIL entirely,
but that didn't really go anywhere. Any attempt to work around the
double rattr-lists during mtree splits results in more mess than this
magic rattr.

But I did notice we only need to support "simple" rattrs during mtree
splits, which means we can just call lfs3_rbyd_appendrattrs to handle
these.

Maybe this will be problematic if we ever want to deduplicate
lfs3_mdir_commit___ and lfs3_rbyd_appendrattrs, but I don't see that
happening because of the different concerns (mdir-specific rattrs):

 function                code  stack  ctx
 lfs3_mdir_commit___     1052    744  396
 lfs3_rbyd_appendrattrs   142    584  388

The benefit of a single-recurse LFS3_tag_RATTRS:

- Simplifies lfs3_mdir_commit__, no more awkward loop recursion.

- May have other use cases for nesting simple rattrs?

Adds a bit of code:

                 code          stack          ctx
  before:       35316           2176          660
  after:        35320 (+0.0%)   2176 (+0.0%)  660 (+0.0%)

                 code          stack          ctx
  gbmap before: 38148           2192          772
  gbmap after:  38172 (+0.1%)   2192 (+0.0%)  772 (+0.0%)
This commit is contained in:
Christopher Haster
2025-11-30 00:24:23 -06:00
parent ce6cbc3c77
commit 8db3ce342c
2 changed files with 17 additions and 15 deletions
+1 -1
View File
@@ -829,7 +829,7 @@ enum lfs3_tag {
// in-device only tags, these should never get written to disk
LFS3_tag_INTERNAL = 0x0000,
LFS3_tag_TAIL = 0x0001,
LFS3_tag_RATTRS = 0x0001,
LFS3_tag_SHRUBCOMMIT = 0x0002,
LFS3_tag_GRMPUSH = 0x0003,
LFS3_tag_MOVE = 0x0004,