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:
@@ -103,7 +103,7 @@ code = '''
|
||||
defines.N = [0, 1, 2, 3, 4]
|
||||
defines.SIZE = 'N*FRAGMENT_SIZE'
|
||||
# force a btree node
|
||||
defines.SHRUB_SIZE = 0
|
||||
defines.INLINE_SIZE = 0
|
||||
defines.CRYSTAL_THRESH = -1
|
||||
defines.SYNC = [false, true]
|
||||
in = 'lfs.c'
|
||||
@@ -487,7 +487,7 @@ defines.N = [0, 1, 2, 3, 4]
|
||||
defines.SIZE = 'N*FRAGMENT_SIZE'
|
||||
defines.CHUNK = [32, 8, 1]
|
||||
# force a btree node
|
||||
defines.SHRUB_SIZE = 0
|
||||
defines.INLINE_SIZE = 0
|
||||
defines.CRYSTAL_THRESH = -1
|
||||
defines.SYNC = [false, true]
|
||||
defines.REMOUNT = [false, true]
|
||||
|
||||
Reference in New Issue
Block a user