Chiphell - 分享与交流用户体验

标题: 告别单盘组建TrueNAS SCALE终极家用OpenZFS File Server, VM & More [打印本页]

作者: jerrytsao 时间: 2022-3-26 20:14
标题: 告别单盘组建TrueNAS SCALE终极家用OpenZFS File Server, VM & More
本帖最后由 jerrytsao 于 2022-4-7 04:08 编辑

关于存储, 讨论的实在太多了, 我这里也分享一些个人感受

A. 单盘各自使用 vs 多盘以某种方式混在一起使用

在此之前, 我的HDD数据一直都以单盘的形式存在, 从12年前的1TB/2TB到后来的4TB, 8TB以及16TB, 且一直保留容量X2递增更换

主要原因有两点

1) 早期对各种RAID以及存储文件系统没有做深入研究, 只是觉得空气单盘如果坏了大不了开盘拿数据, 如果不重要的数据甚至可以直接不要了换新

2) 软RAID特别是Win OS RAID等脱离系统之后就要重新弄, 且OS出问题就容易挂, 硬RAID则直接不考虑, 卡贵而且折腾起来太麻烦

最近几年, 随着网速的加快, 下载4K UHD原盘文件夹动不动超80GB, 加上qBittorrent这个吃资源的家伙对单盘HDD造成了很大压力

日益觉得存储和PC一起有很重的累赘感和拖累感, 剥离开来是势在必行, 而和PC分家也意味着和单盘说再见

B. 磁盘冗余阵列(RAID)用什么模式, 普通标准RAID, 非标准RAID, 还是专门的存储文件系统?

说到RAID, 一个基本知识但很多人依旧混淆的概念 - RAID不是备份, RAID是为了Storage阵列有更强的Data Resiliency

Resiliency可以从好几方面来看, 冗余模式, 数据完整性, 纠错性能, 容错能力, 以及存储分层等

Win下软RAID刚上面提到了是一个相当不靠谱的选择, 除非上硬RAID, Storage Spaces虽不是传统RAID但差异不算太大且性能悲催

Linux下软RAID有众所周知的mdadm, 群晖的Synology Hybrid RAID(SHR)其实就是Linux软RAID魔改版

非标准RAID里面近年来比较火的有UnRAID, SnapRAID, FlexRAID等, 但总体来说这几个有各自的缺点, 且大多数对性能几乎无提升

存储文件系统方面则有Linux下的Btrfs, 多平台企业级存储ZFS, 以及近年来很多大规模阵列采用的分布式存储Ceph

选择建议

1) Budget用户或存储小白, 喜欢一块盘一块盘的添加, 且不关心性能, 可以选择SnapRAID

2) 不差钱且不喜欢太折腾, 直接无脑群辉, 利用其强大的软件优势

3) 喜欢折腾且精通Linux选择就很多了, ZFS, mdadm, Btrfs等等都可以

4) 喜欢折腾但不喜欢代码输入, 同时需要GUI可视化界面, 追求性能, 那就用TrueNAS CORE或者TrueNAS SCALE

TrueNAS CORE基于FreeBSD, 而基于Linux的TrueNAS SCALE随着将来效能优化会变得越来越强大, 推荐TrueNAS新用户直接上SCALE

C. 关于ZFS/OpenZFS/TrueNAS

TrueNAS是iXsystems下OpenZFS GUI操作系统品牌名, 旗下主要产品有TrueNAS CORE(原先的FreeNAS)和刚发布正式版没多久的TrueNAS SCALE

ZFS是Oracle甲骨文开发的文件系统, 自家用的专有文件系统叫Oracle ZFS, 而Port过来的开源版本就叫做OpenZFS, 目前依然在积极开发中

ZFS应该是当今最健壮的HDD存储文件系统, 但要玩爽ZFS有几个前提一定要先了解

1) 影响性能最大的因素永远是RAM主存, 所以成本计算上内存一定不能省, 具体容量根据你HDD Pool大小定, 但个人认为不应小于64GB

2) ZFS最早是针对HDD开发的文件系统, SSD并非最佳搭档, 特别是高性能PCIe Gen 4 SSD无法发挥其全部性能

好消息是即将推出的OpenZFS 3.0(TrueNAS要等到23年)对NVMe SSD甚至PMem做了大量新功能和优化, 今后用于SSD存储文件的前景相当乐观

3) ZFS在盘位上最好提前部署, 比如一期的实际可用容量是否够你用, 以及今后准备如何扩展加容量

从上图可以看到3.0版本会更新期待已久的RAID-Z单盘扩展, 虽然从目前测试看来我觉得体验一般, 但对预算紧缺组ZFS的人来说这绝对是天大的好消息

这里顺带说一下OpenZFS 2.1新增的dRAID vs RAID-Z

dRAID适合于一次性固定投入大量盘数的环境, 比如你一次性弄24-96盘, 以后不再增加

低于20盘数就没有必要走dRAID了, 而且短期内dRAID在同Pool下也无法扩展磁盘数量

RAID-Z适合分批次加同样磁盘vdev的用户, 比如第一次先弄12盘Vdev 1, 等钱包充足或者容量不够了再弄12盘在同Pool下添加Vdev 2

dRAID主要解决了很多人担忧的长时间Resilvering(ZFS重组)使得中途另外磁盘挂掉, 进而导致整个Pool Degraded的问题

但RAID-Z同样也有办法来减少风险, 那就是前几年新增的Allocation Classes

将Metadata放在专门的SSD Special Vdev大大加速了Resilvering时间, 同时可以指定<某个Block Size的文件运行在IOPS高太多的SSD上

另外注意RAID-Z适合于视频等大文件为主的流文件(也就是持续读写), 如果Pool纯粹用于数据库+小Block Size毫无疑问还是选择Mirror镜像

扯了这么多下面进入正文, 先来看下这台基本拉满的服务器配置

Case: Fractal Design Define 7 XL

PSU: Super Flower LEADEX G1000W

CPU: AMD EPYC Milan 7T83

MB: Supermicro H12SSL-NT Or ASRock Rack ROMED8-2T

HBA: 2*Broadcom 9400-16i

DRAM: 8*64GB=512GB Samsung DDR4-3200 2R RDIMM M393A8G40AB2-CWE

OS Boot: 2*Samsung PM9A3 1.92TB M.2 2-Way Mirror

Metadata Vdev: 3*Samsung PM9A3 3.84TB U.2 3-Way Mirror

Slog Vdev: 2*Intel Optane 900P 280GB U.2 2-Way Mirror

L2ARC: N/A

Data SSD: Memblaze PBlaze5 D700 11TB U.2

Data HDD: 24*Seagate X18 18TB

2块OS盘M.2 22110以及用于各种Vdev的6块2.5" U.2 SSD全家福

三块9400-16i, 上面两块是原厂货, 最上面那块之前故障了所以跑去海鲜市场买了一块

收到后发现"国产OEM仿品"(最下面那块)泛滥TB/海鲜/eBay, 不过固件/BIOS/EFI更新都正常, 也就将就着用吧

7XL总览

开机两块HBA检测

此处强烈推荐OS安装神器Ventoy, 只需点击一次安装, 放入ISO文件即可, 再也不用反复rufus做启动盘...

这次24块X18 ST18000NM000J有去年7月和去年11月两个Batch, 自带都还是SN01固件, 而官网有新固件SN02, 所以需要一个个手动升级

TrueNAS SCALE安装界面选择磁盘

新建Pool界面, 可以看到1个数据池下有Data, Cache, Log, Hot Spare, Metadata和Dedup共6种Vdev类型

Data顾名思义就是数据

Cache就是L2ARC二级读缓存, 一级缓存当然就是RAM

Log指的是Slog用于加速Sync同步写入速度

Hot Spare就是大家熟知的热备

