请不要把任何和邀请码有关的内容发到 NAS 节点。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
这是一个创建于 318 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，随着 unraid6.12 更新正式支持了 zfs ，op 第一时间把缓存盘格了尝试了下，感觉貌似好像没什么提升？
因为 unraid shfs 众所周知的奇妙逻辑，导致了这个系统的文件可以被分成好几类，以 op 自己举例：
array：冷(各种备份和重要文件)+温数据存放在(2 寸+1 校)的三块 4t 紫盘里，平时日常休眠，三块盘均为 btrfs;
cache：容器+虚拟机+系统文件存放在一块 980pro 缓存盘上，作为高性能应用的储存空间，为 zfs;
raw：媒体库+pt 相关+日常存取文件，存放在组了 btrfs-raid0 的两块 8t 企业盘，作为 16t 储存盘使用;
其他配置：13500+w680+64g ecc+ups 、磁盘独占已打开，盘位 5/8
因为 op 在一个 winserver 上运行着几个 mcje 的服务器。只要硬盘 io 性能不够，服务端就会报"cant keep up"的问题并掉 tps ，属实令人相当恶心。此时优化磁盘 io 性能就成了重点。
需求：array 有较好的安全性，cache 和 raw 尽量有较好的读写性能，并且 raw 尽可能多的利用储存空间(目前为 100%)
参考 reddit 的两篇回复：
1.
BFTRS = Support is dieing out
XFS = The current standard for unraid
ZFS = Only if you know what your doing
2.
xfs for the array
zfs for the cache
是否应该抛弃 btrfs ，将 array 换成 xfs(不换成 zfs 的原因是多盘 zfs 貌似不能单独休眠？);
将 cache 换成 xfs(非 cow 文件系统性能较好)
将 raw 换成 zfs(读写日常文件时使用 zfs arc 提供更快的读写速度，同时 xfs 无法把两个磁盘组合成一个池)
另：
vm.dirty_ratio 和 vm.dirty_background_ratio 到底改咋调啊，目前都是默认的 5%
xfs 这种非 cow 文件系统能不能承载 qcow2 的虚拟磁盘？
因为 unraid shfs 众所周知的奇妙逻辑，导致了这个系统的文件可以被分成好几类，以 op 自己举例：
array：冷(各种备份和重要文件)+温数据存放在(2 寸+1 校)的三块 4t 紫盘里，平时日常休眠，三块盘均为 btrfs;
cache：容器+虚拟机+系统文件存放在一块 980pro 缓存盘上，作为高性能应用的储存空间，为 zfs;
raw：媒体库+pt 相关+日常存取文件，存放在组了 btrfs-raid0 的两块 8t 企业盘，作为 16t 储存盘使用;
其他配置：13500+w680+64g ecc+ups 、磁盘独占已打开，盘位 5/8
因为 op 在一个 winserver 上运行着几个 mcje 的服务器。只要硬盘 io 性能不够，服务端就会报"cant keep up"的问题并掉 tps ，属实令人相当恶心。此时优化磁盘 io 性能就成了重点。
需求：array 有较好的安全性，cache 和 raw 尽量有较好的读写性能，并且 raw 尽可能多的利用储存空间(目前为 100%)
参考 reddit 的两篇回复：
1.
BFTRS = Support is dieing out
XFS = The current standard for unraid
ZFS = Only if you know what your doing
2.
xfs for the array
zfs for the cache
是否应该抛弃 btrfs ，将 array 换成 xfs(不换成 zfs 的原因是多盘 zfs 貌似不能单独休眠？);
将 cache 换成 xfs(非 cow 文件系统性能较好)
将 raw 换成 zfs(读写日常文件时使用 zfs arc 提供更快的读写速度，同时 xfs 无法把两个磁盘组合成一个池)
另：
vm.dirty_ratio 和 vm.dirty_background_ratio 到底改咋调啊，目前都是默认的 5%
xfs 这种非 cow 文件系统能不能承载 qcow2 的虚拟磁盘？
 |
1
ltkun 318 天前 via Android
pve 全部 zfs 扩展性啥的强太多 第一次知道 zfs 就下定决心全部迁移
|
 |
3
ExplodingFKL 317 天前
@totoro625 #2 主要是支持错误自愈（在带冗余的情况下），但在空间快满的情况下性能会下降
|
 |
4
locoz 317 天前 via Android
我觉得吧，你靠换文件系统想提升性能，不如把你的 mc 服务端从虚拟机里拿出来放到容器里，避免性能损耗…
|
 |
5
a632079 317 天前
ZFS 的好处是安全性啊……我之前缓存盘用的 BTRFS ，然后就没了。损失了四五百 GiB 的数据（还包括了局域网的 Gitea 数据容器）😭
|
 |
6
HashV2 317 天前
机械阵列 XFS 两块 8T 数据盘 一块 10T 校验盘
固态缓存 BFTRS 两块 2T raid1 |
 |
7
qq979365509 317 天前
unraid 再等等，现在 zfs 功能官方支持不是很全。zfs 对固态硬盘没什么提升，甚至性能下降，对机械硬盘的提升就非常大，用 zfs 主要是因为特性而不是性能。
|
 |
