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:
@@ -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'
|
||||
|
||||
Reference in New Issue
Block a user