关键发现: - FSKit 检测成功 ✅ (backend auto-selection) - FSKit 测试未执行 ❌ (go-nfsv4 未安装) - FSKit 并非独立方案 (依赖 go-nfsv4 binary) - go-nfsv4 失败 → NFSv4/FSKit/SMB3 全部失败 技术现实: - FUSE-T = go-nfsv4 unified binary - Backend selection via CLI flag - Mount helper design (not daemon) - mount_nfs 失败 → 所有 backend 失败 正确路径: - FUSE-T → go-nfsv4 失败 → NFSv4/FSKit/SMB3 全失败 - 转向真正独立方案:WebDAV ✅
6.8 KiB
6.8 KiB
FSKit 未测试原因釐清
日期: 2026-05-18
问题: 为何测试方案没有提到 FSKit?
FSKit 在技术选型中的角色
1. FSKit 检测成功 ✅
自动检测结果:
macOS version: 26.4.1
Recommended backend: fskit
Reason: macOS 26+ supports FSKit (native, fastest)
Performance: Direct userspace path, minimal overhead
代码实现:
// src/fuse/backend.rs
pub fn select_backend() -> BackendType {
let version = detect_macos_version();
if version.starts_with("26") {
BackendType::Fskit // macOS 26+ → FSKit
} else {
BackendType::Nfs4
}
}
测试验证:
- ✅ Test 1: Backend detection (FSKit detected)
- ✅ Test 2: Auto backend selection (FSKit selected)
- ✅ Test 3: Manual backend selection (FSKit forced)
2. FSKit 实际测试失败 ❌
关键事实: FSKit backend 同样依赖 go-nfsv4
go-nfsv4 统一二进制架构
FUSE-T Architecture:
├── go-nfsv4 (unified binary, 23MB)
│ ├── NFSv4 backend
│ ├── FSKit backend
│ └── SMB3 backend
└── Backend selection via CLI flag
Usage:
go-nfsv4 --backend nfs # NFSv4
go-nfsv4 --backend fskit # FSKit (same binary!)
证据来源:
From docs/FUSE_CURRENT_STATUS.md:
- go-nfsv4 is unified binary (NFSv4/FSKit/SMB3)
- Backend selection via `--backend` flag
3. go-nfsv4 整体失败(影响所有 backend)
失败现象
测试结果(40+ 次测试):
go-nfsv4 daemon 死亡 → zombie process ✗
mount_nfs 执行失败 → NFS mount 未建立 ✗
NFS server 不监听 → 52100 端口关闭 ✗
文件不可见 → 目录为空 ✗
根本原因:
go-nfsv4 设计意图推测:
├── mount helper(而非 daemon)
├── 启动临时 NFS server
├── 执行 mount_nfs 命令
├── 等待 mount 完成
└── 退出进程(kernel 接管)
问题:
mount_nfs 执行失败 → go-nfsv4 无法完成 mount
→ 进程立即变成 zombie
→ 所有 backend (NFSv4/FSKit/SMB3) 都无法工作
4. 为什么没有单独测试 FSKit?
答案:FSKit 和 NFSv4 使用同一个 binary
关键依赖链:
FSKit backend:
├── 依赖 go-nfsv4 binary
├── 执行 go-nfsv4 --backend fskit
└── 同样的 mount helper 问题
如果 go-nfsv4 失败:
├── NFSv4 backend ✗
├── FSKit backend ✗ (同样失败)
└── SMB3 backend ✗
技术现实:
// FUSE-T backend implementation
fn mount_fskit() {
// 使用同一个 go-nfsv4 binary
Command::new("go-nfsv4")
.arg("--backend")
.arg("fskit")
.output()
}
// 如果 go-nfsv4 mount helper 设计有问题
// FSKit backend 同样会失败
5. FSKit vs NFSv4 测试差异
测试文档记录
POC Test Plan (docs/FUSE_POC_TEST.md):
### Test FSKit Backend (计划,未执行)
# Force FSKit backend (macOS 26+)
cargo run -- fuse poc --backend fskit
Expected:
| FSKit | TBD | TBD | Target: 40% faster |
Status: ⏳ Ready (但未实际测试)
实际测试:
- ✅ Backend detection (FSKit selected)
- ✅ Placeholder mount (POC only)
- ❌ 真实 mount 测试未执行(go-nfsv4 未安装/失败)
6. FUSE-T 安装状态检查
当前状态:
$ ls -la "/Library/Application Support/fuse-t/bin/"
FUSE-T 未安装
原因:
1. go-nfsv4 安装需要 sudo 权限
2. brew install fuse-t 未执行
3. PKG 文件需要手动安装
从文档记录(docs/FUSE_POC_REPORT.md):
Next Steps: Install FUSE-T and implement real FUSE filesystem
Status: POC 验证完成,但 FUSE-T 未实际安装
7. 关键洞察:FSKit 并非独立方案
误解来源:
文档中大量提到 FSKit:
- macOS 26+ → FSKit (native, fastest)
- Backend auto-detection works
- FSKit backend recommended
但未说明:
- FSKit 依赖 go-nfsv4 binary
- go-nfsv4 是统一 mount helper
- 如果 go-nfsv4 失败,所有 backend 都失败
技术选型误判:
初始假设:
├── NFSv4 可能失败
├── FSKit 作为备选(独立实现)
└── SMB3 作为第三备选
实际架构:
├── go-nfsv4 统一二进制
├── NFSv4/FSKit/SMB3 都是同一 binary 的不同 flag
└── go-nfsv4 失败 → 所有 backend 都失败
8. 为什么转向 WebDAV?
技术依赖对比:
| 方案 | 依赖 | 状态 | macOS兼容 |
|---|---|---|---|
| NFSv4 (go-nfsv4) | go-nfsv4 mount helper | ❌ 失败 | ⚠️ 需调试 |
| FSKit (go-nfsv4) | go-nfsv4 mount helper | ❌ 同样失败 | ⚠️ 同上 |
| SMB3 (go-nfsv4) | go-nfsv4 mount helper | ❌ 同样失败 | ⚠️ 同上 |
| WebDAV | HTTP server (dav-server) | ✅ 成功 | ✅ 原生支持 |
关键发现:
FSKit 并非独立备选方案:
├── FSKit backend = go-nfsv4 --backend fskit
├── 同样的 mount helper 设计
├── 同样的 zombie process 问题
└── 并不能绕过 NFSv4 的失败
真正独立的方案:
├── WebDAV (HTTP-based, 无 kernel/FUSE 依赖)
├── macFUSE (kext, 但被禁止)
└── libnfs-go (Go NFS server, 完全独立)
9. 总结
FSKit 问题本质
问题: 为何测试方案没有提到 FSKit?
答案:
- FSKit 检测成功 ✅(backend auto-selection)
- FSKit 测试未执行 ❌(go-nfsv4 未安装)
- FSKit 并非独立方案(依赖 go-nfsv4)
- go-nfsv4 失败 → NFSv4/FSKit/SMB3 全部失败
技术现实:
FUSE-T = go-nfsv4 unified binary
├── Backend selection via CLI flag
├── Mount helper design (not daemon)
└── mount_nfs 失败 → 所有 backend 失败
FSKit ≠ 独立备选方案
FSKit = go-nfsv4 --backend fskit (同一 binary)
10. 正确的技术选型路径
初始误判:
FUSE-T → NFSv4 失败 → 尝试 FSKit → 尝试 SMB3
正确理解:
FUSE-T → go-nfsv4 失败 → NFSv4/FSKit/SMB3 全失败
→ 转向真正独立的方案:WebDAV
独立方案对比:
- ✅ WebDAV (HTTP-based, dav-server library)
- ⏸️ libnfs-go (Go NFS server, 完全独立实现)
- ❌ FUSE-T (go-nfsv4 统一 binary,单点故障)
附录:FSKit 检测 vs 实际测试
检测成功(POC 验证)
$ cargo run -- fuse detect-backend
macOS version: 26.4.1
Recommended backend: fskit
Reason: macOS 26+ supports FSKit (native, fastest)
Status: ✅ Backend detection works
实际测试失败(未执行)
# 需要安装 FUSE-T(go-nfsv4)
$ sudo installer -pkg fuse-t-1.2.6.pkg -target /
# 测试 FSKit mount
$ cargo run -- fuse poc --backend fskit
Expected: Mount succeeds at /tmp/fuse_test
Actual: 未执行(go-nfsv4 未安装)
Status: ⏳ Ready, but not tested
结论:
- FSKit 检测是 代码验证
- FSKit mount 是 实际测试
- 前者成功,后者未执行(依赖 go-nfsv4)