Dotaz: SSD jako write cache pro HDD

[Michal]

Zdravim. Mam linuxovy nas s 10Gbe siti a disky prehistorickeho (rotacniho) typu kvuli kapacite. Klientske pocitace maji take 10GBbe ale uz maji normalni nvme disky, ne takove ty velke 3,5" obludy jako pouzivala moje babicka kdyz jeste, budiz ji zeme lehkka, zila.

Dost me stve, ze zapis na ten NAS je _extremne_ pomaly (~130MB/s velke soubory, male jeste mene) pricemz klientske pocitace mezi sebou pres SMB zvladnou 1GB/s+ Dalo by se udelat to, ze by se k rotujici rzi predradil nvme, ktery by se choval jako write cache? Vim, ze synology neco takoveho umi. Optimalni by bylo, kdyby se to chovalo jako jedno blokove zarizeni - zapis by odchytil nvme a postupne by se to uklidilo na tu srandovne vrnici vec s moturkem. O neco horsi reseni (to by asi nepoznalo, ze soubor v cili uz existuje a nemohlo by se zeptat, co v takove situaci delat (skip/overwrite)) by mohlo byt pomoci utility, ktera by periodicky data z nvme uklidizela na ty retro disky. Musela by si dat akorat pozor, zda se soubor zrovna nezapisuje aby nenahrala na magnetomechanickou zarazku pod dvere polonahrany soubor.

Mam nejakou moznost jak to v linuxu vyresit?

Odpovědi

[Peter Golis]

Dalo by se udelat to, ze by se k rotujici rzi predradil nvme, ktery by se choval jako write cache?

Napríklad ZFS to má implementované natívne, stačí pridať cache disk do poolu. Ale to by asi chcelo odsypať údaje niekam inam, a preformátovať diskové pole na ZFS. Poprípade je možné použiť dm-cache/lvmcache, závisí ako si to diskové pole vytváral.

[Michal]

Na ZFS jsem se dival ale nejsem si jisty, zda ZFS SLOG funguje tak, jak potrebuji... Predne podle popisu funguje pouze pro synchronni zapisy. Kdezto samba dela asynchronni zapisy. Dale se pise, ze delat vetsi SLOG nez 16GB nema z nejakeho duvodu smysl. A 16GB cache pro muj usecase, kdy potrebuji nasat narazove 100GB a pak at se to klidne hodinu zapisuje na rotacni disk stacit nebude...

[Michal]

Cim vic o tom ctu, tim vic me to utvrzuje, ze to neni vhodne reseni:

https://www.reddit.com/r/zfs/comments/m6ydfv/performance_effects_of_slog_on_ssd_and_ram_disk/

very often people come here and suggest using a SLOG to speed up their zpools, because they think SLOG is a write cache.

It is not.

https://support.osnexus.com/hc/en-us/articles/213487606-Can-the-ZFS-ZIL-SLOG-be-used-to-increase-performance

NOTE: The ZIL SLOG device is not a write cache that will buffer all I/O's written to the Quantastor Storage Pool.

...

[Peter Golis]

Voľakto tu pred časom písal v blogu niečo o tom, ako sa mu týmto spôsobom rapídne zdvihol výkon. Ale myslím že používal L2ARC cache a nie SLOG/ZIL.

Ale nie som si istý či tam mal aj informáciu o tom, že vynútil v SAMBA položky sync always a strict sync ktoré ti napadli pri použití SLOG/ZIL, a ktoré by spomalili zápis keďže cache v RAM by bola obmedzená na viacerých úrovniach.

[Michal]

Treba psal o ctecim vykonu? L2ARC je pouze pro cteni. Zmenit sambu na sync by zapisu urcite nepomohlo, ten prvni odkaz co jsem posilal tvrdi, ze async je mnohonasobnie rychlejsi nez sync i s SLOGem v ramdisku.

[Peter Golis]

Keď sa ti nechce hľadať ten tunajší blog v ktorom bolo aj porovnanie celkového výkonu, tak skús ten dm-cache/lvmcache. Alebo tie staré disky vymeň aj so starým radičom, a použi niečo výkonnejšie.