Metadata即上面已经提到的Allocation Classes, 统称Special Vdev

Dedup AKA De-duplication数据去重, 属于变相的数据压缩, 一般不建议使用, 一方面会占用大量主存, 另一方面会降低性能

具体Vdev配置, 这里顺便说明选择上述硬件配置的理由

RAM: 8条64GB DDR4-3200 2R RDIMM, 512GB能满足500TiB Pool(1GB/1TB)的"坊间最佳要求", 无论科学与否内存越大对ZFS只有正作用

OS启动盘: 2块Samsung PM9A3 1.92TB M.2做2-Way镜像, 评测见此, 主要考虑22110+防掉电保护

Metadata Vdev: 3块Samsung PM9A3 3.84TB U.2做3-Way镜像, 评测见此, 一般来说Metadata容量可按0.3%去算

如果基本都是视频大文件所需要百分比更小, 但假如很多随机小块的话则可选择1%, 可以运行以下命令获取更准确的块大小统计

zdb -Lbbbs POOLNAME

复制代码

由于此Vdev是将原本放在HDD的Metadata移到随机IOPS快很多的SSD上, 一旦坏了整个Pool的数据也毁了, 需要至少2块组镜像, 推荐3-4块也不为过

Slog Vdev: 2块Intel Optane 900P 280GB U.2做2-Way镜像, 自从Optane SSD发布之后便成为ZFS Slog御用盘, 没有之一

最佳Slog盘当属P4801X 100GB, 这里选择900P 280GB主要同时兼顾容价比和耐久度

此Vdev可以随时删除, 因此镜像不是必须, 而容量则和网络直接相关, 10GbE理论上只需要5s*1.25GB/s=6.25GB

注意Slog只在Sync同步写时起作用, Async异步写时就是靠主存, 以下是关于Standard, Sync Always和Sync Disabled三者的区别

sync=standard: sync writes are written 2 times (first to LOG, second as normal write every ~5 seconds)
async write are written only once (every ~5 seconds)
sync=always: sync & async writes are written 2 times (first to LOG, second as normal write every ~5 seconds)
sync=disabled: sync & async writes are written only once (every ~5 seconds)

Cache Vdev: 无, L2ARC只在主存不够的情况下建议使用, 否则很可能会起反作用

Data SSD Vdev: 1块Memblaze PBlaze5 D700 11TB U.2, 评测见此

单独新建一个SSD单盘Pool, 主要原因是为了BT软件, 第一次组ZFS很容易忽略的情况是P2P所导致的磁盘碎片

一旦HDD池里用BT软件, 只有重写文件才能Defrag, 而由于ZFS本身COW特性就是"碎片"式文件系统, 等到后期容量不够用再整理是不可能的

有了SSD Pool, 意味着可以在qBittorrent里设置"Keep incomplete torrents in:"指向到SSD, 下载完毕后自动完整移到HDD Pool, 完美解决碎片化问题

Data HDD Vdev: 一期24盘组2个12-Wide RAID-Z2 Vdevs, 最大可用空间为325.2TiB(1MiB Record Size)和299.1TiB(128KiB Record Size)

家用一般只推荐Z2(Z1太危险, Z3没有必要), 12盘通常来说是Z2的宽度极限, 像16-24盘这样太宽的单Z2 Vdev只有可怜的单盘IOPS且安全系数直线下降

未来容量扩展其实相当方便, 添加12块同型号磁盘组新的Vdev, 然后加入到原有的Pool当中

如36盘组3个Vdevs可以达到487.8TiB(1MiB)和448.7TiB(128KiB), 而96盘组8个Vdevs则可以达到1,301.5TiB(1MiB)和1,197TiB(128KiB)

此种扩展方式的另一个优点是, 新增1个Vdev的同时可以增加一个单盘的IOPS, 对整个HDD Pool的随机性能都有帮助

Pool Status页面可以清晰查看Pool和Vdev的完整结构

Disks页面可以找到各磁盘的序列号, 容量, 以及所属Pool

开启SMART Tests后, 即可在Reporting页面查看各磁盘的温度信息

这里建议Scrub和SMART Long岔开两周各一次, 第1周某日Scrub, 第2周同日SMART, 第3周同日Scrub, 第4周同日SMART, 每月如此循环

Storage主页可以查Pool和Dataset的基本数据, 注意这里的可用容量299.1TiB是基于128KiB Record Size的预估

改成1MiB之后实际可用容量为325.2TiB, 但不会在ZFS上显示, 可以在文件信息里看到实际磁盘占用, 会比原本小一些

设置里的Boot页面可以看到当前OS盘里的TrueNAS系统版本和体积, 如果有过升级会保留之前的版本

Dataset页面设置一览, 主要修改Compression Level, Record Size, ACL Type和Metadata (Special) Small Block Size

首页信息全览

下一步是设置Sharing, 先弄个简单的SMB

为了不影响Root用户设置, Credentials下新建一个User, 默认打钩Samba Authentication

然后在Windows上映射磁盘即可

C8DH上只有2.5GbE, 随便测一下稳定在极限280MB/s上下

除了SMB之外, 还可以给ATV整个WebDAV, 或者弄个iSCSI Block Storage折腾更高的带宽和更低的延迟

SCALE的一大特点就是更多的Application, 默认很少只有7个(包括Plex, Nextcloud, Chia等), 需要在里面添加TrueCharts Catalog

添加完之后, 就拥有了多达194个App, 包括常用的TrueCommand, qBittorrent, Emby等等, 能涵盖各类需求, 比FreeBSD的Jail强大太多

SCALE相比CORE另一个优势当然就是Linux KVM了, 虽然目前还没法和VMWare之类相比, 但SCALE的潜力很大, 同OpenZFS一起拥有很高的天花板

2022-03-29 Update 10GbE

连上12900K默认+Z690 Formula的AQC113

未作任何巨帧等优化Windows 11初步跑10GbE SMB, 1MiB Record Size下LZ4要比ZSTD更快一些

Windows SMB默认Async写入, 所以不会经过900P加速, 但可以看到PM9A3的Special Vdev加速让整个HDD Pool随机性能直接变成SATA SDD级别

HDD Pool持续读取稳稳被10GbE限制

2022-04-06 Update 40GbE

因为有了sunneyboy的这个SCALE vs CORE帖子, 开始折腾之前扔在垃圾堆N年的"古董级"网卡

由于之前两块ConnectX-4 VPI MCX456A-ECAT 2*100GbE Lenovo OEM(4年前的测试见此)不知为何闲置着就挂了

反倒是更早eBay买的ConnectX-3 Pro VPI MCX354A-FCCT 2*40GbE还活着, 只能先将就用着

一上机发现网卡显示不出来, 但是Shell里输lspci能看到设备, Google后发现大概率是端口类型默认是IB的原因

突然想起来上次用mlxconfig改过端口是坏掉的100G, 这两块40G之前只在Windows下改过端口类型, 但并没有用mlxconfig修改并写入EEPROM

果断拔下插到Windows, 下载安装MFT(Mellanox Firmware Tools)工具包, 输入mlxconfig命令修改默认VPI(InfiniBand)为ETH(Ethernet)

mlxconfig -d mt4103_pciconf0 set LINK_TYPE_P1=2 LINK_TYPE_P2=2

复制代码

另外其实默认不改端口也可以显示出来, 就是需要在系统设置->高级里的Sysctl添加Variable, 和FreeBSD TrueNAS CORE下Tunables是一个道理

不过还是建议上面直接EEPROM里写入以太网的方法兼容性更好

sys.device.mlx4_core0.mlx4_port0 = eth
sys.device.mlx4_core0.mlx4_port1 = eth

复制代码

mlxconfig改完后重新插上就可以在TrueNAS SCALE自动显示40G ETH网卡了

