avatar

命令行小屋

A text-focused Halo theme

  • Ai
  • Linux
  • 游戏
  • 数据库
  • Apache Hadoop
  • Windows
  • 手机
主页 fnOS × Unraid:通过 VirtIOFS 挂载宿主机磁盘并实测 1GB/s 读取性能
文章

fnOS × Unraid:通过 VirtIOFS 挂载宿主机磁盘并实测 1GB/s 读取性能

发表于 最近 更新于 最近
作者 KennethCheng
17~22 分钟 阅读

随着 fnOS 的持续更新,虚拟机与宿主机之间的文件共享能力也越来越完善。

对于已经在 Unraid 上存储了大量数据的用户来说,与其为了 fnOS 再复制一份数据,不如直接将 Unraid 宿主机上的目录通过 VirtIOFS 共享给 fnOS 使用。

这样既可以保留原有的数据和存储结构,又能够让 fnOS 中的 Docker、媒体服务以及其他应用直接访问 Unraid 上的数据。

本文记录一次 Unraid → fnOS VirtIOFS 挂载的完整配置过程,并分别测试 VirtIOFS 和 Unraid 宿主机本地目录的顺序读写性能,对比两者之间的实际性能差异。


一、Unraid 配置 VirtIOFS

首先在 Unraid 中配置 VirtIOFS,将需要提供给 fnOS 使用的目录通过 VirtIOFS 共享。

image.png

配置完成后启动 fnOS 虚拟机。

进入 fnOS 后,可以通过 /sys/fs/virtiofs/ 检查 VirtIOFS 设备是否已经被正常识别。


二、查看 VirtIOFS 状态

首先查看当前系统识别到的 VirtIOFS 实例:

ls -l /sys/fs/virtiofs/

假设对应的 VirtIOFS 实例编号为 1,继续查看它的 tag:

cat /sys/fs/virtiofs/1/tag

输出:

pan

这里的 pan 就是 Unraid 配置的 VirtIOFS 共享 Tag,后续挂载时需要使用这个名称。


三、挂载 VirtIOFS

首先创建挂载目录:

mkdir -p /vol1/1000/mnt/pan

然后执行挂载:

mount -t virtiofs pan /vol1/1000/mnt/pan

检查挂载状态:

mount | grep virtiofs

输出:

pan on /vol1/1000/mnt/pan type virtiofs (rw,relatime)

再查看磁盘容量:

df -hT /vol1/1000/mnt/pan

输出:

Filesystem     Type      Size  Used Avail Use% Mounted on
pan            virtiofs  1.9T  1.3T  557G  71% /vol1/1000/mnt/pan

至此,Unraid 上的 pan 目录已经通过 VirtIOFS 成功挂载到 fnOS:

/vol1/1000/mnt/pan

四、测试 VirtIOFS 顺序写入性能

为了测试 VirtIOFS 的实际性能,在共享目录下创建专用测试目录:

mkdir -p /vol1/1000/mnt/pan/virtiofs_test

然后使用 dd 写入一个 10 GiB 测试文件:

sync
echo 3 > /proc/sys/vm/drop_caches

dd if=/dev/zero \
   of=/vol1/1000/mnt/pan/virtiofs_test/test_10g.bin \
   bs=1M count=10240 \
   conv=fdatasync \
   status=progress

测试过程中实时速度最高达到约 870 MB/s,最终完成后的平均速度为:

10444865536 bytes (10 GB, 9.7 GiB) copied, 12 s, 870 MB/s
10737418240 bytes (11 GB, 10 GiB) copied, 12.3916 s, 867 MB/s

10240+0 records in
10240+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 13.0148 s, 825 MB/s

最终平均写入速度约为:

825 MB/s


五、测试 VirtIOFS 顺序读取性能

接下来测试顺序读取:

sync
echo 3 > /proc/sys/vm/drop_caches

dd if=/vol1/1000/mnt/pan/virtiofs_test/test_10g.bin \
   of=/dev/null \
   bs=1M \
   iflag=direct \
   status=progress

