本系列文章将对国产 NAS 系统飞牛 fnOS 进行全方位深度解析。本文是系列第二篇，聚焦存储架构，从物理盘、RAID、LVM 到文件系统，一层一层剥开 fnOS 的存储底层，重点解析飞牛自研的 trimafs 联合文件系统和 trimacl 权限机制。

阅读本文前，建议先阅读第一篇：飞牛 fnOS 深度解析（一）：系统基础与启动流程全揭秘

前言

存储是 NAS 系统的核心。一台 NAS 不管界面多漂亮、功能多丰富，底层的存储架构决定了它的数据安全性、扩展性和性能上限。

群晖有 SHR，威联通有 Qtier，飞牛 fnOS 的存储方案是什么？官方宣传里提到的"存储池"、"智能合并"背后是什么技术？是用的开源 ZFS？还是 mdadm + LVM 的传统方案？还是自研了什么东西？

本文将通过 SSH 登录系统，用最原始的命令行方式，从物理盘到文件系统，一层一层解析 fnOS 的存储架构。

测试环境：fnOS 1.2.0505，x86_64 平台，4 块硬盘（1×NVMe SSD 119G + 1×SATA 931G + 2×SATA 465G），8G 内存。

一、存储架构总览

先看最终的挂载情况：

df -h

关键输出：

Filesystem                    Size  Used Avail Use% Mounted on
/dev/nvme0n1p2                 63G   14G   46G  24% /
/dev/nvme0n1p1                 93M  8.1M   85M   9% /boot/efi
trim_6c71e3b3-...             900G   99M  900G   1% /vol2
/dev/mapper/trim_d1c5b5d5-... 932G   15G  915G   2% /vol3
/dev/mapper/trim_a7d015a3-...  56G   25G   29G  47% /vol1
trimafs                        1.9T   40G  1.8T   3% /fs

可以看到，fnOS 有 4 个数据挂载点：/vol1、/vol2、/vol3、/fs，加上系统盘 /。

再看块设备层级：

lsblk

输出：

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda           8:0    0 931.5G  0 disk
└─sda1        8:1    0 931.5G  0 part
sdb           8:16   0 465.8G  0 disk
└─sdb1        8:17   0 465.8G  0 part
  └─md1       9:1    0 931.3G  0 raid0
    └─trim_d1c5b5d5_... 253:1 0 931.3G 0 lvm  /vol3
sdc           8:32   0 465.8G  0 disk
└─sdc1        8:33   0 465.8G  0 part
  └─md1       9:1    0 931.3G  0 raid0
    └─trim_d1c5b5d5_... 253:1 0 931.3G 0 lvm  /vol3
nvme0n1     259:0    0 119.2G  0 disk
├─nvme0n1p1 259:1    0    94M  0 part  /boot/efi
├─nvme0n1p2 259:2    0  63.9G  0 part  /
└─nvme0n1p3 259:3    0  55.2G  0 part
  └─md0       9:0    0  55.2G  0 raid1
    └─trim_a7d015a3_... 253:0 0 55.2G 0 lvm  /vol1

综合这两条命令，fnOS 的存储架构是一个四层混合架构：

┌─────────────────────────────────────────────────────────────┐
│  挂载点（用户可访问）                                          │
│  /        /vol1      /vol2       /vol3        /fs            │
└──┬────────┬──────────┬───────────┬────────────┬──────────────┘
   │        │          │           │            │
┌──▼────────▼──────────▼───────────▼────────────▼──────────────┐
│  文件系统层                                                      │
│  ext4    ext4       ZFS         ext4         trimafs(联合层)  │
└──┬────────┬──────────┬───────────┬────────────┬──────────────┘
   │        │          │           │            │
┌──▼────────▼──────────▼───────────▼────────────▼──────────────┐
│  逻辑卷层                                                        │
│  无      LVM        无(ZFS自带)  LVM          无               │
└──┬────────┬──────────┬───────────┬────────────┬──────────────┘
   │        │          │           │            │