手上DAC铜缆只有两条HPE OEM 845406-B21, 对应Mellanox MCP1600-C003 3米, 意外发现QSFP28 100G线材也能用在QSFP+ 40G端口上

由于QSFP+ 40G, QSFP28 100G, QSFP56 200G, QSFP-DD 400G以及QSFP-DD800 800G都采用了相同大小规格的收发器, 线缆向后兼容也并不意外

在Windows的MCX354A网卡上设置单独的网关10.0.0.X和IP 10.0.0.X, 并在TrueNAS端MCX354A改IP地址为10.0.0.X, 即可握手40GbE

如此就可以做到PC和TrueNAS之间走40GbE, 同时不影响PC和TrueNAS已有的10GbE和局域网内其它设备以及WAN外网的互联

这个时候在这台PC上可以通过两个IP地址进入TrueNAS Dashboard, 默认10GbE通过交换机的192.168.X.X, 以及网卡之间互插的10.0.0.X

我这边TrueNAS SCALE HDD 2*Z2 40GbE SMB测出来的极限为27GbE, 毕竟不能和多年FreeBSD优化相比, 加上Win本身的限制, 不过会慢慢会优化的

CDM v8.0.4跑1GiB(SMT On), Special Vdev提升整个HDD Pool部分随机性能>SATA SSD, 在没有RDMA的情况下算是不错了

[Read]
  SEQ 1MiB (Q=  1, T= 1):  2242.112 MB/s [ 2138.2 IOPS] < 467.34 us>
  SEQ 1MiB (Q=  8, T= 1):  3196.626 MB/s [ 3048.5 IOPS] <  2615.14 us>
  RND 4KiB (Q=  1, T= 1): 80.535 MB/s [  19661.9 IOPS] < 50.75 us>
  RND 4KiB (Q= 32, T=16): 435.586 MB/s [ 106344.2 IOPS] <  4803.52 us>

[Write]
  SEQ 1MiB (Q=  1, T= 1):  1176.851 MB/s [ 1122.3 IOPS] < 890.14 us>
  SEQ 1MiB (Q=  8, T= 1):  1669.667 MB/s [ 1592.3 IOPS] <  4985.51 us>
  RND 4KiB (Q=  1, T= 1): 46.335 MB/s [  11312.3 IOPS] < 88.27 us>
  RND 4KiB (Q= 32, T=16): 143.955 MB/s [  35145.3 IOPS] < 13889.98 us>

[Mix] Read 70%/Write 30%
  SEQ 1MiB (Q=  1, T= 1):  1746.924 MB/s [ 1666.0 IOPS] < 599.57 us>
  SEQ 1MiB (Q=  8, T= 1):  2363.504 MB/s [ 2254.0 IOPS] <  3541.11 us>
  RND 4KiB (Q=  1, T= 1): 49.138 MB/s [  11996.6 IOPS] < 83.01 us>
  RND 4KiB (Q= 32, T=16): 177.827 MB/s [  43414.8 IOPS] < 11661.94 us>

TrueNAS SCALE HDD 2*Z2 -> PC拷贝88GB的数个大视频文件, 平均在2.4GB/s上下, 为消除任何Q1T1读写瓶颈PC端采用的磁盘是P5800X 1.6TB

PC -> TrueNAS SCALE HDD 2*Z2拷贝88GB的数个大视频文件, 1MiB Record Size + LZ4实时压缩导致速度稍慢, 平均在1.4GB/s上下

这一波测试之后机器应该不会移到弱电箱而是在书房待着了, 接下来准备换上200GbE互联折腾RDMA和NVMe-oF Target/Initiator Offloads

作者: LunaSea 时间: 2022-3-26 20:15
J叔沙发

作者: gtx9 时间: 2022-3-26 20:18
估计是目前CHH最强NAS配置了

作者: ArmStronger 时间: 2022-3-26 20:20
前排膜拜J叔

作者: 醉酒棕熊 时间: 2022-3-26 20:21

门槛太高
内卷严重

作者: goat 时间: 2022-3-26 20:21
unraid直接不建议是因为收费吗

作者: wesleyxy 时间: 2022-3-26 20:24

醉酒棕熊发表于 2022-3-26 20:21
门槛太高
内卷严重

熊总全ssd啊

作者: sky也许 时间: 2022-3-26 20:30

后排支持

作者: dsboylw 时间: 2022-3-26 20:31
我也就买卖花生红枣大杏仁了~

看着500多G内存脑阔疼~

作者: lovesb 时间: 2022-3-26 20:50
要是SCALE在smb上rdma跑40/56g就好了

作者: osmud 时间: 2022-3-26 20:55
这个系统最难用的是他的Docker，不知道为什么要上个K3S，对一般人来说简直是个灾难。本来想把K3S卸载了，貌似ZFS是跑在K3S里的。而且最近系统自动更新一直失败，扶了墙也不行。

作者: linchen0950 时间: 2022-3-26 21:00
超过26个硬盘，编号是sdaa开始吗

作者: kpchan 时间: 2022-3-26 21:01
"家用”的标准又被J叔无情地拔高了。。。。。这作业根本抄不起。只能默默收藏。。

作者: kpchan 时间: 2022-3-26 21:03

gtx9 发表于 2022-3-26 20:18
估计是目前CHH最强NAS配置了

自信点。。。。。

应该没有之一了。。。。

作者: chin39 时间: 2022-3-26 21:03
大佬这套配置看着口水哗哗的，好奇dedup打开同时dedup盘是傲腾的情况。

作者: oldnetdog 时间: 2022-3-26 21:17
这个机箱不是只能18个3.5的HDD吗？怎么可以安装24块盘的？

作者: jop 时间: 2022-3-26 21:23

这配置，强无敌。。。。

作者: Juzi丶 时间: 2022-3-26 21:27
本帖最后由 Juzi丶于 2022-3-26 21:31 编辑

scale的性能至少比core差三分一
很明显一点就是就算samba在linux用了vfs_io_uring，4k的iops还是比freebsd下慢一倍
还有openzfs在linux上的arc性能也比freebsd差

至于碎片问题这个是不需要考虑的问题，哪怕是100%跨度的块也只会是硬盘内外圈速度的问题

并不推荐大于128KiB的记录大小
大的记录大小带来相应的就是块读写时间增加
这会导致在机械盘上的大跨度的iops骤降
而且哪怕不是大跨度读写性能也不如128KiB

special vdev设置存取32KiB及以内的块可以释放机械盘上iops，某些场景下可以带来100%的性能提升

作者: sc80t 时间: 2022-3-26 21:32
硬盘温度不错，环境温度是多少，12cm风扇开的多少转？

作者: 有只老虎 时间: 2022-3-26 21:36

oldnetdog 发表于 2022-3-26 21:17
这个机箱不是只能18个3.5的HDD吗？怎么可以安装24块盘的？

硬盘架上只能放16个

作者: isail 时间: 2022-3-26 21:42
提示: 作者被禁止或删除内容自动屏蔽

作者: leeosx 时间: 2022-3-26 21:43

lovesb 发表于 2022-3-26 20:50
要是SCALE在smb上rdma跑40/56g就好了

10g都很难跑满

作者: oldnetdog 时间: 2022-3-26 21:45

有只老虎发表于 2022-3-26 21:36
硬盘架上只能放16个

J叔不是写了24块盘，不知道咋安装上的。

作者: jerrytsao 时间: 2022-3-26 21:46
本帖最后由 jerrytsao 于 2022-3-26 21:48 编辑

goat 发表于 2022-3-26 20:21
unraid直接不建议是因为收费吗

UnRAID更多的是Marketing, 就像一个魔改版JBOD, Parity不完全, Reliability也不够, 还要付费, 唯一的强项可能就是那个Community和Apps

