Renamed lfs->cfg->shrub_size -> lfs->cfg->inline_size

While I think shrub_size is probably the more correct name at a
technical level, inline_size is probably more what users expect and
doesn't require a deeper understanding of filesystem details.

The only risk is that users may think inline_size has no effect on large
files, when in fact it still controls how much of the btree root can be
inlined.

There's also the point that sticking with inline_size maintains
compatibility with both the upstream version and any future version that
has other file representations.

May revisit this, but renaming to lfs->cfg->inline_size for now.
This commit is contained in:
Christopher Haster
2025-02-07 01:35:22 -06:00
parent 6cd29bede2
commit bac2464b8f
8 changed files with 30 additions and 30 deletions
+3 -3
View File
@@ -128,7 +128,7 @@ defines.POWERLOSS_BEHAVIOR = [
]
defines.MKCONSISTENT = [false, true]
# inlining has a tendency to hide sync issues, so try without
defines.SHRUB_SIZE = ['BLOCK_SIZE/4', '0']
defines.INLINE_SIZE = ['BLOCK_SIZE/4', '0']
defines.N = [1, 2, 4, 8, 16, 32, 64]
defines.SIZE = [
'0',
@@ -228,7 +228,7 @@ defines.POWERLOSS_BEHAVIOR = [
]
defines.MKCONSISTENT = [false, true]
# inlining has a tendency to hide sync issues, so try without
defines.SHRUB_SIZE = ['BLOCK_SIZE/4', '0']
defines.INLINE_SIZE = ['BLOCK_SIZE/4', '0']
defines.N = [1, 2, 4, 8, 16, 32, 64]
defines.OPS = 256
defines.SIZE = [
@@ -458,7 +458,7 @@ defines.POWERLOSS_BEHAVIOR = [
]
defines.MKCONSISTENT = [false, true]
# inlining has a tendency to hide sync issues, so try without
defines.SHRUB_SIZE = ['BLOCK_SIZE/4', '0']
defines.INLINE_SIZE = ['BLOCK_SIZE/4', '0']
# note dirs x files grows O(n^2)
defines.N = [1, 2, 4, 8]
defines.M = 'N'