现状
kvspaceShmOpen(path, data_size) 在创建时用固定 data_size 决定容量：
data_size 一次性算出 shm_total（kvspace_hdr + blocks_meta + ART_SLAB + sbo_head + data_size），ftruncate 到该大小，单次 mmap 整块映射。- 再次打开已存在的文件时，
data_size 直接从头部 sbo_data_size 读回——沿用创建时的容量，不可更改。
- 底层
slotsboxmalloc 变长区（sbo_data）与 ART slab 均在这块固定映射内分配。
即：容量在 shm 创建时锁死，运行期无扩容/缩容路径。写入超过初始容量只能失败或需要用户预先按峰值超额分配。
问题
这是方案 2（tensor.data 由 extstore 后端管理，见 #14）目前无法直接落到 shm 上的根因之一：tensor data 体量动态且可达 GB 级，固定容量的 shm 无法在运行期按需扩张。
需要设计
运行期动态扩缩容，候选方向（待定档）：
- 扩容：
ftruncate 增大 backing file + mremap（Linux）重新映射；多进程共享场景下如何让所有 attach 方感知新映射基址/大小（版本号 + 重映射握手，或固定虚拟地址预留 + 按需 mmap 提交）。
- 缩容：
slotsboxmalloc 空闲区回收 + fallocate(PUNCH_HOLE) 释放物理页，或整理后 ftruncate 收缩。
- 地址稳定性：ART 节点与 slotsbox 存的是 offset 而非指针（利于重映射），需确认所有跨进程引用都是 offset-based、不缓存裸指针。
- 并发：扩缩容期间的读写栅栏 / 版本切换，避免撕裂。
交付
先出设计文档（元存 + 扩展存储两层各自的扩缩容策略），再实现。解决后回填 #14 的方案 2 可行性判断。
现状
kvspaceShmOpen(path, data_size)在创建时用固定data_size决定容量：data_size一次性算出shm_total（kvspace_hdr + blocks_meta + ART_SLAB + sbo_head + data_size），ftruncate到该大小，单次mmap整块映射。data_size直接从头部sbo_data_size读回——沿用创建时的容量，不可更改。slotsboxmalloc变长区（sbo_data）与 ART slab 均在这块固定映射内分配。即：容量在 shm 创建时锁死，运行期无扩容/缩容路径。写入超过初始容量只能失败或需要用户预先按峰值超额分配。
问题
这是方案 2（tensor.data 由 extstore 后端管理，见 #14）目前无法直接落到 shm 上的根因之一：tensor data 体量动态且可达 GB 级，固定容量的 shm 无法在运行期按需扩张。
需要设计
运行期动态扩缩容，候选方向（待定档）：
ftruncate增大 backing file +mremap（Linux）重新映射；多进程共享场景下如何让所有 attach 方感知新映射基址/大小（版本号 + 重映射握手，或固定虚拟地址预留 + 按需mmap提交）。slotsboxmalloc空闲区回收 +fallocate(PUNCH_HOLE)释放物理页，或整理后ftruncate收缩。交付
先出设计文档（元存 + 扩展存储两层各自的扩缩容策略），再实现。解决后回填 #14 的方案 2 可行性判断。