作者: cyberspace13 时间: 2022-3-26 21:46
k3s接受不能，这个算是最大槽点。
4k的原盘最大也不会超200m吧，其实大容量单盘还是够用的

作者: BONBONBON 时间: 2022-3-26 21:53
d7xl还有渠道买吗

作者: IPP 时间: 2022-3-26 21:56
7T83的NAS...太强了…

作者: jameszjq 时间: 2022-3-26 22:07
我也不知道自己为什么要点收藏，我又玩不起这个配置。

作者: nlnjnj 时间: 2022-3-26 22:30
9400 这个国产的和原装的有什么区别啊，我也买了国产的，是OEM还是？

作者: Smartcraft 时间: 2022-3-26 22:34

lovesb 发表于 2022-3-26 20:50
要是SCALE在smb上rdma跑40/56g就好了

能启用RDMA需要点挺多的。
- 如果是RoCEv1， Ethernet Switch需要支持FPC。
- 如果是RoCEv2， Switch/Router禁止重排序udp packet。路由需要支持ECN。
- 软件需要基于RDMA接口重新开发程序，Windows Server 2019 SMB是支持的。但是TrueNAS SMB端未必支持啊。
- NiC本身需要有RDMA asic。

以上硬件投入挺大的。如果都达成，server端是RAM DISK，client可以直接泡满40GbE。

作者: T.JOHN 时间: 2022-3-26 22:39
我并不觉得scale性能会比core差到哪里去，openzfs代码统一以后区别只是freebsd和linux两个底层操作系统较量。测试zfs性能也不可能用samba，而是fio测本地性能
在代码一致的情况下arc命中率是没区别的，而性能差异只能是操作系统内核层面的差异，即便bsd内存管理更高效也高了极其有限。至于生态linux不是针对谁，服务器领域其他操作系统都是垃圾。

如果只用来存视频或大文件recordsize设置为1MiB是很合理，这样scrub做checksum的时候效率是128k的8倍，只有专门跑mysql这种数据库会调到16k。而且recordsize可以随时改，只有ashift无法改。不过以楼主的硬件，跑读写密集的工作都在ssd上，用不到这个pool。

除了压缩方式可以从lz4改成zstd，楼主的方案基本没什么可优化的地方了。

楼主的方案过设计了，zfs其实最朴实就是64G~1T ECC mem+HDD x N+16G 傲腾 slog就行了，除了重建的时候CPU占用高一些，其他时候不太占资源

作者: dsboylw 时间: 2022-3-26 23:00

oldnetdog 发表于 2022-3-26 21:17
这个机箱不是只能18个3.5的HDD吗？怎么可以安装24块盘的？

水冷机上不是放了一摞硬盘吗？箱子也没盖盖子，应该是minisas拉出来一根

作者: jerrytsao 时间: 2022-3-26 23:12

linchen0950 发表于 2022-3-26 21:00
超过26个硬盘，编号是sdaa开始吗

嗯, Linux都一样的

作者: jerrytsao 时间: 2022-3-26 23:14

oldnetdog 发表于 2022-3-26 21:45
J叔不是写了24块盘，不知道咋安装上的。

晚些会定制个32盘机箱, 目前8盘放在外面的笼子, 不想用机柜...

作者: 堕天使星颖 时间: 2022-3-26 23:23
FlexRAID官网都没了。。

作者: 雨前龙井 时间: 2022-3-26 23:24

豪华

作者: jerrytsao 时间: 2022-3-26 23:34

堕天使星颖发表于 2022-3-26 23:23
FlexRAID官网都没了。。

这东西一直没细看, 已经Dead了

推荐列表里删掉

作者: jerrytsao 时间: 2022-3-26 23:42
本帖最后由 jerrytsao 于 2022-3-26 23:45 编辑

T.JOHN 发表于 2022-3-26 22:39
我并不觉得scale性能会比core差到哪里去，openzfs代码统一以后区别只是freebsd和linux两个底层操作系统较量 ...

选ZSTD无后缀, ZSTD-1还是ZSTD-19, 看了些文档还不是很明确, 7T83确实应该利用其压缩/解压性能优势

作者: goat 时间: 2022-3-26 23:43

jerrytsao 发表于 2022-3-26 21:46
UnRAID更多的是Marketing, 就像一个魔改版JBOD, Parity不完全, Reliability也不够, 还要付费, 唯一的强项 ...

但是现在snapraid要跑crontab，flex好像几乎处于停滞状态。开箱即食，又可以整合一堆乱乱七八糟容量且带实时校验的没选了

哪位大佬快点整合一个带mergerfs的nas系统吧

作者: leeosx 时间: 2022-3-26 23:53

T.JOHN 发表于 2022-3-26 22:39
我并不觉得scale性能会比core差到哪里去，openzfs代码统一以后区别只是freebsd和linux两个底层操作系统较量 ...

大佬。我全默认设置 18个18t...为啥samba共享下面读写速度基本上就是600/200的样子raidz2...文件是单个60g的
64g内存

作者: blasaw 时间: 2022-3-27 00:36
这机箱是怎么装24个机械盘的。。

作者: Juzi丶 时间: 2022-3-27 05:57

jerrytsao 发表于 2022-3-26 23:42
选ZSTD无后缀, ZSTD-1还是ZSTD-19, 看了些文档还不是很明确, 7T83确实应该利用其压缩/解压性能优势 ...

zstd速度太慢
而且对于多媒体内容的压缩率是毫无意义的（因为根本没得压）
但不能也不建议关闭压缩
所以默认lz4就是最好使的

https://github.com/openzfs/zfs/pull/10278
https://github.com/openzfs/zfs/pull/12805

作者: Juzi丶 时间: 2022-3-27 06:12

T.JOHN 发表于 2022-3-26 22:39
我并不觉得scale性能会比core差到哪里去，openzfs代码统一以后区别只是freebsd和linux两个底层操作系统较量 ...

至于性能这个不信的话你可以自己测一下看看，我又不是瞎吹

就记录大小来举例

1MiB的块大小就算是最外圈拿常见的HC320来算也需要200ms以上的io时间，而128KiB则是18±6ms之间

作者: kingkiss 时间: 2022-3-27 08:23
期待关于网络配置和测试的文章，我也组了个TRUENAS SCALE，全NVME固态池25G网卡SMB读取只能跑1.2G/S还很不稳定，写入只有500M-800/S，一直都没弄明白为什么。

作者: T.JOHN 时间: 2022-3-27 10:44

jerrytsao 发表于 2022-3-26 23:42
选ZSTD无后缀, ZSTD-1还是ZSTD-19, 看了些文档还不是很明确, 7T83确实应该利用其压缩/解压性能优势 ...

偏向省空间选5，偏向性能得选1，或者负值。可以参考 https://community.centminmod.com ... p2-vs-xz-etc.18669/

zstd算是19/20年引入zfs最重要两个特性之一了，同期还有个特性就是本地加密，类似bitlocker，0.8.0引入，0.8.4切换成aes-256-gcm算法。不过它没bitlocker方便，把秘钥存在微软服务器上，得把一长串字符给本地记下来，否则无了。

作为存储文件系统能省空间是很有必要的。在此之前lz4和gzip是zfs主要压缩方式，所以他主要用来对标gzip，比gzip压缩率高，占用资源更少，解压速度远高于gzip，属于gzip完全上位的算法。

facebook 2015年开始从新造轮子主要是它网站fb+ins数据量实在太大了，压缩能省非常多得成本，但又不能影响用户体验，所以设计一个压缩率优秀，但更重要的是可以"在线解压"的压缩方式，也就是解压速度要能很快加载这些网页内容。所以和传统备份压缩算法追求极致压缩率的bzip，xz之类目的不一样。我觉得是很适合需要在线读取内容的服务器用，也不用我觉得，反正facebook验证过显然很靠谱，至于lz4基本就没什么压缩，聊胜于无的类型。