┌──▼────────▼──────────▼───────────▼────────────▼──────────────┐
│  RAID 层                                                         │
│  无      mdadm RAID1 无(单盘)    mdadm RAID0  无               │
└──┬────────┬──────────┬───────────┬────────────┬──────────────┘
   │        │          │           │            │
┌──▼────────▼──────────▼───────────▼────────────▼──────────────┐
│  物理硬盘                                                         │
│  nvme0n1p2  nvme0n1p3   sda      sdb + sdc    (跨vol2+vol3)  │
│  (63G系统)  (55G)      (931G)   (465G×2)                      │
└─────────────────────────────────────────────────────────────────┘

一句话总结：系统盘用 NVMe SSD，数据盘同时使用了 mdadm 软 RAID + LVM 和 ZFS 两种方案，最上面还有一层自研的 trimafs 联合文件系统把多个卷合并成统一入口。

下面我们一层一层详细解析。

二、物理盘层：4 块硬盘的分工

这台机器有 4 块硬盘，分工明确：

设备类型大小用途
nvme0n1NVMe SSD119.2G系统盘 + vol1（高速存储）
sdaSATA 硬盘931.5GZFS 存储池（vol2）
sdbSATA 硬盘465.8GRAID0 成员（vol3）
sdcSATA 硬盘465.8GRAID0 成员（vol3）

NVMe SSD 被分成了 3 个分区：

分区大小挂载点用途
nvme0n1p194M/boot/efiEFI 引导分区
nvme0n1p263.9G/系统根分区
nvme0n1p355.2G→ md0 → LVM → /vol1高速数据卷

设计思路很清晰：

  • 系统和引导放在 NVMe SSD 上，保证开机速度和系统响应
  • 划出一部分 NVMe 空间作为高速数据卷（vol1），适合存 Docker 配置、数据库等需要高速 IO 的数据
  • 大容量 SATA 硬盘作为数据存储，分别走 ZFS 和 RAID0 两种方案

三、RAID 层：mdadm 软 RAID 的巧妙设计

fnOS 使用 Linux 原生的 mdadm（multiple devices admin）做软 RAID。

cat /proc/mdstat

输出：

Personalities : [raid0] [raid1] [raid4] [raid5] [raid6] [raid10] [linear]
md1 : active raid0 sdc1[1] sdb1[0]
      976506880 blocks super 1.2 512k chunks
md0 : active raid1 nvme0n1p3[0]
      57891840 blocks super 1.2 [1/1] [U]
unused devices: <none>

有两个 md 设备：md0 和 md1。

3.1 md1（vol3 的底层）：标准双盘 RAID0

md1 : active raid0 sdc1[1] sdb1[0]
      976506880 blocks super 1.2 512k chunks
  • 成员：sdb1 + sdc1，两块 465G 硬盘
  • 级别：RAID0（条带化）
  • 总容量：976506880 blocks ≈ 931G（465×2）
  • 条带大小：512k chunks
  • 状态：active（正常）

RAID0 的原理是把数据切成小块，轮流存在两块盘上，读写时两块盘同时工作，性能翻倍，容量也是两块盘之和。但代价是没有冗余——任何一块盘坏了，所有数据都没了。

vol3 用 RAID0，适合存电影、下载等可以重新获取的数据，追求大容量和高性能，不追求安全性。

3.2 md0（vol1 的底层）：单盘 RAID1 的巧妙设计

md0 : active raid1 nvme0n1p3[0]
      57891840 blocks super 1.2 [1/1] [U]

这是最有意思的地方：

  • 成员：只有 nvme0n1p3 一块盘
  • 级别：RAID1（镜像）
  • 容量：57891840 blocks ≈ 55.2G
  • 状态：[1/1] [U] —— 期望1盘/实际1盘/状态正常

