Skip to content

Commit 04bcc26

Browse files
mudsskymudssky
committed
feat(fnos): 添加磁盘别名和补挂功能支持FNOS重启后命名稳定化
添加完整的磁盘别名同步和失败盘补挂机制，解决FNOS重启后磁盘被挂载到型号路径的问题。 新功能包括： - alias命令：为已挂载到型号路径的磁盘建立业务名bind mount别名 - backfill命令：为FNOS未挂载的磁盘执行单独补挂 - reconcile命令：组合入口，先同步别名再补挂失败盘 - 扩展状态模型，显式区分别名同步候选盘与补挂候选盘 此方案采用"保留FNOS原始路径+叠加业务名别名"的方式，避免与FNOS原生挂载机制冲突， 同时提供稳定的业务名访问路径供Samba等上层服务使用。
1 parent 6d6d24d commit 04bcc26

24 files changed

Lines changed: 2867 additions & 95 deletions

‎docs/brainstorms/2026-04-05-fnos-disk-alias-and-backfill-requirements.md‎

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
---
2+
date: 2026-04-05
3+
topic: fnos-disk-alias-and-backfill
4+
---
5+
6+
# FNOS 磁盘业务名别名与失败盘补挂方案
7+
8+
## Problem Frame
9+
10+
当前 `linux/fnos/fnos-mount-manager` 已经能生成 `fstab`、`tmpfiles`、并提供 `check`、`repair`、`remount` 等命令，但实机重启后的结果说明：仅靠 systemd `fstab` 挂载，并不能稳定赢过 FNOS 原生自动挂载。
11+
12+
本机当前状态已经清楚分成两类：
13+
14+
- `animeDisk`、`debutDisk`、`galDisk` 已经被 FNOS 原生服务挂上，但路径是 `/vol00/ST4000VX007-2DT166`、`/vol00/ST8000NM017B-2TJ103`、`/vol00/WDC WD40EZRZ-00GXCB0` 这类型号路径，而不是业务名路径。
15+
- `bookDisk` 没有被成功挂上，属于真正的失败盘。
16+
17+
因此下一步不应该继续把所有盘都视为“必须由我们抢到底层首次挂载”，而是要把方案改成两段式：
18+
19+
1. 对已经被 FNOS 原生挂上的盘，建立稳定业务名别名层。
20+
2. 对 FNOS 没挂上的盘，单独补挂。
21+
22+
这个方案的目标不是改掉 FNOS 原始挂载路径，而是在保留原始路径的前提下，额外提供稳定、可预期、适合 Samba/脚本/人工使用的业务名路径。
23+
24+
## Requirements
25+
26+
**Alias Layer**
27+
- R1. 方案必须保留 FNOS 原始挂载路径，不主动重命名或删除 `/vol00/ST...`、`/vol00/WDC...` 这类原生路径。
28+
- R2. 对已经被 FNOS 成功挂上的磁盘，管理器必须能够建立稳定的业务名别名路径，例如把原始路径映射到 `/vol00/debutDisk`。
29+
- R3. 业务名别名层默认必须使用 bind mount，而不是 symlink，除非目标环境明确不支持 bind mount。
30+
- R4. 别名同步时必须以“原始路径是否已存在且已挂载”为前提；如果原始路径不存在，不应创建空壳别名误导使用者。
31+
32+
**Backfill for Failed Disks**
33+
- R5. 对 FNOS 原生自动挂载失败的磁盘，管理器必须能够单独执行补挂，而不是要求所有磁盘都统一重挂。
34+
- R6. “失败盘补挂”与“已挂盘别名同步”必须是可组合但逻辑独立的两个分支；不能因为某块盘失败就中断其余已挂盘的别名同步。
35+
- R7. 对补挂仍失败的磁盘，管理器必须给出明确失败原因，并保留其他磁盘的成功结果。
36+
37+
**Naming and Access**
38+
- R8. 业务名路径必须继续以结构化配置中的固定业务名为准，例如 `/vol00/bookDisk`、`/vol00/debutDisk`，不能退回卷标或磁盘型号派生。
39+
- R9. Samba 等上层共享配置必须可以稳定切换到业务名路径，而不要求依赖 FNOS 原始型号路径。
40+
- R10. 对终端用户和脚本调用方而言，业务名路径应成为推荐访问入口；原始路径保留但降级为底层实现细节。
41+
42+
**Workflow**
43+
- R11. 管理器必须新增明确的“别名同步”能力，并支持只同步别名、不执行补挂。
44+
- R12. 管理器必须支持只对失败盘执行补挂，而不扰动已经被 FNOS 挂上的磁盘。
45+
- R13. 管理器必须支持一个组合入口，在一次运行中完成“先同步已挂盘别名，再补挂失败盘”。
46+
- R14. 组合入口默认不应对已经健康挂上的磁盘执行 `umount` + `mount`，除非用户显式选择强制重挂。
47+
48+
## Success Criteria
49+
- `animeDisk`、`debutDisk`、`galDisk` 这类已被 FNOS 挂到型号路径的盘，在不破坏原始路径的前提下，能稳定通过业务名路径访问。
50+
- `bookDisk` 这类 FNOS 未挂上的盘，可以被单独补挂到业务名路径。
51+
- 业务名路径能够作为 Samba 或其他上层入口的稳定配置目标。
52+
- 管理器在一次执行中可以同时报告：哪些盘做了别名同步、哪些盘做了补挂、哪些盘仍失败。
53+
- 失败盘不会拖垮已挂盘的别名同步结果。
54+
55+
## Scope Boundaries
56+
- 本次不尝试让 FNOS 原生自动挂载直接改名为业务名路径。
57+
- 本次不禁用或替换 `trim_main.service` 这类 FNOS 核心服务。
58+
- 本次不要求删除型号路径或让它们从系统中消失。
59+
- 本次不把 Samba 共享层的最终改动策略在此文档中细化到具体配置文件级别；这里只要求业务名路径可作为稳定目标。
60+
61+
## Key Decisions
62+
- 采用“保留 FNOS 原始路径 + 叠加 bind mount 业务名别名”的方式，而不是强行改写 FNOS 原始挂载结果。
63+
- 采用“只对失败盘补挂”的方式，而不是每次对所有盘统一重挂。
64+
- 采用“别名同步”和“失败盘补挂”分支解耦的方式，而不是把两者硬塞进一个只会全成全败的流程。
65+
- 采用“业务名路径为推荐入口”的方式，而不是继续让型号路径暴露给上层使用者。
66+
67+
## Dependencies / Assumptions
68+
- FNOS 原生自动挂载在多数情况下仍会先把部分盘挂到型号路径，这些路径在方案运行时可被发现。
69+
- 目标环境支持 bind mount，并允许在 `/vol00` 下建立附加挂载点。
70+
- 当前仓库内的结构化磁盘配置已经足以表达“业务名 -> 设备标识”的关系。
71+
72+
## Outstanding Questions
73+
74+
### Resolve Before Planning
75+
- 暂无。
76+
77+
### Deferred to Planning
78+
- [Affects R2,R3,R11,R13][Technical] 别名同步是通过 bind mount 单次命令完成，还是需要额外生成/安装持久化规则或 service 来保障重启后自动恢复。
79+
- [Affects R5,R6,R12,R13][Technical] 失败盘补挂的判定规则如何定义，才能稳定区分“未挂上”与“已挂到错误路径”。
80+
- [Affects R9,R10][Technical] 是否要在同一轮里同步更新 Samba 配置指向业务名路径，还是先只保证本地业务名路径稳定可用。
81+
- [Affects R13][Technical] 组合入口的命令面应如何设计，例如 `sync`、`alias`、`backfill`、`reconcile` 哪个最清晰。
82+
83+
## Next Steps
84+
85+
→ /prompts:ce-plan for structured implementation planning