不过楼上说了对，如果全视频文件，是没什么可以压的了，而且recordsize设成了1MiB就更没什么可以压的了，甚至可以不开压缩。不过我觉得也不能所有文件都是h.264/hevc之类的视频，总要有些文档之类的，而且那么强的性能开lz4肯定不如zstd。

作者: T.JOHN 时间: 2022-3-27 10:56

Juzi丶发表于 2022-3-27 06:12
至于性能这个不信的话你可以自己测一下看看，我又不是瞎吹

就记录大小来举例

视频文件不需要高IOPS，而且楼主qbit临时文件放在ssd上，下载下来得视频就没有随机读取，自然也不需要寻道。

我不是没看过zfs性能测试，ddg搜索前三条都是一个人测的 https://openbenchmarking.org/result/2109269-IB-DEBXCPNGT86
它测的都是网络性能，是scale和core综合对比。但zfs本地性能它没测，显然这里有两部分，一部分是zfs本地性能，另一部分是网络性能iscsi，nfs和smb，第二部分显然和zfs无关，是应用层的事情了。像我这种用zfs，不用truenas显然不能被它的测试代表

作者: T.JOHN 时间: 2022-3-27 12:24
本帖最后由 T.JOHN 于 2022-3-27 12:38 编辑

leeosx 发表于 2022-3-26 23:53
大佬。我全默认设置 18个18t...为啥samba共享下面读写速度基本上就是600/200的样子raidz2...文件是单个60 ...

先查本地性能再查smb问题

1. 本地性能可以用fio测

fio -ioengine=libaio -bs=128k -direct=1 -thread -rw=read -filename=/zpool/test -name="BS 128k read test" -iodepth=1 -numjobs=1 -size=100G -runtime=60

复制代码

rw 把read改成write就是写
filename - 你读的时候可以找个池里大文件读。写的时候文件名别和其他不要一样，否则会覆盖掉
size - 是文件大小，你的盘多，100G写入很快的，你可以调整
runtime - 是最多跑1分钟

18个18T，我不知道你的盘结构，假设你是raidz2，就是16个盘工作，单盘算平均150mb/s，连续读的速度2.4G，算上损耗*0.8，应该2G左右，写会比读慢，大约就一半。

2. samba可以先更新下版本，输入smbd -V，如果太老更新下
(, 下载次数: 116)
其次看协议是否都正常开启了，用nmap扫描，

nmap --script smb-protocols IP

复制代码

IP改成你服务器局域网IP

现在基本都不用1.0了，你尽量保证3.11开启以适配你win10或者win11

然后你可以调优smb参数，配置文件一般在/etc/samba/smb.conf

use sendfile = yes
server multi channel support = yes
aio read size = 1
aio write size = 1
write cache size = 262144 -- 这一条参数在4.12版本以后没了
min receivefile size = 16384
getwd cache = yes
unix extensions = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY

复制代码

这些是我用的，具体说明参考
https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html
https://wiki.archlinux.org/title/Samba_(%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87)

编辑：注释write cache size参数为无效

作者: leeosx 时间: 2022-3-27 12:26

T.JOHN 发表于 2022-3-27 12:24
先查本地性能再查smb问题

1. 本地性能可以用fio测

谢谢。。我晚点从新装个truenas scale试试看。。谢谢

作者: rakuhin 时间: 2022-3-27 18:22
好贴，不知道在esxi下装truenas scale会不会有性能损失，比较习惯用esxi装虚拟机。

作者: kingkiss 时间: 2022-3-27 19:02

T.JOHN 发表于 2022-3-27 12:24
先查本地性能再查smb问题

1. 本地性能可以用fio测

大神按照你的方法用FIO测试了一下各个池读取都正常但是写入诡异的只有430MB/S左右，一个8盘HDD raidz2,一个4盘U2 raidz1,不知道咋回事

作者: T.JOHN 时间: 2022-3-27 19:51
本帖最后由 T.JOHN 于 2022-3-27 19:53 编辑

kingkiss 发表于 2022-3-27 19:02
大神按照你的方法用FIO测试了一下各个池读取都正常但是写入诡异的只有430MB/S左右，一个8盘HDD raidz2, ...

上面给的命令是测区块大小128k，单线程，单队列深度的吞吐量。

8盘HDD raidz2 430MB/S偏低，但我不能说不正常。我6盘hc320 mirror大概是544MiB/s (571MB/s)，供你参考。如果你想好看，可以把numjob调到2甚至更多，然后增加个参数-group_reporting，你就会看到吞吐量显著提升，因为是多线程速度。如果想看raidz2性能，你尝试BS设成1M，iodepth适当增加，比如4/8/16。

fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=write -filename="/storage/test" -name="BS 4k write test" -iodepth=1 -numjobs=1 -size=10G -runtime=60 ###测试命令
BS 1M write test: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
fio-3.7
Starting 1 thread
Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=551MiB/s][r=0,w=141k IOPS][eta 00m:00s]
BS 4k write test: (groupid=0, jobs=1): err= 0: pid=7595: Mon May 18 09:42:34 2020
write: IOPS=139k, BW=544MiB/s (571MB/s)(10.0GiB/18809msec)
slat (usec): min=3, max=2060, avg= 6.11, stdev= 9.35
clat (nsec): min=591, max=167075, avg=713.06, stdev=690.50
lat (usec): min=4, max=2068, avg= 6.91, stdev= 9.45
clat percentiles (nsec):
| 1.00th=[ 604], 5.00th=[ 612], 10.00th=[ 612], 20.00th=[ 620],
| 30.00th=[ 620], 40.00th=[ 628], 50.00th=[ 652], 60.00th=[ 684],
| 70.00th=[ 700], 80.00th=[ 700], 90.00th=[ 716], 95.00th=[ 796],
| 99.00th=[ 1144], 99.50th=[ 1512], 99.90th=[12480], 99.95th=[13248],
| 99.99th=[17536]
bw ( KiB/s): min=518648, max=644352, per=99.95%, avg=557217.08, stdev=24743.32, samples=37
iops : min=129660, max=161088, avg=139304.27, stdev=6185.89, samples=37
lat (nsec) : 750=94.30%, 1000=4.04%
lat (usec) : 2=1.25%, 4=0.05%, 10=0.06%, 20=0.30%, 50=0.01%
lat (usec) : 250=0.01%
cpu : usr=17.50%, sys=81.11%, ctx=7348, majf=0, minf=105
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,2621440,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=544MiB/s (571MB/s), 544MiB/s-544MiB/s (571MB/s-571MB/s), io=10.0GiB (10.7GB), run=18809-18809msec

复制代码

U.2盘你测错目录了？没道理那么低的，除非你CPU 100%满了。U.2你可以尝试把iodepth调到32再测一遍，和上面一样，numjob调高后你会看到很爆炸的数据，甚至超过理论值。另外你的系统是裸装的还是虚拟机直通的？虚拟机会有损失，可能各种各样问题，建议裸系统测，以下9200max的单盘zfs数据供你参考