正常来说，RAID1 至少需要两块盘，把同一份数据写两份，一块盘坏了另一块还有。但这里只有一块盘也做成了 RAID1。

这不是降级状态（降级会显示 [2/1] [_U]），而是飞牛故意设计的单盘 RAID1。

为什么要这么设计？

好处很明显：方便后期扩容。

如果用户一开始只有一块盘，直接用裸盘或 LVM，后期想加第二块盘做镜像保护，操作非常麻烦——需要备份数据、重新建 RAID、恢复数据。

但如果一开始就把单盘封装成 RAID1（虽然只有一个成员），后期加第二块盘时，只需要一条命令把新盘加进这个 RAID1，系统就会自动开始同步数据，同步完成后就变成了真正的双盘镜像。全程不需要重新格式化，不需要迁移数据，业务不中断。

这是一个非常巧妙的设计，用很小的开销（RAID1 层的一点点性能损耗）换取了后期扩容的极大便利性。

3.3 内核支持完整的 RAID 级别

从 Personalities 一行可以看到：

[raid0] [raid1] [raid4] [raid5] [raid6] [raid10] [linear]

fnOS 的内核支持所有主流 RAID 级别，包括 RAID5/6 这些需要校验的级别。说明飞牛的存储方案不只是支持简单的 RAID0/1，多盘场景下应该也支持 RAID5/6。

四、LVM 层：逻辑卷管理与工具移除

在 RAID 层之上，vol1 和 vol3 都套了一层 LVM（Logical Volume Manager，逻辑卷管理器）。

从 lsblk 可以看到：

md0 (raid1) → trim_a7d015a3_... (lvm) → /vol1
md1 (raid0) → trim_d1c5b5d5_... (lvm) → /vol3

LVM 的逻辑卷设备路径是 /dev/mapper/trim_xxx，这是标准的 LVM 设备映射路径。

4.1 LVM 的作用

LVM 是 Linux 下的逻辑卷管理工具，它在物理盘和文件系统之间加了一层抽象，主要好处是：

  • 灵活调整分区大小：传统分区大小定死了就不好改，LVM 可以在线扩大逻辑卷
  • 多盘合并：可以把多块盘的空间合并成一个大卷
  • 快照：LVM 支持快照功能

但在 fnOS 这里，LVM 的使用方式比较简单——每个 RAID 阵列对应一个逻辑卷，1:1 映射，没有做复杂的空间池化。也就是说，LVM 在这里主要是为了获得"在线扩容"的能力，而不是为了多盘合并。

4.2 管理工具被移除

一个值得注意的现象是：fnOS 系统里没有安装 LVM 的管理命令。

pvs
# -bash: pvs: command not found

vgs
# -bash: vgs: command not found

lvs
# -bash: lvs: command not found

dmsetup ls
# -bash: dmsetup: command not found

pvs（看物理卷）、vgs（看卷组）、lvs（看逻辑卷）、dmsetup（设备映射管理）这些 LVM 的标准管理工具全部不存在。

但 /etc/lvm/ 目录是存在的：

ls /etc/lvm/
archive  backup  lvm.conf  lvmlocal.conf  profile

说明 LVM 的配置和备份机制还在，只是管理命令被移除了。

这是飞牛的设计理念：底层用了高级技术，但把管理命令都藏起来，所有存储操作只能通过 Web 界面进行。 这样做的好处是防止用户在命令行下误操作搞坏存储，坏处是高级用户失去了命令行管理的灵活性。

同样的情况也出现在 ZFS 上（下一节会讲到）。

五、文件系统层：ZFS + ext4 + trimafs

文件系统是存储架构的最上层，直接决定了数据怎么存、怎么管理、有哪些高级功能。

fnOS 同时使用了三种文件系统：ext4、ZFS、trimafs（自研）。

5.1 ext4：经典可靠

vol1 和 vol3（LVM 逻辑卷之上）使用的是 ext4 文件系统。