‎docs/ideation/2026-04-05-fnos-postboot-disk-naming-ideation.md‎

Lines changed: 76 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,76 @@
1+
---
2+
date: 2026-04-05
3+
topic: fnos-postboot-disk-naming
4+
focus: 重启后仍然无法稳定按业务名挂载 FNOS 外接盘，还有什么办法
5+
---
6+
7+
# Ideation: FNOS 重启后磁盘业务名稳定化
8+
9+
## Codebase Context
10+
11+
当前仓库已经有一套 `linux/fnos/fnos-mount-manager`，支持 `generate`、`apply`、`check`、`status`、`repair`、`remount`，并能生成 `fstab` 与 `tmpfiles` 规则。实现假设是：只要 systemd 在开机阶段成功挂载到 `/vol00/bookDisk`、`/vol00/debutDisk` 这类路径，就能稳定保持业务名。
12+
13+
但本机实际行为显示，这个假设只成立一部分。开机后真正把多块 NTFS 盘挂载到 `/vol00/ST4000VX007-2DT166`、`/vol00/ST8000NM017B-2TJ103`、`/vol00/WDC WD40EZRZ-00GXCB0` 的，是 FNOS 的 `trim_main.service`，而不是我们的挂载管理器。当前状态里：
14+
15+
- `RemovableDisk` 能按我们的名字挂上。
16+
- `animeDisk`、`debutDisk`、`galDisk` 常被 FNOS 原生自动挂载抢到型号路径。
17+
- `bookDisk` 还存在“重启后未挂上”的单独失败路径。
18+
- `status`、`check`、`repair`、`remount` 已能把这些冲突暴露出来，但还没有从产品层决定“到底是要和 FNOS 抢挂载，还是接受 FNOS 原始挂载再做命名抽象”。
19+
20+
代码与系统信号都说明：继续单纯增强 `fstab` 规则，无法保证重启后稳定取胜。FNOS 原生自动挂载是系统内建对手，而不是偶发干扰。
21+
22+
## Ranked Ideas
23+
24+
### 1. 在 FNOS 原始挂载之上建立稳定业务名别名层
25+
**Description:** 不再尝试让 FNOS 原生自动挂载直接使用 `bookDisk`、`debutDisk` 这些名字，而是接受它先挂到型号路径，再由我们的管理器在开机后建立稳定的业务名别名层。别名层优先考虑 bind mount，其次才是 symlink，因为 bind mount 对 Samba、本地 CLI 和依赖真实目录树的工具兼容性更强。这里的“同步”不是给已有挂载直接改名，也不是默认先卸载再重挂，而是保持 FNOS 原始挂载不动，再把 `/vol00/ST...` 绑定到 `/vol00/bookDisk` 这类业务路径。
26+
**Rationale:** 这条路线不和 `trim_main.service` 正面争抢首挂时机，而是把它当成底层事实来源，再把用户真正关心的“稳定业务名路径”叠加在其上。它最符合当前代码库和本机观测：FNOS 会挂、但名字不对；我们要的是名字稳定，而不是一定亲自执行底层第一次 mount。
27+
**Downsides:** 需要额外处理“原始路径发现”和“业务名别名同步”两层状态；如果 FNOS 某次连原始挂载都失败，别名层也无能为力。另外这条路线会同时保留“型号路径”和“业务名路径”两套入口。
28+
**Confidence:** 88%
29+
**Complexity:** Medium
30+
**Status:** Unexplored
31+
32+
### 2. 增加开机后重协调服务，显式执行 `remount`
33+
**Description:** 把当前已有的 `remount` 命令做成开机后的 oneshot service，顺序放在 `trim_main.service` 和相关挂载完成之后。它的职责不是取代 `fstab`，而是当系统重启后发现设备被挂到型号路径或某块盘未按期望挂载时，主动卸掉错误挂载并按业务名重挂。
34+
**Rationale:** 这条路线最大程度复用你已经写好的 `remount` 逻辑，改动集中，能最快验证“重启后自动纠偏”是否足够。对于现在这种“重启后只挂 4 块、而且名字不对”的症状，它能直接对症。
35+
**Downsides:** 仍然属于“和 FNOS 原生自动挂载打第二回合”，而不是从模型上绕开冲突。若 FNOS 服务在后续阶段继续刷新挂载，仍可能出现来回抢占。
36+
**Confidence:** 81%
37+
**Complexity:** Medium
38+
**Status:** Unexplored
39+
40+
### 3. 采用混合策略：FNOS 原始挂载做底座，仅对失败盘和关键盘执行定向重挂
41+
**Description:** 把盘分成两类：默认所有盘都接受 FNOS 原始挂载结果，并通过业务名别名层统一访问；只有像 `bookDisk` 这种重启后经常挂载失败、或你明确要求必须真实占用业务名路径的少数盘，再执行定向 `remount`。也就是说，“已经被 FNOS 正常挂上但名字不对”的盘走 bind mount 别名；“FNOS 没挂上”的盘才补挂。
42+
**Rationale:** 这是在稳定性和控制力之间的折中方案。你不必为所有盘都承担“抢占底层挂载”的风险，只把复杂度投到真正出问题的少数盘。
43+
**Downsides:** 认知模型变成双轨：有些业务名来自别名，有些来自真实重挂。后续运维文档必须写清楚，否则容易混乱；实现上还要有“判定某块盘属于哪一类”的稳定规则。
44+
**Confidence:** 77%
45+
**Complexity:** Medium
46+
**Status:** Unexplored
47+
48+
### 4. 把“名字稳定”下沉到共享层，而不是块设备挂载层
49+
**Description:** 接受本地实际挂载仍然是 `/vol00/ST...` 或 `/vol00/WDC...`，但通过 Samba/WebDAV/文件管理器配置层，把对外暴露的名称稳定成 `bookDisk`、`debutDisk` 这类业务名。同时，本地 CLI 若也需要业务名，可再提供轻量别名目录或脚本辅助跳转。
50+
**Rationale:** 如果你的核心诉求其实是“网络访问和日常管理看起来名字稳定”，那就没必要非在底层挂载点层面赢 FNOS。共享层通常比块设备层更适合承接“人类可读命名”。
51+
**Downsides:** 这并不能让 `/vol00/bookDisk` 本身天然存在，更多是“用户界面命名正确”，不是真正的底层挂载命名统一。对需要本地脚本固定路径的场景帮助有限。
52+
**Confidence:** 72%
53+
**Complexity:** Low
54+
**Status:** Unexplored
55+
56+
### 5. 逆向 FNOS 原生自动挂载链路，寻找可注入的命名映射点
57+
**Description:** 把研究重点从 `fstab` 和 systemd 转到 FNOS 自带服务链路，尤其是 `trim_main.service`、`share_service`、`RemovableMonitor`、以及它们使用的配置和模板。目标不是立刻 hack 二进制，而是先验证是否存在“把型号路径映射成业务名”的可注入配置点或 hook。
58+
**Rationale:** 如果 FNOS 确实有内建命名映射能力，而我们现在只是没找到，那么这是唯一能让“系统原生自动挂载直接按业务名表现”的正统路线。长远看，这也是最干净的整合方式。
59+
**Downsides:** 当前扫描没有发现明显现成入口，说明这条路要么不存在，要么埋得很深。探索成本最高，成功率不如前几项确定。
60+
**Confidence:** 44%
61+
**Complexity:** High
62+
**Status:** Unexplored
63+
64+
## Rejection Summary
65+
66+
| # | Idea | Reason Rejected |
67+
|---|------|-----------------|
68+
| 1 | 继续只靠 `fstab` / `tmpfiles` 打赢 FNOS 原生自动挂载 | 当前系统状态已经证明这条路不稳定，`trim_main.service` 会在重启后抢设备挂载 |
69+
| 2 | 单纯把 NTFS 卷标改成业务名，让 FNOS 自动用卷标命名 | 现网证据显示 FNOS 当前挂载名更多来自磁盘型号而不是文件系统卷标 |
70+
| 3 | 完全禁用 `trim_main.service` | 风险过高，它是 FNOS 核心服务，禁掉会影响的不只是外接盘挂载 |
71+
| 4 | 只用 symlink 做业务名 | 成本低但兼容性弱，许多工具和共享场景对 bind mount 更稳 |
72+
| 5 | 继续人工重启后执行 `remount` | 不解决“重启后自动恢复”的根问题，只是把操作成本留给人 |
73+
74+
## Session Log
75+
- 2026-04-05: Initial ideation — 10+ candidate directions considered, 5 survivors kept
76+
- 2026-04-05: Refined ideas #1 and #3 — clarified that alias sync prefers bind mounts over rename/unmount, and that failed disks can fall back to targeted remount