[root@server ~]# fio -ioengine=libaio -bs=128k -direct=1 -thread -rw=write -filename=/NVMe/test -name="BS 128k write test" -iodepth=32 -numjobs=1 -size=10G -runtime=60 -group_reporting
BS 128k write test: (g=0): rw=write, bs=(R) 128KiB-128KiB, (W) 128KiB-128KiB, (T) 128KiB-128KiB, ioengine=libaio, iodepth=32
fio-3.19
Starting 1 thread
BS 128k read test: Laying out IO file (1 file / 10240MiB)
Jobs: 1 (f=1): [W(1)][100.0%][w=1628MiB/s][w=13.0k IOPS][eta 00m:00s]
BS 128k read test: (groupid=0, jobs=1): err= 0: pid=383810: Sun Mar 27 19:32:04 2022
write: IOPS=16.5k, BW=2058MiB/s (2158MB/s)(10.0GiB/4976msec); 0 zone resets
slat (usec): min=27, max=480, avg=58.48, stdev=39.37
clat (usec): min=2, max=5006, avg=1883.69, stdev=624.91
lat (usec): min=36, max=5153, avg=1942.43, stdev=641.04
clat percentiles (usec):
| 1.00th=[ 1057], 5.00th=[ 1172], 10.00th=[ 1237], 20.00th=[ 1336],
| 30.00th=[ 1450], 40.00th=[ 1582], 50.00th=[ 1696], 60.00th=[ 1876],
| 70.00th=[ 2147], 80.00th=[ 2442], 90.00th=[ 2835], 95.00th=[ 3097],
| 99.00th=[ 3589], 99.50th=[ 3818], 99.90th=[ 4424], 99.95th=[ 4621],
| 99.99th=[ 4883]
bw ( MiB/s): min= 1639, max= 2870, per=100.00%, avg=2082.28, stdev=528.17, samples=9
iops : min=13114, max=22964, avg=16658.11, stdev=4225.28, samples=9
lat (usec) : 4=0.01%, 50=0.01%, 100=0.01%, 250=0.01%, 500=0.01%
lat (usec) : 750=0.01%, 1000=0.01%
lat (msec) : 2=64.79%, 4=34.98%, 10=0.21%
cpu : usr=8.36%, sys=66.07%, ctx=13714, majf=0, minf=2113
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
issued rwts: total=0,81920,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=32
Run status group 0 (all jobs):
WRITE: bw=2058MiB/s (2158MB/s), 2058MiB/s-2058MiB/s (2158MB/s-2158MB/s), io=10.0GiB (10.7GB), run=4976-4976msec

复制代码

作者: kingkiss 时间: 2022-3-27 19:57
本帖最后由 kingkiss 于 2022-3-27 20:01 编辑

T.JOHN 发表于 2022-3-27 19:51
上面给的命令是测区块大小128k，单线程，单队列深度的吞吐量。

8盘HDD raidz2 430MB/S偏低，但我不能说 ...

用新的代码测试了一下，写入速度还是只有500M/S，盘是铠侠CD6 7.68T 4个，组的raidz1,读取速度倒是正常的，另外一个两盘PM1733组的mirror池也一样写入只有450MB/S

作者: kaixin_chh 时间: 2022-3-27 20:02
神贴留个名，等以后发达了再来抄作业

作者: T.JOHN 时间: 2022-3-27 20:25

kingkiss 发表于 2022-3-27 19:57
用新的代码测试了一下，写入速度还是只有500M/S，盘是铠侠CD6 7.68T 4个，组的raidz1,读取速度倒是正常的 ...

读速度正常说明硬件都没问题，你所有池的写卡450MB/S就很奇怪了，所以我觉得测错目录了，除此之外我想不出啥原因了。有report没？我怕U.2利用率都没10%，

解决办法可能把zfs版本升级一下可能解决，zfs -V可以看版本，最新稳定版本是2.0.7或2.1.4

作者: kingkiss 时间: 2022-3-27 20:46

T.JOHN 发表于 2022-3-27 20:25
读速度正常说明硬件都没问题，你所有池的写卡450MB/S就很奇怪了，所以我觉得测错目录了，除此之外我想不 ...

(, 下载次数: 109) (, 下载次数: 112) (, 下载次数: 125) (, 下载次数: 109)

我也觉得很奇怪，一直找不到原因

作者: T.JOHN 时间: 2022-3-27 21:36

kingkiss 发表于 2022-3-27 20:46
我也觉得很奇怪，一直找不到原因

你写的时候clat percentiles(us)是HDD水平，lat(msec) 10=89.7%，意思延时总体是10ms，我看了下我之前机械单盘测试结果就是这水平，显然你写在了HDD的池子里。你可以再测一次，跑机箱旁边听听声音就知道了，必定有硬盘咔咔的声音。

你读的时候lat(nsec) 500=93.34%，意思是总体延时500ns，属于SSD水平。500ns和10ms差了2万倍。

至于为啥你读写路径一样，却没写到SSD池，我也不知道。你可以用

zfs get mountpoint

复制代码

检查挂载点，别把固态池放在机械池的子目录下，也许能解决问题。

作者: jerrytsao 时间: 2022-3-27 23:04
本帖最后由 jerrytsao 于 2022-3-27 23:28 编辑

T.JOHN 发表于 2022-3-27 10:44
偏向省空间选5，偏向性能得选1，或者负值。可以参考 https://community.centminmod.com/threads/round-4- ...

每个原盘文件夹下(除BDMV子文件夹之外)有一些小文件, 其它基本都是视频文件了

反正CPU性能高, 主存容量也够大, 我直接选了ZSTD-19, 对视频文件也没啥影响

作者: T.JOHN 时间: 2022-3-28 00:26

jerrytsao 发表于 2022-3-27 23:04
每个原盘文件夹下(除BDMV子文件夹之外)有一些小文件, 其它基本都是视频文件了

反正CPU性能高, 主存容量 ...

19我只能说充分利用CPU

scrub和smart长测我觉得不用两周一次那么频繁的，一个月一次就很充分了。白嫖王是万年不维护才丢的数据，一方面WD和ST两家的企业盘都很可靠，另一方面有ECC内存出错概率很低。
主要smart长测的时候真的非常吵，尤其盘多情况下，18T估计要20小时+，我已经懒到半年测一次了，平时用10天一次的短测替代。

作者: jerrytsao 时间: 2022-3-28 00:38

T.JOHN 发表于 2022-3-28 00:26
19我只能说充分利用CPU
scrub和smart长测我觉得不用两周一次那么频繁的，一个月一次就很充分了。白 ...

建议不错

作者: 风车车 时间: 2022-3-28 01:25
风车车看不懂这些，因为他买不起你们这些高端电脑！

作者: zexin4 时间: 2022-3-28 08:20
围观一下，太强了。
直接接在pcie转接U.2的卡上那6块盘挨的那么近会不会散热有问题啊

作者: nichfung 时间: 2022-3-28 08:28
这个厉害，太强了

作者: jerrytsao 时间: 2022-3-28 16:02
本帖最后由 jerrytsao 于 2022-3-28 16:10 编辑

T.JOHN 发表于 2022-3-28 00:26
19我只能说充分利用CPU
scrub和smart长测我觉得不用两周一次那么频繁的，一个月一次就很充分了。白 ...

小试了下视频文件ZSTD-19是毫无意义了, 且传输变得非常不稳定, 我感觉TrueNAS似乎无法吃CPU多线程?

目测只有LZ4和ZSTD无后缀里二选一, ZSTD Level 1-5之间差异也不大, 另外好像ZSTD并不是一定比LZ4压缩比更高?

作者: T.JOHN 时间: 2022-3-28 17:21

jerrytsao 发表于 2022-3-28 16:02
小试了下视频文件ZSTD-19是毫无意义了, 且传输变得非常不稳定, 我感觉TrueNAS似乎无法吃CPU多线程?

目测 ...

如果实测LZ4比ZSTD还好的话，那肯定用LZ4了，虽然这个结果和我测得不一样。

是否支持多线程取决于Truenas带的软件二进制包，现在lz4和zstd都支持多线程的。比如我现在用的centos 8 stream版本自带的是v1.8.3，当启用压缩时候，zfs会调用它，但至于用不用多线程，zfs的代码说了算，要么给用户一个设置选项，实际上貌似没有。
https://github.com/lz4/lz4/issues/807#issuecomment-549481307