Spoliehať sa na to že budeš mať 100% istotu že klientský desktop ukončil zápisy je trošku silné riziko.

[Michal]

Ten lvmcache vypada dobre, to muze byt presne to, co potrebuji.

Chtelo se mi hledat: https://www.abclinuxu.cz/hledani?from=0&count=10&orderBy=create&orderDir=desc&advancedMode=true&dotaz=zfs&typ=blog

Ale tam jsem nasel jen https://www.abclinuxu.cz/blog/Max_Devaine/2019/9/zfs-stavba-zkusenosti-se-zfs-storage ktery potvrzuje to, co jsem psal - SLOG rozhodne neni write cache.

[Peter Golis]

SLOG to trochu zrýchli, ale nie až tak ako dostatok RAM pre L1 ARC cache. Urýchliť by to mohol aj HW RAID radič s RAM a baterkou, ale to je už jednoduchšie a lacnejšie ten starý server nahradiť niečím z tohoto desaťročia. Voliteľne aj s možnosťou pripojenia ďalšieho diskového shelfu.

Inak ten LVM som spomínal keďže som odhadoval že aj tak už máš roztiahnuté LVM na tých rotačných diskoch. Len by som ho odporučil aj s dm-integrity ak máš FS bez checksumov na dátach.

[Michal]

Co mas porad s tim L1 ARC? ten se pri zapisu vubec neprojevi. Je to read cache.

[Peter Golis]

First Level Cache je v RAM, a je zapnutá. Ak by sa do nej necachovalo, tak by ZFS nepodporoval asynchrónne zápisy.

WIKI ZFS:

Handled by means of "transaction groups" – writes are collated over a short period (typically 5 – 30 seconds) up to a given limit, with each group being written to disk ideally while the next group is being collated.

Pred tým som písal o Level 2.

[X]

Kdyz je to stare pole takova zoufalost, tak proc ho chces zachovavat? Kup si novy pole, problem vyreseny.

[Michal]

No protoze jsem si spocital, ze bych potreboval alespon 4 rychle disky v RAID0 abych uzivil 10 Gbit. A to si nelajznu mit tam 4 disky bez redundance. S 8 disky v RAID10 by to asi take slo, pokud by nebyl bottleneck na radici. To mame 8 exosu po 10k s DPH to je 80k to uz se vyplati trochu zagooglit, zda neni lepsi reseni V RAID5 by asi stacilo 5-6 disku ale kdo vi zda by to nezabilo pocitani tech kodu.

[PetebLazar]

Mám obavu, že na saturaci 10Gbps čtyři rotační HDD v RAID0 stačit nebudou (jakkoli to prostá matematika 4x260MB/s > 1GB/s může naznačovat). Mám v RAID6 šest členů (8TB Helium) a v lineárním čtení/zápisu jsem rád za 600MB/s. Ladil jsem parametry RAID a FS omezeně, takže maximum asi bude ležet výše.

[Max]

Přesně tak.
Zdar Max

[Michal]

A nevadne ti to na pocitani tech kontrolnich souctu nez ze by nestihalo IO? Pro raid6 jsou navic slozitejsi nez pro raid5...

[lertimir]

Tam nejsou kontrolní součty, ale pouze parita, a to je základní operace procesoru XOR.

[Michal]

xor je u raid5 (a i tam se tomu rika parita), u raid 6 je to vypocetne mnohem slozitejsi: https://igoro.com/archive/how-raid-6-dual-parity-calculation-works/

Krome toho i u toho xoru to neni zase takova trivka jak by se mohlo zdat - nacist blok dat do pameti spocitat ten XOR pocet_disku-1 krat a pak zapsat do pameti aby to slo zapsat na disk. A to vse rychlosti 1GB/s

[PetebLazar]

Nemyslím si, že by to bylo brzdou několika HDD v RAID6.