‎docs/plans/2026-04-05-001-refactor-fnos-mount-manager-plan.md‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,8 @@ origin: docs/brainstorms/2026-04-05-fnos-portable-disk-mounting-requirements.md
1212

1313
本计划承接 `docs/brainstorms/2026-04-05-fnos-portable-disk-mounting-requirements.md`，目标是把当前分散在 `linux/fnos/fnos-mount-manager/fstab`、`linux/fnos/remount.sh`、以及机器侧临时 systemd / shell 补救逻辑里的数据盘挂载流程，收敛为一套可复制、可校验、可修复的 FNOS 挂载管理器。
1414

15+
后续补充说明：这份计划已经完成“统一管理器骨架、配置生成、检查、修复”这一层；针对“FNOS 开机后把部分磁盘挂到型号路径、部分磁盘完全未挂”的启动后命名稳定化问题，后续工作已拆分到 `docs/plans/2026-04-05-002-feat-add-fnos-alias-backfill-plan.md`，不再继续堆叠到本计划里。
16+
1517
这次不再把“编辑 `fstab`”和“修复挂载异常”视为两个独立脚本问题，而是统一为一个模块化 shell 工具链：
1618

1719
1. `linux/fnos/` 下维护结构化 shell 配置与模块化源码。

0 commit comments

Comments
 (0)