8
libook 317 天前  1
unRAID 官方文档给出了文件系统的选择建议，列出了每种文件系统的优缺点和在 unRAID 系统上的默认行为，可以参考 https://docs.unraid.net/unraid-os/manual/storage-management/#selecting-a-file-system-type
官方文档有一个比较重要的信息，就是尽量使用 unRAID 来格式化文件系统，因为它会根据它的产品技术原理来使用特定的参数格式化文件系统。 个人理解，unRAID 的设计是面向一定的使用场景的。 最初也是最核心的场景就是冷数据场景，即通常作为传统存储设备用来**存储**文件的，比如照片、录影、文档。在这个场景下通常不需要实时的数据检索和高 IOPS ，但对数据完整性、存储空间的可扩展性要求更高，unRAID 招牌的 Array 方案就是用来针对性满足这些需求的。 后来用户开始在 NAS 上跑服务和虚拟机了，那么对实时检索和 IOPS 的需求更高了，但 unRAID 原本的 Array 并不兼容这种需求场景，于是就提供了一个额外的 Cache Pool 机制，向当于是基于传统的 RAID 方案来做了另外一套存储体系来提供很高的 IO 性能，然后再将它与原有 Array 存储体系打通，让用户可以通过设置来确保热数据始终在 Cache Pool 中，而冷数据放在 Array 中。当然如果没多少冷数据，Cache Pool 就会成为最大和最主要的存储空间，只是这样就不局限在 unRAID 提供的方案，其他的 NAS 系统也可以或者更能胜任。 因为受限于 Btrfs 的 RAID 支持不完善，仅 RAID0 和 RAID1 是稳定可用的，而对于有较多热数据（单盘放不下）的人来说，用 RAID0 不安全、用 RAID1 成本太高。于是 unRAID 引入了 ZFS 来提供更完备的 RAID 支持。 基于对 unRAID 的设计应用场景的理解，我自己是将我的数据分为冷数据和热数据两部分，我的热数据的量级远小于冷数据，属于 unRAID 面向的使用场景，于是我的方案如下： - 冷数据：多块机械硬盘，XFS 文件系统，unRAID Array - 热数据：2NVMe ，Btrfs ，RAID1 Cache Pool - 备份数据： 机械硬盘，Btrfs 文件系统，Unassigned Devices 容器和虚拟机本身以及需要经常访问的数据都放到 Cache Pool 中，其他绝大部分数据都在 Array 中，重要数据定时使用 rsync 备份到备份盘上并创建和保留最近 7 天的快照。 如果未来我的热数据量大到单盘放不下了，我就可以将 Cache Pool 改为 RAIDZ1 或 RAIDZ2 。 你可以评估一下你的使用需求场景是否与 unRAID 的设计使用场景匹配，如果不匹配就可以考虑其他系统方案，如果匹配就看是不是可以采用 unRAID 默认推荐的方案，特别是文件系统的选择。 |
 |
9
WizardLeo OP @locoz 感谢回复。如果把 mc 服务端拿出来放容器的话，需要自己做容器吧？我不太懂怎么搞😥
@qq979365509 感谢回复。如果是固态硬盘的话，三种文件系统里是 xfs 最好吗？我听说 zfs 全部功能会在 6.13 支持 @a632079 感谢回复。我之前缓存盘用 btrfs 也遭遇了一次毁灭性的事故，最终用只读模式把文件读出来了😂 @libook 感谢长篇回复！我在搭建这个设备的时候就考虑到了文件安全问题，ecc 内存和 ups 都备好了。就是冲着 zfs 的高级特性来的，现在还是打算用一下 zfs🤣应该后面就按照前文说的格式化磁盘了。 |
|
10
libook 317 天前
@WizardLeo #9
unRAID 的 ZFS 更多是对 Cache Pool 特性的一个扩展，对 unRAID 开发团队来说，可能他们的 Array 解决方案依然是核心功能。这也就是为什么 ZFS 有很多高级特性，但 unRAID 并没有全都引入，因为它本来就是用来满足 Cache Pool 的功能需求的，而非作为 unRAID 的主要的存储方案提供的。 如果你对 ZFS 感兴趣可以看看 TrueNAS Core / TrueNAS Scale 。 |
|
11
locoz 316 天前 1
@WizardLeo #9 你可以选择使用现成的镜像： https://github.com/itzg/docker-minecraft-server
如果多个服务端还想共用一个默认端口、依靠域名区分的方式对外服务，这个人也做了个工具： https://github.com/itzg/mc-router |
|
12
WizardLeo OP @locoz 收到！我尝试了一下一个叫“crafty”的 mc 服务器管理平台容器，io 性能突飞猛进。现在服务器貌似是直接在宿主机运行了，同一个包(比如说 e9e)启动速度快了 70%左右，tick time 减少了一半以上。现在使用 zfs 貌似还能直接把地图载到 zfs arc 里面，应该是彻底解决问题了。
|
|
13
locoz 310 天前
@WizardLeo #12 你在宿主机上直接用容器运行的时候，容器内的进程就是在宿主机上运行了，少了一层虚拟化的性能损耗提升肯定明显。MC 的地图加载速度实际上要求并不高，只要不是一群人跑图或者是跑图速度快到离谱的程度，随便一个 SATA SSD 的性能都可以满足，用更快的缓存感觉意义不是特别大。
|
 |
14
a393310872 270 天前
@WizardLeo 同样的提升在帕鲁上也是一样，开虚拟机跑 tick 明显高，无论是换虚拟网卡还是直通网卡都没用，或者说效果并不明显（但雾锁王国并不会），换成 docker 后问题解决，tick 就变的正常了
|
Select Language