TrueNAS论坛上最近的测试比较20年做的：
https://www.truenas.com/community/threads/lz4-vs-zstd.89400/

我回帖之前做了下测试
storage是我zpool目录，我没用压缩，空间够。分别用 1.切尔诺贝利视频和 2.centOS IOS安装镜像做的测试
测试命令，0和5分别是压缩起始和结束级别

zstd/lz4 -b0 -e5 /文件

复制代码

这样你就不用在zpool里面改来改去了，很直观看到你机器压缩性能的速度。这里只用单线程的，因为zstd-cli支持多线程调用，lz4-cli不支持，单线程也方便控制变量看速度。

可以看到ISO文件压缩以后节省6%-9.5%空间，而且zstd更好，解压速度不如lz4，但3.5+GB速度不影响传输，除非网卡是40GB的。考虑到压缩速度，zstd选择1-2就很好，lz4也是1-2最好

压视频就坑爹了，lz4压缩完以后体积比之前更大，显然不能用了。zstd起码比原来小一丢丢，但压缩率连0.1%都没，所以视频文件没啥可压缩的。

你这样测一下会比在windows里面看体积更准也更直观

作者: kingkiss 时间: 2022-3-28 18:54
本帖最后由 kingkiss 于 2022-3-28 19:29 编辑

T.JOHN 发表于 2022-3-27 21:36
你写的时候clat percentiles(us)是HDD水平，lat(msec) 10=89.7%，意思延时总体是10ms，我看了下我之前机 ...

我把fio命令里面的/zpool/GAMES替换成/mnt/GAMES写入速度就正常了，很神奇。 (, 下载次数: 129)
看来应该是truenas 共享的问题了，我ISCSI和SMB用crystaldisk mark测试读取有1.7G/S到2.5G/S，但是实际读取只有1G/S，写入甚至只有400M/S左右

作者: mkkkno1 时间: 2022-3-28 19:07

goat 发表于 2022-3-26 23:43
但是现在snapraid要跑crontab，flex好像几乎处于停滞状态。开箱即食，又可以整合一堆乱乱七八糟容量且带 ...

试试OMV（openmediavault）啥，虽然我用的是ubuntu+snapraid+mergerFS，因为我装OMV不是这里有点问题就是那里有点问题。

作者: jerrytsao 时间: 2022-3-28 19:36
本帖最后由 jerrytsao 于 2022-3-28 19:42 编辑

T.JOHN 发表于 2022-3-28 17:21
如果实测LZ4比ZSTD还好的话，那肯定用LZ4了，虽然这个结果和我测得不一样。

是否支持多线程取决于Truena ...

感谢测试, 你这个应该是128KiB Record Size下的吧, 我刚才还是在Win下SMB简单测试了下128KiB, LZ4倒没有压缩变大的情况

首先7T83线程占用没啥大问题, 是昨晚观察错误

其次确认1MiB对CPU的压力相比128KiB大很多, 毕竟128K下视频文件几乎没有压缩, 128K下开ZSTD-19传输就比较稳定, 只有稍多一丢丢波动

我这数据肯定选1MiB, Google一搜有太多测试证明1MiB大多数情况下没有副作用, 除非全是数据库小文件, 我还是选ZSTD无后缀好了

作者: T.JOHN 时间: 2022-3-28 20:02

kingkiss 发表于 2022-3-28 18:54
我把fio命令里面的/zpool/GAMES替换成/mnt/GAMES写入速度就正常了，很神奇。
看来应该是truenas 共享的问 ...

fio命令肯定要用真实路径/挂载点，不能用GUI里面显示路径。我写的那个zpool是举例用的，如果你输入了相当于在linux根目录下测试，你可以ls /zpool看到你之前留下的测试文件，根目录等于是在系统盘里面读写。

共享的话理论你iscsi或smb的crystal读写测试应该是和实际传输一样的，如果速度不达标参考上文smb优化或者你换个操作系统，用linux做客户端测下也许能提速

作者: T.JOHN 时间: 2022-3-28 20:10

jerrytsao 发表于 2022-3-28 19:36
感谢测试, 你这个应该是128KiB Record Size下的吧, 我刚才还是在Win下SMB简单测试了下128KiB, LZ4倒没有 ...

是的，我是用默认128KiB做的测试，看来应该是recordsize差异造成的测试结果不同。
看来1MiB确实非常适合存视频，size on disk省了好多（如果是真省的话）。副作用就是之前说的降低IOPS，不适合数据库16k小文件，不过不是你的使用场景，无需考虑。

作者: goat 时间: 2022-3-28 21:41

mkkkno1 发表于 2022-3-28 19:07
试试OMV（openmediavault）啥，虽然我用的是ubuntu+snapraid+mergerFS，因为我装OMV不是这里有点问题就是 ...

omv看功能里没提可以合并不同vol。我主要需求就是一堆旧硬盘塞归档，要求带校验。目前符合需求有人维护的也就unraid

。其实snapraid+mergerFS是最经济+合理，但是因为万一手贱更新/bug导致cron没跑，又有硬盘下线就

作者: mkkkno1 时间: 2022-3-28 21:46

goat 发表于 2022-3-28 21:41
omv看功能里没提可以合并不同vol。我主要需求就是一堆旧硬盘塞归档，要求带校验。目前符合需求有人维护的 ...

你搜索下omv+mergerFS 呀。肯定可以，不过要装omv-extras，而且名字变成了unionfilesystem

作者: Mufasa 时间: 2022-3-28 21:53
这个门槛确实太高了。。。。

TrueNAS的权限系统折腾得头大，后来删除不要了，装Windows完事。

作者: goat 时间: 2022-3-28 21:56

mkkkno1 发表于 2022-3-28 21:46
你搜索下omv+mergerFS 呀。肯定可以，不过要装omv-extras，而且名字变成了unionfilesystem ...

thx，等有时间再折腾了

作者: MatthewLXJ 时间: 2022-3-29 09:10
太强了...7T83的NAS。

之前尝试过TrueNas scale和core做全机械纯存储的NAS，尝试搭配CX3 pro 40G eth + 8盘RAIDZ提速，在没有SSD的情况下性能也太惨了...单纯拿去刷刷PT lz4也作用不大，关键偶尔还会卡I/O导致PT掉速，转了一圈又回到了单盘JBOD，配合WIN Server支持RDMA的SMB局域网速度也还不错。

作者: jerrytsao 时间: 2022-3-29 13:42
本帖最后由 jerrytsao 于 2022-3-29 13:48 编辑

T.JOHN 发表于 2022-3-28 20:10
是的，我是用默认128KiB做的测试，看来应该是recordsize差异造成的测试结果不同。
看来1MiB确实非常适合 ...

连上12900K默认+Z690 Formula的AQC113, 未作任何巨帧等优化Windows 11初步跑10GbE SMB, 我觉得还是用回LZ4吧...

作者: blackbeardever 时间: 2022-3-29 13:45
J叔大作，收藏了慢慢消化

作者: jerrytsao 时间: 2022-3-29 13:56
本帖最后由 jerrytsao 于 2022-3-29 14:16 编辑

leeosx 发表于 2022-3-26 23:53
大佬。我全默认设置 18个18t...为啥samba共享下面读写速度基本上就是600/200的样子raidz2...文件是单个60 ...

我PC上换到10GbE试了, 没有任何网络性能上的大问题, 就是1MiB+压缩会影响一点持续写入

作者: tunluan 时间: 2022-3-29 15:25
mark 感谢分享

作者: sojoke 时间: 2022-3-29 15:35
呵呵，这个牛哦，那么多硬盘，全部18t

作者: yaoiverson 时间: 2022-3-30 10:13
我也不知道该回复点啥但是啥都不说也不好，只能我艹，牛逼

作者: leeosx 时间: 2022-3-30 12:50
感觉我的性能限制是不是因为用的是带背板扩展造成的。。