测试结果:

10236198912 bytes (10 GB, 9.5 GiB) copied, 10 s, 1.0 GB/s

10240+0 records in
10240+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 10.4388 s, 1.0 GB/s

最终顺序读取速度约为:

1.0 GB/s


六、测试 Unraid 宿主机本地磁盘顺序写入性能

为了判断 VirtIOFS 是否带来了明显的性能损耗,再直接在 Unraid 宿主机上的同一个 pan 目录进行测试。

测试目录:

/mnt/disk5/pan/virtiofs_test

执行:

dd if=/dev/zero \
   of=./test_10g.bin \
   bs=1M count=10240 \
   conv=fdatasync \
   status=progress

测试结果:

9985589248 bytes (10 GB, 9.3 GiB) copied, 4 s, 2.5 GB/s
10737418240 bytes (11 GB, 10 GiB) copied, 4.39904 s, 2.4 GB/s

10240+0 records in
10240+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 6.46436 s, 1.7 GB/s

最终平均写入速度约为:

1.7 GB/s


七、测试 Unraid 宿主机本地磁盘顺序读取性能

继续测试宿主机本地顺序读取:

dd if=./test_10g.bin \
   of=/dev/null \
   bs=1M \
   iflag=direct \
   status=progress

测试结果:

10247733248 bytes (10 GB, 9.5 GiB) copied, 6 s, 1.7 GB/s

10240+0 records in
10240+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 6.28499 s, 1.7 GB/s

最终平均读取速度约为:

1.7 GB/s


八、VirtIOFS 与 Unraid 本地磁盘性能对比

将两组测试结果放在一起,可以比较直观地看到 VirtIOFS 的实际性能。

测试项目fnOS VirtIOFSUnraid 本地VirtIOFS 相对性能
顺序写入825 MB/s1.7 GB/s约 48.5%
顺序读取1.0 GB/s1.7 GB/s约 58.8%

从结果来看:

  • VirtIOFS 顺序写入约为 Unraid 宿主机本地性能的 48.5%
  • VirtIOFS 顺序读取约为 Unraid 宿主机本地性能的 58.8%
  • 在本次测试环境下,VirtIOFS 的实际吞吐已经达到 800 MB/s~1 GB/s 级别

也就是说,虽然 VirtIOFS 相比直接访问宿主机本地目录存在一定性能损耗,但整体吞吐依然相当可观。

需要注意的是,这只是本次硬件、Unraid、fnOS 虚拟机以及 VirtIOFS 配置下的实际测试结果,并不能代表 VirtIOFS 在所有环境中的固定性能上限。


九、实际使用体验

完成 VirtIOFS 挂载后,fnOS 就可以直接访问 Unraid 上原有的目录和数据。

例如:

/vol1/1000/mnt/pan

实际上对应的就是 Unraid 宿主机上通过 VirtIOFS 共享出来的目录。

这样一来,fnOS 中的 Docker、媒体服务、文件管理以及其他应用,就可以直接使用 Unraid 上现有的数据,而不需要为了虚拟机再额外复制一份。

这种方案最大的优势就是:

数据继续保留在 Unraid,fnOS 直接使用,无需迁移数据。

对于已经在 Unraid 上积累了大量 Docker appdata、媒体库、文件以及其他数据的用户来说,这一点尤其方便。


十、值得注意的问题

本次测试主要针对 10 GiB 大文件顺序读写性能,因此只能反映 VirtIOFS 的吞吐能力。

实际运行 Docker 服务时,性能表现并不完全取决于顺序读写速度。

例如 PostgreSQL、MariaDB、GitLab、Nextcloud 等应用,还会大量依赖:

  • 4K 随机读写
  • IOPS
  • I/O 延迟
  • fsync
  • 文件创建与删除
  • 文件系统元数据操作

因此:

顺序读取达到 1 GB/s,并不代表数据库和 Docker appdata 的实际性能也一定达到本地磁盘的 60% 左右。

