“This is actively, but very slowly, being worked on.” →
I’m curious where this is being tracked / talked about. Curious about ZFS performance work to complete with XFS/ext4 on NVMes.
I have two PM9A3 U.2 and something is wrong when I format them with 4k, ZFS then complains with
“One or more devices are configured to use a non-native block size. Expect reduced performance.”
With any other NVME I have it’s no problem
Your result looks like your server is dead, but the test is also not useful, you should use fio
That’s only one PM9A3
# dd if=/dev/zero of=/tank02/test1.img bs=5G count=20 oflag=dsync
dd: warning: partial read (2147479552 bytes); suggest iflag=fullblock
0+20 Datensätze ein
0+20 Datensätze aus
42949591040 Bytes (43 GB, 40 GiB) kopiert, 4,7957 s, 9,0 GB/s
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html
Updated your Trust level to post URLs now just so you know
I believe it was @wendell who did a video a while back on GRAID – It does not do parity checks. Ye be warned.
May I ask why you are using proxmox?
It was my understanding that it wasn’t even calculating parity at the same time that data was being written, so a power outage/crash/some kind of interruption will make the volume inconsistent which is very bad.
-I should probably double check to make sure that is still the case, I know GRAID did make some improvements after the initial hype bubble.
VROC has a deferred parity issue too that is pretty serious. It seems like all these software raids that are hardware accelerated have fundamental problems.
I remember a video (the same one by Wendel?) went over the entire debacle of older hardware doing it proper and newer completely skimping on it.
I remember that video too!
I have a completely different school of thought on the depreciation of Data Integrity Field from older hard drives and raid controllers: the adoption of Advanced Format hard drives made it mostly redundant. The amount of extra ECC performance AF drives bring likely exceeds the 520/528b sector DIF hdds of yore.
There was also the argument that DIF provided “full I/O path” integrity protection, but the SAS commandset is robust enough to actually sample the connection intrgrity to the hard drive from the hba so it was already kind of dubious to say that DIF would help resolve bad connections between hba and hhd.
T10 PI did replace the old DIF drives though, it just wasn’t adapted by hardly anyone because it wasn’t that helpful IMO.