ext4 是 Linux 最经典、最稳定的文件系统，几乎所有 Linux 发行版的默认文件系统都是它。它的特点是稳定、成熟、性能好，但没有快照、数据校验等高级功能。

fnOS 把 ext4 用在 LVM 卷上，是一个稳妥的选择——对于不需要高级功能的存储卷，ext4 是最可靠的选择。

5.2 ZFS：高级功能与飞牛定制

vol2 使用的是 ZFS 文件系统。

ZFS 的确认证据

虽然 zfs 和 zpool 命令被移除了（和 LVM 工具一样），但我们可以通过其他方式确认 ZFS 的存在：

1. 内核模块已加载：

lsmod | grep zfs

输出：

zfs                  5849088  28
spl                   131072  1 zfs

zfs 模块（约 5.6MB）和它的依赖 spl（Solaris Porting Layer）都已加载。

2. 挂载参数显示 ZFS：

mount | grep vol2

输出：

trim_6c71e3b3-8964-4324-9c51-5adc8ca42fb5 on /vol2 type zfs 
(rw,noatime,xattr,trimacl,casesensitive)

文件系统类型明确是 zfs。

3. ZFS 快照目录存在：

ls -la /vol2/.zfs/

输出：

drwxr-xr-x  3 root root  2 Sep  3 15:32 shares
drwxr-xr-x  3 root root  2 Jul 20 09:39 snapshot

.zfs 是 ZFS 的特殊隐藏目录，里面有 snapshot（快照）和 shares（共享）子目录。这是 ZFS 的标志性特征，其他文件系统没有这个目录。

4. 快照已挂载：

trim_6c71e3b3-...@UTC_08-2026.07.20-09.39.25 
on /vol2/.zfs/snapshot/UTC_08-2026.07.20-09.39.25 
type zfs (ro,relatime,xattr,trimacl,casesensitive)

有一个 2026年7月20日的自动快照，以只读方式挂载在 .zfs/snapshot/ 下。用户可以通过这个目录访问文件的历史版本。

ZFS 数据集命名

ZFS 的数据集名是 trim_6c71e3b3-8964-4324-9c51-5adc8ca42fb5，这是一个 UUID 格式的名字，不是人类可读的名字（比如 tank/vol2）。说明飞牛在创建 ZFS 池时，用 UUID 作为数据集名，可能是为了避免命名冲突或统一管理。

挂载参数分析

rw,noatime,xattr,trimacl,casesensitive
参数说明
rw读写模式
noatime不更新文件访问时间，提升性能
xattr支持扩展属性
trimacl⚠️ 飞牛自定义的 ACL 挂载选项
casesensitive大小写敏感

重大发现：trimacl —— 飞牛给 ZFS 打的内核补丁

这里最值得关注的是 trimacl 这个挂载参数。

标准 ZFS 没有 trimacl 这个挂载选项。 ZFS 的 ACL 相关参数是 acltype（posixacl/nfsv4acl）、aclmode 等，从来没有 trimacl。

这说明：飞牛对 ZFS 内核模块打了补丁，增加了自己的 ACL 实现，命名为 trimacl。

为什么要这么做？推测原因：

  1. 跨文件系统统一权限：fnOS 同时使用 ZFS 和 ext4，两种文件系统的 ACL 机制不同（ZFS 用 NFSv4 ACL，ext4 用 POSIX ACL）。飞牛需要一个统一的权限层，让用户在 Web 界面设置的权限，不管底层是 ZFS 还是 ext4，行为都一致。
  2. 和 SMB/NFS 权限对齐：NAS 的文件共享主要走 SMB 和 NFS，这两种协议的权限模型和 Linux 本地权限不完全一样。飞牛可能需要一个自定义的 ACL 层来更好地对齐 SMB/NFS 的权限语义。
  3. 和 trimafs 配合：后面会讲到，飞牛还有一层 trimafs 联合文件系统，它也需要统一的权限管理。trimacl 可能是贯穿 ZFS/ext4/trimafs 的统一权限机制。

