Dotaz: Write cache pri zapisu pres CIFS na ZFS

[Michal]

Příloha:

• kopirovani.PNG (4526 bytů)

Kopiruju soubory z win PC na linuxovy NAS pres 10Gbit/s sit a sambu/cifs. V NASu je ZFS nad normalnim HDD s rychlosti zapisu kolem 140MB/s. Je tam take hromada pameti. Rychlost kopirovani je na zacatku ~1100MB/s a po cca 1GB klesne na rychlost disku 140MB/s viz prilozeny soubor. Evidentne tam je nejaka cache, ktera data nacucne a postupne to zapisuje na ten pomaly disk. Kdyz je u ale plna, tak neprijme vic, nez zapise na disk. Nevim, zda ta cache je na strane samotneho OS nebo ZFS. Na konci kopirovani se to pak zasekne na 99 % pricemz disk dale zapisuje to, co bylo v cache. Takze ve vysledku nic neusetrim pac se ceka na nejaky commit. Muj dotaz zni- co kde nakonfigurovat, aby to tou plnou rychlosti jelo nikoliv 1GB ale 10 GB (RAM tam je dostatek) a aby to odeslalo commit ihned kdyz jsou data v cache a ne az kdyz jsou skutecne zapsana. Samozrejme pocitam s tim, ze kdyz vypadne napajeni nebo se stane s cilovym NASem neco jineho, tak prijdu o data.

Odpovědi

[Michal]

Overil jsem, ze cache je zalezitosti OS a nikoliv ZFS - udelal jsem pokusne smb share na systemovem disku, ktery je ext4 a chova se to stejne.

[Vlado99]

Takto sa chová zápis na SMR disk. V OS s tým nič neurobíš.

[Michal]

To neni SMR disk... Plus myslim, ze ani SMR disk nedokaze protlacit 1100MB/s pres sata rozhrani takze tim to chovani vysvetlit nejde

[z_sk]

Skús https://stackoverflow.com/questions/20215516/disabling-disk-cache-in-linux.

[Max]

Vypínání diskové keše dává smysl jen v případě použití řadiče s keší, ostatně ty řadiče si tu keš standardně na diskách vypínají.
Celkově tedy ta manipulace s keší nedává smysl.
Zdar Max

[trekker.dk]

V té Sambě se můžete zkusit podívat na nastavení strict sync, to by mohlo vyřešit ten "zásek" na 99%.

Ten 1GB bych si tipnul na cache operačního systému - úmyslně se jako cache nevyužije všechna paměť, kterou by tak využít šlo, protože tím zpomalíte všechno ostatní - když něco jiného potřebuje paměť, tak to nejdřív musí počkat, až se ta cache pomalu překopíruje do úložného zařízení. Možná v /proc nebo /sys bude nějaká páčka, kterou půjde přepnout, aby ta cache mohla být větší, ale momentálně mě nenapadá správná fráze pro google

[Jendа]

Ten začátek se nastavuje pomocí /proc/sys/vm/dirty_ratio a /proc/sys/vm/dirty_background_ratio, ten sync na konci nevím, u některých věcí pomůže prasárna - pustit je přes eatmydata, což je věc, která vypíná sync - samozřejmě s dopadem na konzistenci dat pokud dojde k výpadku.

I když ZFS si ještě k tomu řeší cache částečně po svém (ARC), tak se podívat ještě na nastavení toho.

[Max]

Zjevně není backend dostatečně rychlý, aby to zapsal. Tj. to diskové pole je pomalé a po naplnění pár keší to padne na reál. Je nesmysl chtít, aby jsi kopíroval dlouhodobě rychleji, než dokážeš reálně zapsat.
Zrychlení zápisů docílíš pomocí slog keše. Na tu se používají rychlá ssd, která zlvádají šíleně moc přepisů (já na to používám Intel Optane).
Pokud jsi sebevrah, tak můžeš slog keš nasimulovat pomocí ramdisku. Prostě si vytvoříš ramdisk o nějaké velikosti a ten pak připojíš jako slog. Tím si nasimuješ, jak reálně rychle ti to bude fungovat s ssd (příklad z mého blogu). Můžeš to tak prozovovat i dlouhodobě, ale můžeš lehce přijít o data, lehce dojít k nekonzistencím a po restartu serveru se ti pool automaticky nepřipojí, protože nebudeš mít ten ramdisk = poolu bude chybět slog.
Zdar Max