[    2.419446] raid6: avx2x4   gen() 39993 MB/s
[    2.487450] raid6: avx2x4   xor()  5190 MB/s
[    2.555446] raid6: avx2x2   gen() 40175 MB/s
[    2.623448] raid6: avx2x2   xor() 34891 MB/s
[    2.691446] raid6: avx2x1   gen() 24095 MB/s
[    2.759445] raid6: avx2x1   xor() 30594 MB/s

[Michal]

Mas procesor, ktery je schopen precist z pameti 40GB/s a pak i tam i tolik zapsat? Jinymi slovy: neni ten ten benchmark nahodou in-place fake cucoprst?

[Peter Golis]

Ten benchmark je priamo z kernelového modulu raid456, a robí sa počas kalibrácie pri štarte alebo zavedení daného modulu, a je vidno vo výstupe z dmesg. Jednoducho sa vyberie najrýchlejší algorytmus. Ale ten zodpovedá len výkonu CPU, a neberie do úvahy priepustnosť radiča, zbernice alebo aj RAM.

Teda ukazuje že či to CPU to zvláda, a to je odpoveď na otázku či to CPU zvláda.

Pred rokom som si robil HTPC NAS z MicroPC ktorého CPU zvláda len 44874 MB/s, ale to je slabučká i3. Doň sa mi pochopiteľne zmestia len dva disky, takže RAID5 a ani RAID6 v ňom nevyužijem.

[PetebLazar]

Jde o Epyc 7434 tj. 16c 128MB L3 cache s 512GB 8-channel ECC 3200MHz. Epycy od čtyř chipletů výše jsou v optimálním případě teoreticky schopny dosáhnout 200GB/s memory bandwidth. Ten test v rámci inicializace kernelu mohl probíhat na malém datasetu v rámci L1/L2/L3 cache CPU kde bude bandwidth ještě násobně větší.

[PetebLazar]

Oprava: Epyc 7343.

[Petr Tomášek]

A takovéto dělo používáš na desktop?

[Petr Tomášek]

Přesně tak. Jak pomalé to může být, lze třeba otestovat pomocí pv </dev/zero >/dev/null . Příkaz dd bude krapet rychlejší, ale pořád žádné žůžo...

[Peter Golis]

To máš čo za stroj? Mne píše obyčajný NB za menej ako 350€ toto:

[Mon Oct 31 18:27:54 2022] raid6: avx512x4 gen() 52812 MB/s
[Mon Oct 31 18:27:54 2022] raid6: avx512x2 gen() 50534 MB/s
[Mon Oct 31 18:27:54 2022] raid6: avx512x1 gen() 49514 MB/s
[Mon Oct 31 18:27:54 2022] raid6: avx2x4   gen() 44588 MB/s
[Mon Oct 31 18:27:54 2022] raid6: avx2x2   gen() 45382 MB/s
[Mon Oct 31 18:27:54 2022] raid6: avx2x1   gen() 29637 MB/s
[Mon Oct 31 18:27:54 2022] raid6: using algorithm avx512x4 gen() 52812 MB/s
[Mon Oct 31 18:27:54 2022] raid6: .... xor() 10798 MB/s, rmw enabled
[Mon Oct 31 18:27:54 2022] raid6: using avx512x2 recovery algorithm
[Mon Oct 31 18:27:54 2022] xor: automatically using best checksumming function   avx       

[Max]

Raid5 rozhodně nepoužívat, nidky, never ever.
Zdar Max

[Petr Tomášek]

Na to je právě dobrá mdraid cache a zálohovat, zálohovat, zálohovat. Raid6 je lepší, pravda.

[Max]

Write cache ti většinou pomůže snížit IOPS. U ZFS pak SLOG pokrývá jen sync zápis, viz můj blog.
Pokud máš pomalý storage z hlediska datové průchodnosti, tak se ti to nějakou keší moc vytunit nepodaří. Pro nic za nic neexistuje přísloví, že z hovna bič neupleteš :).