不管具体实现是什么，trimacl 的存在说明：飞牛不是简单套用开源 ZFS，而是对 ZFS 做了内核级的定制开发。 这是有相当技术含量的工作。

ZFS 在 fnOS 中的定位

vol2 是单盘 ZFS（只有 sda 一块盘），所以没有 RAID 冗余（一块盘坏了数据还是没了），但享受了 ZFS 的高级功能：

  • 快照：自动创建快照，用户可以恢复误删/误改的文件
  • 数据校验：每个块都有校验和，读取时自动检测数据损坏
  • Copy-on-Write：写时复制，不会因为中途断电导致文件损坏
  • 压缩：ZFS 支持透明压缩（虽然这里没看到压缩参数，但可能默认开了）

Docker 的数据目录也设在了 vol2 上（/vol2/docker/），利用 ZFS 的快照和数据校验保护容器数据和镜像。

5.3 trimafs：飞牛自研联合文件系统（重点）

最后来说最神秘的 /fs，它使用的文件系统叫 trimafs。

trimafs 的确认

cat /proc/filesystems | grep trim

输出：

nodev   trimafs

nodev 表示这个文件系统不需要对应块设备——它不是直接管理物理硬盘的文件系统，而是在其他文件系统之上做一层抽象。

lsmod | grep trim

输出：

trimafs2               77824  1

内核模块名叫 trimafs2（注意是 2，第二版），大小只有 77824 字节（约 76KB），被 1 处引用。

mount | grep ' /fs '

输出：

trimafs on /fs type trimafs (rw,relatime,trimacl)

挂载参数里也有 trimacl——和 ZFS 用的是同一个自定义 ACL 机制。

ps aux | grep trimafs

没有 trimafs 的用户态进程（只有 grep 自己）。说明 trimafs 不是 FUSE 用户态文件系统，而是纯内核模块实现。

trimafs 是什么？

综合以上证据：

  • 纯内核模块实现（不是 FUSE）
  • nodev，不直接管理块设备
  • 模块名 trimafs2，已经迭代到第二版
  • 仅 76KB，轻量级
  • 挂载参数支持 trimacl，和 ZFS 统一权限
  • 总容量 1.9T ≈ vol2(900G) + vol3(932G)

结论：trimafs 是飞牛自研的内核级联合文件系统（Union Filesystem），它的作用是把多个底层存储卷（vol2、vol3）合并成一个统一的命名空间 /fs，让用户感觉像是在一个大文件夹里操作，实际上文件可能分布在不同的物理卷上。

类似的开源方案有 mergerfs、unionfs、aufs，但飞牛选择了自己实现一个内核模块，而不是用开源方案。

trimafs 的工作原理验证

我们来验证一下 trimafs 是不是真的把 vol2 和 vol3 联合起来了。

看 /fs 下的目录：

ls -la /fs/

输出：

drwxrwxrwx  5 root root    0 Sep  3 08:03 .
drwxr-xr-x 25 root root 4096 Sep  3 08:03 ..
drwxr-xr-x  3 root root    0 Sep  3 08:03 1000
drwxr-xr-x  3 root root    0 Sep  3 08:03 1001
drwxr-xr-x  3 root root    0 Sep  3 08:03 1002

/fs 下只有三个目录：1000、1001、1002——这是三个用户的 UID（用户 ID），对应用户的个人存储空间。

再看 /vol2 下的目录：

ls -la /vol2/

输出：

d---------  2 dio  root    2 Jul 14 12:40 1000
d---------  2 D    root    2 Jul 18 09:08 1001
d---------  2 D1   root    2 Jul 18 09:09 1002
drwxr-x---  2 root root    2 Aug  4 08:58 appcenter-downloads
drwxr-xr-x  3 root root    3 Jul 20 09:38 @appmeta
drwx--x--- 12 root root   13 Sep  3 08:03 docker
d------r-x  3 root root    3 Jul 20 08:58 @team
d---------  9 root root    9 Jul 20 09:38 thumb