作者: jerrytsao 时间: 2022-3-30 13:58

kingkiss 发表于 2022-3-27 08:23
期待关于网络配置和测试的文章，我也组了个TRUENAS SCALE，全NVME固态池25G网卡SMB读取只能跑1.2G/S还很不 ...

有没有设primarycache=metadata, NVMe SSD建议等OpenZFS 3.0上线看DirectIO实际表现, 能真正绕过ARC/RAM

作者: jerrytsao 时间: 2022-3-30 14:08
本帖最后由 jerrytsao 于 2022-3-30 14:18 编辑

MatthewLXJ 发表于 2022-3-29 09:10
太强了...7T83的NAS。
之前尝试过TrueNas scale和core做全机械纯存储的NAS，尝试搭配CX3 pro 40G eth ...

目前很多测试看下来, TrueNAS/Windows 11极限都在25GbE左右, 所以40G/100G往上没有两头都支持的RDMA是干不到的, 可以尝试下KSMBD

HDD回到单盘JBOD, 那还需要SMB Direct的网络? 你如果设置了SSD Special Vdev肯定不会慢的, 我这HDD Pool随机性能直接变SATA SSD

作者: sunneyboy 时间: 2022-3-31 05:26
J大佬，我的nas10块6T HDD，8块sata ssd 1.46T，池建议怎么创建能保证性能。谢谢

作者: crye 时间: 2022-3-31 09:59
膜拜大佬，看的我热血沸腾，无奈钱包不给力

作者: jerrytsao 时间: 2022-3-31 10:16
本帖最后由 jerrytsao 于 2022-3-31 10:18 编辑

sunneyboy 发表于 2022-3-31 05:26
J大佬，我的nas10块6T HDD，8块sata ssd 1.46T，池建议怎么创建能保证性能。谢谢

建议弄2-3个960GB或1.92T DWPD=1的数据中心NVMe SSD镜像组那个Special Vdev, SATA SSD的话怎么说呢, 还是单独组个池吧

作者: sunneyboy 时间: 2022-3-31 12:48

jerrytsao 发表于 2022-3-31 10:16
建议弄2-3个960GB或1.92T DWPD=1的数据中心NVMe SSD镜像组那个Special Vdev, SATA SSD的话怎么说呢, 还是 ...

组Special Vdev性能会提升吗？同平台TrueNAS SCALE比CORE慢了很多

作者: dominicchen 时间: 2022-3-31 13:18
J大，问下，GEN8能装这个TrueNAS SCALE 么？能不能装在U盘上？还是必须装在SSD上呢？

作者: 明石的果汁 时间: 2022-3-31 15:29
本帖最后由明石的果汁于 2022-3-31 15:31 编辑

我也装了一个True nas 用了 12T*36 480G*2 系统双万兆做的BOND 标准浪潮服务器来弄的。用于商用备份
SMB/NFS/ISCSI 我都在使用，都还行，ISCSI 不兼容esxi 的 VMFS 6 ,挂不上，我看国外也有好多报错，最后只能降级到5。主页报错过一次，进不去，SSH 提前开了，一个命令就能修复，其他稳定性都还行。
(, 下载次数: 128)
(, 下载次数: 119)

作者: leavelost 时间: 2022-3-31 20:19
本帖最后由 leavelost 于 2022-3-31 21:03 编辑

jerrytsao 发表于 2022-3-31 10:16
建议弄2-3个960GB或1.92T DWPD=1的数据中心NVMe SSD镜像组那个Special Vdev, SATA SSD的话怎么说呢, 还是 ...

向LZ求助，新买的9405W-16i，刷了最近的P22 mix固件，接了P4510的4T盘(也是最近固件0184），跑分不正常，不知有啥解决思路吗？
帖子地址：https://www.chiphell.com/forum.p ... ;extra=#pid49588494

作者: jerrytsao 时间: 2022-4-1 02:16

sunneyboy 发表于 2022-3-31 12:48
组Special Vdev性能会提升吗？同平台TrueNAS SCALE比CORE慢了很多

我原贴里已经详细解释了啊...还有那最后那个CDM随机读写

作者: jerrytsao 时间: 2022-4-1 02:18

dominicchen 发表于 2022-3-31 13:18
J大，问下，GEN8能装这个TrueNAS SCALE 么？能不能装在U盘上？还是必须装在SSD上呢？ ...

和是不是Gen 8没关系, 最好单独SSD做Boot

作者: jerrytsao 时间: 2022-4-1 02:22

明石的果汁发表于 2022-3-31 15:29
我也装了一个True nas 用了 12T*36 480G*2 系统双万兆做的BOND 标准浪潮服务器来弄的。用于商用备份
S ...

3个12盘Pool? 还有个Pool做啥用, 2*10GbE速度如何?

作者: jerrytsao 时间: 2022-4-1 02:26
本帖最后由 jerrytsao 于 2022-4-1 02:36 编辑

leavelost 发表于 2022-3-31 20:19
向LZ求助，新买的9405W-16i，刷了最近的P22 mix固件，接了P4510的4T盘(也是最近固件0184），跑分不正常， ...

https://www.chiphell.com/thread-2316899-1-1.html
https://www.chiphell.com/thread-1819639-1-1.html

关于这个问题我之前有说过好多次, Broadcom(LSI)这类HBA卡依然需要走SOC芯片, 并不适合PCIe NVMe SSD, 跑不满很正常

你需要的是超微Retimer拆分卡, 如Gen 4的AOC-SLG4-4E4T/AOC-SLG4-2E4T, 或Gen 3的AOC-SLG3-4E4T和AOC-SLG3-2E4T, 服务器上都用这种

HomeLab日常可以用我首页那种SZ产转接卡拆分PCIe Gen 4 x4/x4或者x4/x4/x4/x4, 这也是最直通最无损耗的方式

作者: etfgert 时间: 2022-4-1 08:14
太强了J叔，先收藏了

作者: 明石的果汁 时间: 2022-4-1 09:15

jerrytsao 发表于 2022-4-1 02:22
3个12盘Pool? 还有个Pool做啥用, 2*10GbE速度如何?

对，12盘一个组，最后一个组还未使用，速度没做测试，很快就拉完了，跟商用的华为集中存储也差不了太多，当然取决于组内盘的数量。比较遗憾的就是不支持VMFS6，VMFS5单盘最大上线64T，这个问题一直没解决，不知道你那边有测试过没。还有就是稳定性，家用肯定够，但是跟商用的比还是差点意思，商用的集中存储都是双控，多路径，挂任何一个，包括升级，都是无停机，无切换的，Truenas我没找到双机的方案，不停应用，写入状态，如果挂了会很麻烦。

作者: houyuzhou 时间: 2022-4-1 10:34
膜。。。膜拜j叔
我觉得还是买个dell服务器走传统硬raid简单一些。。。。

作者: jerrytsao 时间: 2022-4-1 10:34

明石的果汁发表于 2022-4-1 09:15
对，12盘一个组，最后一个组还未使用，速度没做测试，很快就拉完了，跟商用的华为集中存储也差不了太多， ...

我肯定没有这种需求...你这种我觉得上Ceph啊

作者: voandrew 时间: 2022-4-1 10:54
我去。。。8条64G内存！！！！！！！！我服了

作者: T.JOHN 时间: 2022-4-1 11:40

明石的果汁发表于 2022-4-1 09:15
对，12盘一个组，最后一个组还未使用，速度没做测试，很快就拉完了，跟商用的华为集中存储也差不了太多， ...

你这和操作系统没关系，需要硬件级别的支持，参考PEX芯片的备份双控方案，起码在CHH我还没见过这种硬件

欢迎光临 Chiphell - 分享与交流用户体验 (https://www.chiphell.com/)