WSL 挂载盘踩坑复盘：为什么 LanceDB 在 DrvFs 上会触发 metadata ENOENT，而 ext4 正常1. 背景 在 StaticFlow 的图片入库流程中，我们使用 sf-cli write-images 把图片写入 LanceDB 的 images 表。数据库目录最初放在 WSL 挂载盘：/mnt/e/static-flow-data/lancedb（对应 Windows NTFS，通过 DrvFs 暴露给 WSL） 问题表现是：小图通常写入成功大图（触发 multipart/staged upload）偶发或稳定失败失败日志核心是：Unable to access metadata for ...lance#1: No such file or directory 同样的数据、同样的命令，把 DB 目录切到 WSL 原生 ext4（例如 /home/...）后，写入成功率恢复正常。2. 事故现象（Symptoms） 典型错误（精简后）：LanceError(IO): External error: Unable to access metadata for .../images.lance/data/<uuid>.lance#1: No such file or directory 关键特征：报错路径带 #1 后缀（staged upload 临时文件特征）小文件较少触发，大文件更易触发同命令在 ext4 路径可复现“从失败变成功”3. 根因结论（Root Cause）3.1 根因不是业务逻辑，而是文件系统语义差异 这次问题的本质是：Lance / object_store 在本地对象写入时会走 staged upload（临时文件 -> rename -> metadata/finalize）在 WSL 的 DrvFs（/mnt/*）上，这条链路与 Linux 原生 POSIX 语义并不完全等价结果是某些阶段出现 ENOENT（尤其是带 #suffix 的 staged 文件） 即：数据库引擎假设的“类 POSIX 原子行为”与 DrvFs 的实现细节存在缝隙。3.2 代码链路证据 从依赖代码可以看到关键点：Lance IO 对大对象写入会进入 multipart/staged 流程（阈值约 5MB）本地 object store staged 上传会创建 dest#<n> 的临时对象完成阶段会执行 rename/finalize，并继续 metadata 相关操作在 DrvFs 上该链路出现 metadata ENOENT 可对应到依赖实现中的关键位置（版本以本地 lock 为准）：lance-io 的 object writer 初始分段阈值为 5MB（INITIAL_UPLOAD_STEP）object_store::local 的 staged 上传会创建 目标文件名 + #后缀 的临时对象完成阶段会做 rename(src, dest) 和后续 metadata/finalize现场报错路径恰好是 staged 临时对象：.../data/<id>.lance#1 这与我们现场现象完全对齐：“大图更容易失败” <- 因为更容易触发 staged/multipart“路径里出现 #1” <- staged 本地临时对象命名3.3 失败时序图（简化）sequenceDiagram participant CLI as sf-cli participant Lance as Lance/ObjectStore participant FS as Filesystem CLI->>Lance: write-images(large file) Lance->>FS: create staged object: file.lance#1 Lance->>FS: write chunks Lance->>FS: finalize: rename(file.lance#1 -> file.lance) Lance->>FS: metadata/final checks FS-->>Lance: ENOENT (DrvFs edge case) Lance-->>CLI: IO error: Unable to access metadata ...#1 3.4 为什么 ext4 正常 ext4 是 Linux 原生文件系统，和 Rust/Lance 依赖栈（tokio + object_store + lance）默认假设的语义更一致：rename / inode / metadata 行为更稳定对“先写临时文件再提交”的数据库工作负载兼容性更高 所以同样命令迁移到 ext4 后可稳定成功。4. Dr…