/vol2 下也有 1000、1001、1002 三个用户目录，属主分别是 dio（UID 1000）、D（UID 1001）、D1（UID 1002）。

再看 /vol3 下的目录：

ls -la /vol3/

输出：

d---------  1 dio  root   80 Aug  6 00:11 1000
d---------  1 D    root    0 Jul 20 18:28 1001
d---------  1 D1   root    0 Jul 20 18:28 1002
drwxr-x---  1 root root    0 Aug  5 15:04 appcenter-downloads
drwxr-xr-x  1 root root   26 Jul 20 19:03 @appmeta
d---------  1 root root   62 Jul 20 19:03 thumb

/vol3 下同样有 1000、1001、1002 三个用户目录。

真相大白：每个用户在 vol2 和 vol3 上都有自己的目录，trimafs 把这两个位置的同名目录联合成 /fs/1000/ 一个入口。 用户通过 /fs/1000/ 访问自己的文件时，trimafs 自动把文件分布到 vol2 和 vol3 上，用户不需要关心文件实际存在哪块盘。

空间使用情况也验证了这一点：

挂载点总容量已用
/fs（trimafs）1.9T40G
/vol2（ZFS）900G99M
/vol3（ext4）932G15G

/fs 的 1.9T 正好约等于 vol2(900G) + vol3(932G)。

trimafs 的设计意义

trimafs 是飞牛存储架构的核心创新，它解决了几个问题：

  1. 统一入口：用户不需要关心自己的文件存在哪个卷、哪块盘，只需要知道 /fs/我的目录/ 就行
  2. 跨文件系统透明：不管底层是 ZFS 还是 ext4，用户看到的都是统一的目录结构和权限行为（通过 trimacl 统一）
  3. 自动负载均衡：trimafs 可以根据各卷的空间使用情况，自动决定新文件存在哪个卷上
  4. 在线扩容：加一块新盘、建一个新卷，trimafs 可以把它加入联合，用户无感知

这就是飞牛官方宣传的"存储池"、"智能合并"背后的技术实现——不是什么黑科技，而是一个自研的内核级联合文件系统，但做得很轻量（76KB）、很底层（内核模块）、和权限系统深度整合（trimacl）。

六、数据目录结构

了解了存储架构之后，我们来看看数据在各卷上是怎么组织的。

6.1 用户数据

每个用户（按 UID）在每个数据卷上都有自己的目录：

/vol2/1000/  → 用户 dio 在 ZFS 卷上的个人空间
/vol3/1000/  → 用户 dio 在 ext4 卷上的个人空间
/fs/1000/    → trimafs 联合后的统一入口（用户实际访问的位置）

目录权限是 d---------（700），只有属主本人能访问，安全性不错。

6.2 系统数据

除了用户目录，每个卷上还有一些系统目录：

目录存在位置用途
@appmetavol2、vol3应用元数据
appcenter-downloadsvol2、vol3应用中心下载缓存
thumbvol2、vol3缩略图缓存
docker仅 vol2Docker 数据（镜像、容器、卷）
@team仅 vol2团队空间？

可以看到，@appmeta、appcenter-downloads、thumb 这些目录在每个卷上都有——说明每个存储卷有自己独立的应用元数据和缓存。而 Docker 数据只在 vol2（ZFS）上，因为飞牛把 Docker 默认数据目录设在了 ZFS 卷上，利用 ZFS 的快照和校验保护容器数据。

带 @ 前缀的目录（@appmeta、@team）是飞牛的命名约定，用来标识系统目录，和用户目录区分开。

七、存储解构方法论：5 条命令摸清新 NAS 的存储