如果主要用于数据库、Docker appdata 等场景,还需要进一步测试 4K 随机读写、IOPS、延迟以及大量小文件操作,才能更准确地判断 VirtIOFS 是否适合长期运行这些服务。


十一、总结

经过本次实际测试,在当前 Unraid + fnOS + VirtIOFS 环境下:

项目性能
VirtIOFS 顺序写入825 MB/s
VirtIOFS 顺序读取约 1.0 GB/s
Unraid 本地顺序写入1.7 GB/s
Unraid 本地顺序读取1.7 GB/s

从结果来看,VirtIOFS 虽然相比 Unraid 宿主机本地目录存在一定性能损耗,但仍然可以提供 800 MB/s~1 GB/s 级别的顺序读写性能。

对于希望在 fnOS 中继续使用 Unraid 数据的用户来说,VirtIOFS 最大的意义并不只是速度,而是:

不需要迁移数据、不需要额外复制存储,fnOS 可以直接访问 Unraid 上原有的数据目录。

随着 fnOS 的不断完善,这种 Unraid + fnOS + VirtIOFS 的组合,对于同时使用两个系统的用户来说,已经具备相当不错的实用价值。

最终结论:

在本次测试环境下,VirtIOFS 的顺序读取速度达到约 1 GB/s,顺序写入达到约 825 MB/s。对于普通文件访问、媒体库以及大量顺序读写场景已经足够快;如果用于数据库、GitLab、Docker appdata 等高频小文件和随机 I/O 场景,则建议进一步进行 4K 随机 I/O 和延迟测试。

fnOS, unraid
Linux
许可协议:  CC BY 4.0
分享

相关文章

8月 16, 2026

fnOS × Unraid:通过 VirtIOFS 挂载宿主机磁盘并实测 1GB/s 读取性能

随着 fnOS 的持续更新,虚拟机与宿主机之间的文件共享能力也越来越完善。 对于已经在 Unraid 上存储了大量数据的用户来说,与其为了 fnOS 再复制一份数据,不如直接将 Unraid 宿主机上的目录通过 VirtIOFS 共享给 fnOS 使用。 这样既可以保留原有的数据和存储结构,又能够让

8月 15, 2026

fnOS 飞牛 NAS 修复 Gitea 记录:升级版本并关闭用户注册

记录一次在飞牛 fnOS 上维护 Gitea 的简单过程。 本次操作主要包括:升级 Gitea、修改配置关闭注册、重启服务。整个过程均通过飞牛应用中心完成,适合使用 fnOS 部署 Gitea 的用户参考。 一、升级 Gitea 首先打开飞牛 fnOS: 飞牛应用中心 → 已安装应用 →

8月 15, 2026

我的 Gitea 被攻击实录:从 CPU 异常到确认服务器端 RCE 的完整排查过程

一次真实的家庭服务器安全事故复盘。 从最开始怀疑“是不是 CPU 被打高了”,到最终在 Git 仓库中找到攻击者留下的 post-index-change Hook,我花了不少时间才把整个攻击链拼起来。 这次事件也让我意识到:看到异常访问并不可怕,可怕的是只看到了访问日志,却没有继续追踪服务器上的文

下一篇

上一篇

fnOS 飞牛 NAS 修复 Gitea 记录:升级版本并关闭用户注册

最近更新

  • fnOS × Unraid:通过 VirtIOFS 挂载宿主机磁盘并实测 1GB/s 读取性能
  • fnOS 飞牛 NAS 修复 Gitea 记录:升级版本并关闭用户注册
  • 我的 Gitea 被攻击实录:从 CPU 异常到确认服务器端 RCE 的完整排查过程
  • New API vs LiteLLM:大模型 API 网关终极对决,6 维对比一篇说透
  • 3 分钟把 100 个大模型塞进一个 API:用 LiteLLM 给公司搭一层 LLM 网关

热门标签

samsung WireGuard Chevereto docker 破解 llama MiniMax-H3 ComfyUI LangChain Ai

目录

©2026 命令行小屋. 保留部分权利。

使用 Halo 主题 Chirpy