我并不觉得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占用高一些，其他时候不太占资源
oldnetdog 发表于 2022-3-26 21:17
这个机箱不是只能18个3.5的HDD吗？怎么可以安装24块盘的？
水冷机上不是放了一摞硬盘吗？ 箱子也没盖盖子，应该是minisas拉出来一根
linchen0950 发表于 2022-3-26 21:00
超过26个硬盘，编号是sdaa开始吗
嗯, Linux都一样的
oldnetdog 发表于 2022-3-26 21:45
J叔不是写了24块盘，不知道咋安装上的。
晚些会定制个32盘机箱, 目前8盘放在外面的笼子, 不想用机柜...
FlexRAID官网都没了。。
[可爱]豪华
堕天使星颖 发表于 2022-3-26 23:23
FlexRAID官网都没了。。
这东西一直没细看, 已经Dead了[晕倒] 推荐列表里删掉
本帖最后由 jerrytsao 于 2022-3-26 23:45 编辑
T.JOHN 发表于 2022-3-26 22:39
我并不觉得scale性能会比core差到哪里去，openzfs代码统一以后区别只是freebsd和linux两个底层操作系统较量 ...
选ZSTD无后缀, ZSTD-1还是ZSTD-19, 看了些文档还不是很明确, 7T83确实应该利用其压缩/解压性能优势
jerrytsao 发表于 2022-3-26 21:46
UnRAID更多的是Marketing, 就像一个魔改版JBOD, Parity不完全, Reliability也不够, 还要付费, 唯一的强项 ...
但是现在snapraid要跑crontab，flex好像几乎处于停滞状态。开箱即食，又可以整合一堆乱乱七八糟容量且带实时校验的没选了[无奈]
哪位大佬快点整合一个带mergerfs的nas系统吧[流泪]
T.JOHN 发表于 2022-3-26 22:39
我并不觉得scale性能会比core差到哪里去，openzfs代码统一以后区别只是freebsd和linux两个底层操作系统较量 ...
大佬。我全默认设置 18个18t...为啥samba共享下面读写速度基本上就是600/200的样子raidz2...文件是单个60g的
64g内存
这机箱是怎么装24个机械盘的。。
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
T.JOHN 发表于 2022-3-26 22:39
我并不觉得scale性能会比core差到哪里去，openzfs代码统一以后区别只是freebsd和linux两个底层操作系统较量 ...
[偷笑] 至于性能这个不信的话你可以自己测一下看看，我又不是瞎吹
就记录大小来举例
1MiB的块大小就算是最外圈拿常见的HC320来算也需要200ms以上的io时间，而128KiB则是18±6ms之间
期待关于网络配置和测试的文章，我也组了个TRUENAS SCALE，全NVME固态池25G网卡SMB读取只能跑1.2G/S还很不稳定，写入只有500M-800/S，一直都没弄明白为什么。
jerrytsao 发表于 2022-3-26 23:42
选ZSTD无后缀, ZSTD-1还是ZSTD-19, 看了些文档还不是很明确, 7T83确实应该利用其压缩/解压性能优势 ...
偏向省空间选5，偏向性能得选1，或者负值。可以参考 https://community.centminmod.com/threads/round-4-compression-comparison-benchmarks-zstd-vs-brotli-vs-pigz-vs-bzip2-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。
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: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，如果太老更新下
其次看协议是否都正常开启了，用nmap扫描，
nmap --script smb-protocols IP IP改成你服务器局域网IP
现在基本都不用1.0了，你尽量保证3.11开启以适配你win10或者win11
https://img.kolbb.com/images/2022/03/27/smb.jpg
然后你可以调优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参数为无效
T.JOHN 发表于 2022-3-27 12:24
先查本地性能再查smb问题
1. 本地性能可以用fio测
谢谢。。我晚点从新装个truenas scale试试看。。谢谢
好贴，不知道在esxi下装truenas scale会不会有性能损失，比较习惯用esxi装虚拟机。
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: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):
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=,5.00th=, 10.00th=, 20.00th=,
| 30.00th=, 40.00th=, 50.00th=, 60.00th=,
| 70.00th=, 80.00th=, 90.00th=, 95.00th=,
| 99.00th=[ 1144], 99.50th=[ 1512], 99.90th=, 99.95th=,
| 99.99th=
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数据供你参考
# 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):
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 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
神贴留个名，等以后发达了再来抄作业
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
T.JOHN 发表于 2022-3-27 20:25
读速度正常说明硬件都没问题，你所有池的写卡450MB/S就很奇怪了，所以我觉得测错目录了，除此之外我想不 ...
我也觉得很奇怪，一直找不到原因[晕倒]
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:28 编辑
T.JOHN 发表于 2022-3-27 10:44
偏向省空间选5，偏向性能得选1，或者负值。可以参考 https://community.centminmod.com/threads/round-4- ...
每个原盘文件夹下(除BDMV子文件夹之外)有一些小文件, 其它基本都是视频文件了
反正CPU性能高, 主存容量也够大, 我直接选了ZSTD-19, 对视频文件也没啥影响
jerrytsao 发表于 2022-3-27 23:04
每个原盘文件夹下(除BDMV子文件夹之外)有一些小文件, 其它基本都是视频文件了
反正CPU性能高, 主存容量 ...
19我只能说充分利用CPU[流汗]
scrub和smart长测我觉得不用两周一次那么频繁的，一个月一次就很充分了。白嫖王是万年不维护才丢的数据，一方面WD和ST两家的企业盘都很可靠，另一方面有ECC内存出错概率很低。
主要smart长测的时候真的非常吵，尤其盘多情况下，18T估计要20小时+，我已经懒到半年测一次了，平时用10天一次的短测替代。
T.JOHN 发表于 2022-3-28 00:26
19我只能说充分利用CPU
scrub和smart长测我觉得不用两周一次那么频繁的，一个月一次就很充分了。白 ...
建议不错
风车车看不懂这些，因为他买不起你们这些高端电脑！