Kiitos tästä. Kuvittelin jo ymmärtäneeni tuon SLOGin toiminnan, mutten näköjään sittenkään täysin. Tietysti tuo on järkevää että data kirjoitetaan lopullisestikin pooliin RAMista, RAMin kauttahan se todnäk. joutuisi jokatapauksessa menemään. Tuo 5s kuluessa tuli mulle yllärinä. Kuvittelin että ZFS kirjoittelee tuon ZILin sisällön pooliin vasta joskus myöhemmin kun ehtii muilta operaatioiltaan (tai ZIL/SLOG loppuu kesken). Ja jotenkin ajattelin että ZFS siinä välissä käyttäisi jotain älyä ja kirjottaisi datan pooliin niin että se voidaan sieltä myöhemmin lukea perättäislukuina, mutta tuskinpa tässä välissä mitään optimointia tehdään vaan data recordit kirjoitetaan sellaisenaan eteenpäin.
Tuo 5s timeout on useimmiten hyvä ratkaisu, sinä aikana ZFS saa riittävästi dataa muodostaakseen niistä sisään tulleista satunnaiskirjoituksista helposti luettavia kokonaisuuksia levylle. Siellä on kyllä muitakin rajoitteita login koolle, mm. suurin sallittu koko tavuina. Omalla kohdalla nostin tuon 30 sekuntiin, nopeuksissa en eroa huomannut, mutta kirjoitukset tuolle Optanelle tippui viidesosaan kun ei tarvitse jokaisen pienen logiin tulevan merkinnän takia kirjoittaa koko 128 kB recordia uudelleen. Eli siis ZFS taiteilee puskurin aikana tulleista pienistä kirjoituksista yhden isomman kokonaisuuden.
Tuo 5s timeout tarkoittaa myös sitä, että gigan linkin päässä (~100MB/s) SLOGiin ei voida kirjoittaa kuin korkeintaan sen ~500MB, yli gigan kokoinen SLOG olisi siis täysin turhaan varattua tilaa.
Melkein kaikki ZFS:n kanssa harrastamista aloittavat ajattelevat juurikin tuon SLOGin olevan kirjoituspuskuri ja siksi vain hyvä homma. Samoin L2ARCin ajatellaan olevan ilmainen lisä lukukakkuun. Itsekin olen käynyt tuon polun, eikä se edes harmita yhtään, siinä oppi jälleen lisää ZFS:n sielunelämästä. Nykyisin räpellyksille on jo oma koneensa, tällä hetkellä tuo 4c Intel Atom vuosikymmenen ikäisen SSD:n kanssa, copies=2 moodissa gzip-6 pakkauksella sekä deduplikoinnilla porskuttaa yllättävän hyvin, vaikka kaikki noista kuuluu listalle asioista, joita ei tulisi käyttää koskaan.
Mulla on ollut käytössä VM-dataseteissä sync=always ja Proxmoxissa Cache mode=No cache. Olen kuvitellut että tällä kombinaatiolla Proxmox eikä FreeNAS käytä RAMia writebufferina. Kyseessä oleva VM bufferoi omat kirjoituksensa "normaalisti" omaan RAMiinsa, joten jos joku tietty applikaatio edellyttää syncwriteä se ohittaa VM:n bufferit ja päätyy suoraan syncwritenä levylle asti.
Jos pyrkisi siihen että kirjoitukset bufferoitaisiin vain RAMille niin mikä olisi järkevin ratkaisu?
Jos käyttää Proxmoxissa "No cache" -modea ja itse image on FreeNASissa NFS-jakona, käykö siinä niin että kirjoitettavaa dataa on bufferoituna sekä itse VM:n RAMissa että FreeNASin RAMissa? Puhumattakaan jos käyttää "writeback" -modea niin dataa on VM:n RAMissa, hostin (Proxmox) RAMissa ja FreeNASin RAMissa?
Jos käyttäisi "directsync" tilaa Proxmoxissa, mutta asettaa datasetille sync=off, Proxmox luulee kirjoittavansa kaiken suoraan levylle, joten bufferoinnin on pakko tapahtua FreeNASin RAMissa? Tällöin FreeNASille pitäisi varata reilusti enemmän RAMia?
Jos sync=off ja dataa kirjoitetaan paljon ja RAM loppuu kesken, alkaako ZFS viivyttelemään noiden vastausten kanssa? Eikö tästä voi tulla jotain timeout ongelmia?
Sync=always toimii parhaiten niissä tilanteissa, joissa ohjelma (ml. VM:n) ei osaa jostain syystä itse kertoa, että data on kriittisesti suojattava äkillisiltä sähkökatkoilta. Virtuaalikoneissa harvemmin on mitään omaa kirjoituspuskuria (ellei niitä asenna ZFS:lle ZFS:n päälle, mikä on huono idea), sen sijaan ne puskuroi (virtuaalisen) levyn muistiin käyttiksen muistin sijaan ja komentavat cache flushia synkronisten kirjoitusten yhteydessä. Sync=standard on vakioasetus ja se, mikä on melkein aina paras vaihtoehto. Se antaa ohjelman itse päättää onko data kriittistä ja synkronisesti kirjoitettavaa, vai vähemmän kriittistä ja nopeudesta hyötyvää asynkronista. Proxmoxin cache modeista tuo "No cache" on useimmiten se nopein olematta myöskään kovin vikaherkkä, sen kanssa VM kakuttaa vain lukemiset ja kirjoituskakusta vastaa ZFS.
Sync=always ei varsinaisesti vaikuta kirjoituspuskuriin tai sen kokoon, se vaan pakottaa kaikki kirjoitukset synkronisiksi, eli RAMin
lisäksi logiin kirjoitettavaksi. Paitsi peräkkäiskirjoitukset ja jotkut muut poikkeukset, jotka menevät suoraan levylle. ZFS alkaa kyllä jarruttelemaan jos logi täyttyy, joko ajallisesti tai tilallisesti, timeoutin kanssa ei tule ongelmia.
Proxmoxin ZFS kakuttaa vain oman poolinsa dataa eikä esim NFS:llä olevaa, ja kuten mainittua, VM:t ei varsinaisesti edes puskuroi kirjoituksiaan. Proxmox itsestään ei myöskään kakuta mitään, se on tiedostojärjestelmän tehtävä, ja nuo cache modet vaikuttavat siihen miten VM:t keskustelee tiedostojärjestelmän kanssa. Periaatteessa kirjoitukset eivät siis oikein voi olla useaan kertaan RAMissa ainakaan merkittävissä määrin, mutta lukukakku puolestaan voi olla.
Sanoisin järkevimmän ratkaisun olevan sync=standard + cache mode "no cache". Miltei riskitön ja kuitenkin erittäin nopea, toimii tilanteessa kuin tilanteessa.
Terminologiaan vielä sen verran tarkennusta, että jos tarkkoja ollaan, ZFS:n kirjoituspuskuri sijaitsee myös siellä levyllä eikä RAMissa, RAMissa oleva data kuuluu (ymmärtääkseni) transaction grouppeihin. Se ei ole varsinainen puskuri koska siihen kuuluu paljon muutakin, juurikin ZILit ja SLOGit sun muut. Vähän samalla tapaa kuin datasetit eivät ole varsinaisia osioita. Itsekään ei tule aina pysyttyä kärryillä termeistä.
