Új hozzászólás Aktív témák

• #104799 Dißnäëß nagyúr hcl #104795

  Új Válasz 2025-06-27 23:10:27 #104799

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Dißnäëß

  nagyúr

  válasz hcl #104795 üzenetére

  Semennyire, a raid tömböd nagyonhamar gyorsabban tud olvasni, mint a cache-nek (tisztázzuk: READ cache-nek, azaz L2ARC-nak) használt HDD.

  Felejtsd el, a legbikább NVME-t kell L2ARC-nak betenni, lehet kicsi is, vagy amire a pénzed futja, de gyors legyen, nálam 4 HDD olvas 700MB körül (persze 1 nagy fájlt, nem sok aprót millió seek-el), szóval egy SATA SSD is sovány lenne (kettő már okébb)... na az megküldi rendesen a pool sebességet. Mondjuk a nagyobbak többet is bírnak (TBW) és jót is tesz úgy mindennek általában.

  VM-ek (és DB-k és 1-2 dolog) a default async helyett sync módon írnak a poolra, azaz akkor tekint a rendszer valamit kiírtnak, ha az ténylegesen kiírásra kerül... így arra LOG (SLOG) device-ot érdemes csinálni, szintén SSD. Ez write cache, míg az L2ARC read cache csak.

  Az egész pool alá pedig lehet SATA SSD-kből, minimum 2-utas mirrorból, de inkább 3-ból (mert ha bekrepál, befosik a teljes pool) special device-t csinálni, ami a metaadatokat tárolja itt (nem pedig a HDD-n) illetve default tán a 128K-nál kisebb fájlokat, de ez állítható, pl. minden ami 8 megánál kisebb, erre jöjjön, minden, ami nagyobb, a HDD-re. Special device-t utólag is lehet hozzáadni meglévő pool-hoz, viszont csak új írások metaadatai kerülnek az SSD mirrorra, a meglévők már nem, ezért érdemes pool létrehozáskor meglépni ezt, akkor az optimalizált.

  Fullextrás esetben lenne egy pool és hozzá special device (2-3 utas mirror SSD), log device (1 vagy több SSD) és cache (1 vagy több SSD) egyaránt.

  Ezekből a LOG-ot érdemes tükrözni, de ha nem tükör, nincs tragédia, akkor sem, ha meghal (max pár utolsó tranzakció vész el), régen ez baj volt, de már rég kiszögelték a ZFS-ből. Ettől függetlenül olcsó az SSD, két SATA-sat simán be lehet fogni erre a célra tükörben, a LOG-ra durva írás nem megy, inkább több kicsi.

  A cache (L2ARC) SSD-t bármilyenre lehet venni, kommersz szar is lehet, nem fontos enterprise és akár stripe-ba is teheted egy társával, dupla sebesség (raid 0 ekvivalens). Ha hullik, belassulsz, de kb. ennyi történik, semmi különös. Én valami nagysebességű vihargyors NVMe-t fognék be erre és elég 1 db.

  LOG eszköznek 1 vagy 2-utas tükörnél érdemes PLP-s Enterprise szintű SSD-t venni, hogy ha elmegy az áram, be tudja még fejezni a legutolsó megkapott adat kiírását az SSD. Nem durván kötelező, de ajánlott.

  Special device már metadata szint + kicsi fájlok, ez érzékenyebb terület. Én ide szintén csak enterprise, jó írástűrésű SSD-ket fognék be, de PLP-s legyen, itt nagyon fontos, hogy be tudja fejezni a legutolsó megkapott adatot minden SSD benne, ha elmegy az áram hirtelen. Elméletben a ZFS ugye CoW, ha lemegy az áram, nincs korrupció a fájlrendszeren, mégis ajánlják. Enterprise SSD-k ilyenek.

  Szóval SATA SSD-kkel meg lehet oldani mindent, ami nem cache (L2ARC), mert nincs durva szekvenciális írás-olvasás róluk. A cache eszközt érdemes a sebesség miatt NVMe-re venni.

  Amit én még javaslok, az az ashift=12, a szektor méretet amit a ZFS alapegységnek használ, érdemes a default 9-ről megemelni (kettő a kilencediken, azaz 512 bájtról kettő a tizenkettedikre, azaz 4K-ra), bár sok 4K natív diszken felismeri a ZFS és ezt használja.

  Egyre több SSD jön (még azért nem mind) 8k szektormérettel, és mivel egy pool-on belül az ashift érték minden eszközre ugyanúgy érvényes, a gyors mindenféle írási és olvasási cache és metaadat SSD-k optimális kihasználtsága miatt érdemes akár 8K-ra venni a szektorméretet (ashift=13), ez a 4K-s vagy 512b-s HDD-knek sem gond amúgy, hiszen a kisebb számok többszöröse.

  atime off-ra, compression ízlés szerint, dedup off (ez a default amúgy) és akkor nem falja a RAM-ot (a rendszer RAM felét elveszi, de amint kéri egy app, visszaadja), ha esetleg használnál valami gluster vagy egyéb elosztott fájlrendszert felette, akkor érdemes az xattr=sa-t is beadni neki, nem nagy plussz metaadatban.

  - cache (L2arc) bármekkora lehet
  - special már nem feltétlen, nézd meg a statjaidat (zdb -Lbb <pool>) és látni fogod, melyik soron mi az érték a metaadatokra JELENLEG, special nélkül.. de olyan pool teljes méretének 1%-a egészséges lehet (persze nagyon pool függő, ezért érdemes statot nézni). Ha a special betelik, a HDD oldalon folytatódik a (vélhetően) most is megszokott módon a metaadatok és kis fájlok tárolása, szóval nempara, max lassulsz
  - ZIL/SLOG szintén ízlés szerint, azért ne 32 Gigásat..

  Szóval összességében egy komoly sebességű pool abszolút valid, de érdemes egy marék SSD-vel nekiállni. A legkönnyebb a cache eszköz, ha van egy SSD-d elfekvőben, bármikor hozzáadhatod az egészet, vagy csak egy partíciót róla (felül lesz írva), pl. mondjuk ha overprovisioning-elsz, hogy ne használja a teljes tárterületet, így valamivel lassabban kopik.

  Érdemes még a recordsize=1M-et is beadni neki, 16M-ig lehetne menni, de itt már nincs szignifikáns sebességkülönbség és sok helyen azt olvasni, hogy a default 128K és 1M között az optimum. Ez maximum érték, tehát ami ennél kisebb, az kisebb record-ba lesz kiírva, ami ennyi vagy ennél több, az pedig úgy. Hatása van a szekvenciális olvasásra, a tömörítés hatékonyságára, a párhuzamosíthatóságra és még jópár dologra, szóval egy 1 megás recordsize beállítással elég faja lehet egy vegyes mindent tartalmazó pool.

  (Ha csak és kizárólag nagy fájlok mennek rá, ami mondjuk nagyobb, mint hasraütök, 1 giga, lehet 16M is a recordsize érték, de marginális a haszna, 1M ideális max közeli, azt mondják).

  A nap végén rá fogsz jönni, hogy miután tanultál egy rahedli dolgot a ZFS-ről, úgy szar a pool-od, ahogy van.

  Ezen mindenki átmegy, aki ZFS-ezik
  (Szintén zenész).

  Iyenkor jön az, hogy ki mindent valahova máshova, majd HDD-k legyak, faszapool létrehoz, spéci device-okat alá betol, na és majd csak ekkor mehet minden rá vissza, kölcsön HDD-t megköszön.

Új hozzászólás Aktív témák