V principu ano, pokud chcete potlačit write amplification tak je nejlepší mít recordsize stejný jako ashift. Ale někdy je lepší to mít vyšší a potlačit to kompresí. U recordsize 128kB pokud změníte jeden 4kB blok tak se na disk zapíše na jiné místo modifikovaných 128kB, to může být důvod toho množství zápisu ve smartu.
Jen pro zajímavost: kolik vám šetří ta deduplikace? Vzhledem k tomu že se to deduplikuje po blocích a Vy máte bloky 4kB velké tak deduplikační tabulka bude hodně velká a je otázka jestli se vyplatí.
Pokud dáte zpool status -D tak ve výpisu bude podobný řádek:
dedup: DDT entries 188696705, size 601B on disk, 194B in core
Když vynásobíte počet záznamů velikostí jednoho záznamu (on disk, in core) tak dostanete kolik zabírá deduplikační tabulka na disk, respektivě v ram.
Tohle může být příčina toho že je to pomalé. Je možné že deduplikační tabulka zabírá zbytečně moc ram která by se dala využít efektivněji pro db. A při každém zápisu bloku se musí upravovat počty referencí v tabulce což hodně sníží výkon zápisu.
Ještě bych prověřil jak je nastavená velikost bloku na nvme disku. Většinou nvme disky emulují 512B sektor (kvůli winXP) a to stojí také výkon. Je nesmysl aby aplikace pracovala se sektory o velikosti 4KB aby se pak překládali na 512B sektory které disk tvrdí že používá a přitom interně pracoval opět s 4KB.
Když to vezmu osobně tak pokud připravuji server pro db tak:
1, nastavím na nvme velikost sectoru na 4kB
https://wiki.archlinux.org/title/Advanced_Format#Setting_native_sector_size2, zpool vytvářím s ashift 12 a parametry (předpoklad je že /boot je na ext4 a ne na zfs):
dnodesize=auto (jinak pokud velikost adresáře překroší 512B tak to uloží jako nový blok)
redundant_metadata = most (omezím počet zápisů na metadata)
compression=zstd
xattr=sa (ukládá rozšířené atributy přímo k souboru, zvyšuje výkon při použití např selinuxu)
atime=off
primarycache nechávám zaplou na all
3, mysql dataset vytvářím s recordsize=16k. Mám to ozkoušené že to poskytuje nejlepší výkon a je to doporučováno pro db i v dokumentaci zfs.
4, u mysql nejvíc pomůže vypnout doublewrite, ale je možné zapnout ještě další optimalizace. Docela pěkně to má popsané letsencrypt když migroval na zfs:
https://github.com/letsencrypt/openzfs-nvme-databases#mariadb-settings