Nepíšeš ale, jaký filesystém používáš. Třeba ZFS i btrfs má nemalé režie při zápisu. Teoreticky by jsi si mohl pomoci, kdyby jsi použil XFS a journal nastavil na to SSD.
Pokud teď používáš třeba ext4, tak nevím, zda a jak moc by jsi pomohl.
Jinak přenos velkého počtu malých souborů přes síť je problém tak jako tak.
Zdar Max

[lertimir]

Dvě technologie, které má linux a má je v jádře (a má je už asi 10 let) jsou lvmcache a bcache.

[PetebLazar]

Není lvmcache pouze wrapper pro dm-cache?

[lertimir]

Nevím nestudoval jsem podrobně. Kdysi jsem trochu více se zajímal o bcache, autor se tomu hodně pečlivě věnoval a dost to optimalizoval. Nevýhodu to má, že podle autora by to měla být první vrstva na železe, což pro mne, když jsem měl/mám několik zašifrovaných disků a pak nad nimi RAID, tak kde cache přesně mít se mi finálně řešit nechtělo. (hodiny pokusů by nevyvážil ten získaný čas.)

[trekker.dk]

Je. Z man lvmcache (zvýraznění moje):

The two kinds of caching are:

• A read and write hot-spot cache, using the dm-cache kernel module. This cache tracks access patterns and adjusts its content deliberately so that commonly used parts the main LV are likely to be found on the fast storage. LVM refers to this using the LV type cache.

• A write cache, using the dm-writecache kernel module. This cache can be used with SSD or PMEM devices to speed up all writes to the main LV. Data read from the main LV is not stored in the cache, only newly written data. LVM refers to this using the LV type writecache.

[Michal]

Poslusne hlasim, ze lvmcache funguje OK. Tim, ze to neni soucasti BTRFS/ZFS komplikuje situaci pac se to musi nacpat do vrstvy pod temito FS... ale funguje to. Skoda, ze takovou uzitecnou vec ty FS neimplementuji primo...

Take hlasim, ze pokus s ZFS + SLOG a L2 ARC nemel (podle ocekavani) vubec zadny efekt na rychlost async zapisu. Pri prepnuti samby do sync rezimu (aby se uplatnil SLOG) se vysledek dostavil... a opet podle ocekavani - dost negativni: rychlost klesla na polovinu.

[PetebLazar]

Šlo by ověřit (předpokládám že využíváte write-back policy) zda se při následném opakovaném přístupu k posledně zapsaným datům využívá bloků v cache-device (čtení odpovídá v ideálním případě rychlosti cache-device).

.

Možný scénář

Zapsat na origin-device soubor přesahující násobně velikost RAM (eliminovat vliv cache na úrovni RAM)

Nechat propsat zápisy na origin-device

Vyzkoušet sekvenční rychlost při přístupu k uloženému souboru

V mých testech se rychlost zvyšovala s opakovými čtením podobně (jako zde), ale nejsem si jist zda jsem neprovozoval dm-cache v režimu write-thru.

[Petr Tomášek]

Možností máš několik:

1) write-cache, která je přímo v mdraidu: https://www.kernel.org/doc/html/latest/driver-api/md/raid5-cache.html a použít write-back mód. Je potřeba to ale trochu vytůnit. Jediný problém, který jsem s tím ale měl (když jsem použil větší NVMe disk), že ve chvíli, když spadl systém, tak mi devuan odmítl nabootovat, protože obnova trvala moc dlouho. (Stačilo ale systém nechat obnovit a pak znova restartovat).

2) druhou možností je lvmcache.

3) bcache, ale nevím, jak moc je to udržované.

Osobně používám kombinace mdraid cache (pro zápis, jako write-back) a potom lvmcache v režimu hot-spot (tj. pro čtení často čtených sektorů).

[Petr Tomášek]

Oprava: mělo být: pro urychlení čtení často čtených souborů.

[PetebLazar]

Dá se nastavit threshold kolikrát již znamená "často"?

[Petr Tomášek]

Pokud vím, tak to funguje tak, že lvmcache/dm-cache prostě udržuje seznam nejčtenějších sektorů a ty (do příslušné kapacity SSD disku) ukládá paralelně na to SSD.

[Avo]

A co bcachefs?