分析完 fnOS 的存储架构，我们可以总结出一套通用的方法论——拿到任何一台新 NAS（包括其他品牌的设备），用以下 5 条命令，5 分钟内就能摸清它的存储架构：

命令 1：看挂载和文件系统

df -h
  • 看有哪些挂载点、各自多大、用了多少
  • 看文件系统类型（ext4？xfs？zfs？btrfs？还是自研的？）
  • 重点关注非标准的文件系统类型（比如 fnOS 的 trimafs）

命令 2：看块设备层级

lsblk
  • 看有几块物理盘、每块盘怎么分区
  • 看有没有 RAID 设备（md0、md1）
  • 看有没有 LVM 逻辑卷（dm-0、dm-1，或 /dev/mapper/ 路径）
  • 看挂载点和物理盘的对应关系
  • 这是最核心的一条命令，一张图就能看清整个存储栈

命令 3：看软 RAID

cat /proc/mdstat
  • 看有几个 md 设备、各自是 RAID 几
  • 看成员盘有哪些、状态是否正常
  • 看条带大小等参数

命令 4：看内核模块（找自研文件系统）

lsmod | grep -E 'zfs|trim|fuse|union|btrfs'
  • 看加载了哪些文件系统相关的内核模块
  • 重点找非标准的模块名（比如 fnOS 的 trimafs2）
  • 这些自研模块往往是厂商的核心技术

命令 5：看注册的文件系统类型

cat /proc/filesystems
  • 看内核注册了哪些文件系统类型
  • nodev 的是不直接管理块设备的虚拟文件系统（比如联合文件系统、网络文件系统）
  • 找非标准的文件系统名（比如 fnOS 的 trimafs）

bonus：看厂商安装目录

ls /usr/trim/   # fnOS 的安装目录
# 其他品牌可能在 /usr/local/、/opt/、或自己的命名目录
  • 找厂商的自研程序、配置、脚本
  • 看版本号文件（通常在 etc/version 或类似位置）
  • 看有没有自研的存储管理工具

八、总结

通过本文的深度解析，我们对 fnOS 的存储架构有了完整的认知：

  1. 四层混合架构：物理盘 → mdadm RAID → LVM/ZFS → 文件系统（ext4/ZFS/trimafs），同时使用多种存储技术，不是一刀切的方案
  2. 巧妙的 RAID 设计：单盘也封装成 RAID1，方便后期加盘做镜像，不需要重新格式化和迁移数据
  3. ZFS 内核级定制：不是简单套用开源 ZFS，而是打了 trimacl 内核补丁，实现跨文件系统的统一权限管理
  4. trimafs 自研联合文件系统：76KB 的轻量内核模块，把多个存储卷合并成统一入口，是飞牛"存储池"概念的底层实现，已经迭代到第二版
  5. 管理工具移除策略：LVM 和 ZFS 的命令行管理工具全部被移除，所有存储操作只能通过 Web 界面，防止用户误操作
  6. 数据分层存储：Docker 数据放 ZFS 卷（利用快照和校验），用户数据通过 trimafs 自动分布，系统缓存每个卷独立管理

fnOS 的存储架构不是简单的"拿来主义"，而是在开源技术的基础上做了不少自研和定制，尤其是 trimafs 和 trimacl 这两个内核级组件，体现了相当的技术功底。

系列预告

下一篇《飞牛 fnOS 深度解析（三）：文件服务与用户权限体系》，我们将详细解析：

  • SMB/CIFS 服务的配置与认证机制
  • NFS、WebDAV、FTP 的实现方式
  • 四种文件协议的对比与统一认证
  • Web 用户和 Linux 系统用户的关系
  • 用户信息存在哪里（/etc/passwd？数据库？）
  • 权限是 POSIX ACL 还是自研的 trimacl？
  • 跨协议权限怎么保证一致

敬请期待。

本文基于 fnOS 1.2.0505 版本实测，不同版本可能存在差异。
存储操作有风险，请勿在生产环境随意执行本文中的命令。