Visszatért a ZFS-re való telepíthetőség opció az Ubuntu 23.10 telepítőjébe

Fájlrendszer, NAS, storage

Tavasszal kikerült, most úgy tűnik visszatették. Jövőjét az Ubuntunál továbbra is homály fedi.

( bzt | 2023. 09. 17., v – 17:02 )

Szerkesztve: 2023. 09. 17., v – 17:09

Évekig használtam ZFS-t, először még SunOS alatt. Szerény véleményem szerint egy technikai zsákutca, nem is baj, ha nincs támogatva.

Nagy hype van körülötte, de az az igazság, hogy összemosni a virtuális diszkeket és a fájlrendszert nagyon nagyon nem jó ötlet, technikailag egyszerűen nem lehet hatékonyan megoldani. Nem is sikerült a ZFS-nek se :-)

A legtipikusabb hátrányai:
- rengeteg erőforrást zabál minden ZFS implementáció (hadd pazaroljuk csak a RAM-ot meg a CPU-t, ugye), a diszk overheadről nem is szólva
- igaz, hogy ritkán van vele baj, de ha egyszer baj van, szinte képtelenség bárminemű adatmentés (próbáltatok már egy elcrashelt ZFS-ről adatokat visszaállítani? Mármint amikor a legutolsó snapshot túl régi, és nem elég? Senkinek sem kívánom azt a szopást).
- a snapshot jól hangzó marketing bullshit, de valójában tök felesleges. Általában bőven megfelel a célnak egy verziókövető is, mint mondjuk a git. Sok-sok évnyi üzemeltetési tapasztalat mellett mondom, hogy még sosem, de tényleg sohasem fordult elő, hogy valóban szükség lett volna egy teljes fájlrendszert kompletten visszaállítani. Soha. A gyakorlatban mindig csak egy-két sérült vagy elkuffantott fájl korábbi verziója kellett.
- az adatkonzisztenciára is van sokkal hatékonyabb, kevesebb erőforrást pazarló (ráadásul immáron 50-60 éves) megoldás, lásd UFS vagy FILES-11 soft update-el
- a virtuális diszkkezelésre meg sokkal jobb és rugalmasabb (és üzemeltetési szempontból kevesebb szívás), ha egy külön független réteg biztosítja
- ugyanez igaz bármilyen fájlrendszer szintű inkrementális backup-ra is, sokkal jobb és kevesebb szívás, ha külön, függőségmentesen karbantartható a dolog

Anekdota, nem tudom, mennyire igaz, Sun mérnöktől hallottam. Egy egyetemen minden hallgató home-ját külön zvol-ra rakták a könnyebb quota kezelés érdekében. Minden jó is volt, amíg nem kellett a masinát újraindítani, a zfs bootolása majdnem egy teljes napig (!) tartott ennyi zvol mellett... Tegyük fel, hogy csak a fele igaz, még úgy is durva...

Ha ennyire sokat adsz kb. 20 évvel ezelőtti történetek anekdotává vált változatára, akkor a zfs valóban nem neked való:
Anno a ZFS nem támogatott user quota-t, így per user dataset-et csináltak. Valóban ha 10+ ezes nagyságrendű mountot csinálsz, az lassú (volt 20 éve).

Nem találkozok rendszeresen zfs crash-sel (az ubuntu zfs repója, ami plusz csomag ubuntu alatt, megér egy külön postot, ne használd, maradj simán annál ami az ubuntu kernellel jön és nem tartalmazza a ubuntu team próbálkozásait).
Amivel sokszor találkoztam az random data corruption, ezeket a zfs detektálja és automatikusan javítja megfelelő rendundancia esetén.
Linux mdraid esetén (raid1) random bithiba esetén bátran lemásolja azt is. Sok hardware raid esetén hasonló a helyzet vagy rosszabb esetben teljes adatvesztéssel jár. Ezt a ZFS probléma nélkül kezeli. (Sok külső storage a ZFS-hez hasonló módon blockonként alkamaznak checksummát.)

Nem tudok általános fájlrendszerről, ahol az adatokról checksumma készülne:
ext4, xfs, ufs stb. ilyet nem tud.

Transparent compression, dedupe, snapshot is nagyon hasznos funkciók (szerintem).

- zfs rengeteg erőforrás - tömörítés és deduplikációt leszámítva (amit nem kötelező használni) mi a lassú, hol a disk/ram/cpu overhead?
- snapshot helyett - persze, backup, tgz és sok minden használható helyette, de egyik se szebb vagy hatékonyabb
- soft update hogyan véd random bithiba ellen ami (legalábbis nagy pörgős disk esetében) gyakori?
- virtuális diszkkezelésre meg sokkal jobb és rugalmasabb... - miért?, példa?

Nem tudok általános fájlrendszerről, ahol az adatokról checksumma készülne

Hát épp ez a lényeg, nincs is rá szükség, ha ezt az eggyel alacsonyabb réteg már megteszi neked, a használt fájlrendszertől függetlenül. https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-int…
Pont ezért mondom, hogy a UNIX filozófia itt is érvényes: egy nagy monolitikus gigamegoldás helyett jobban megéri több, független réteget használni, ahol minden réteg csak a saját dolgát csinálja, de azt jól. Összességében a végeredmény rugalmasabb, és üzemeltetési szempontból a komponensek külön-külön is frissíthetők / karbantarthatók, míg a mindent-egybe-gigamegoldásnál erre esélyed sincs.

Transparent compression, dedupe, snapshot is nagyon hasznos funkciók

Valóban hasznos funkciók, de több fájlrendszer is tudja ezeket, nemcsak a ZFS, és megintcsak, ez nem is a fájlrendszer dolga. Ha már komoly szerverekről beszélünk, egy Hitachi storage teljesen transparensen megoldja, a fájlrendszer lényegtelen.

soft update hogyan véd random bithiba ellen

Sehogy, de nem is az a dolga. Az arra való, mint a journaling, a konzisztencia biztosítására.

virtuális diszkkezelésre meg sokkal jobb és rugalmasabb

És megintcsak, ha tényleg komoly szerverről beszélünk, egy Hitachi storage megoldja ezt neked csuklóból. De ha csak félig komoly szerverről beszélünk, Solaris alatt például használhatsz SVM-et vagy VxVM-et, mindkettő többet tud, és rugalmasabb, mint a ZFS implementáció (tudom, ez már hit kérdése, hogy a CLI-juk jó-e, de most szigorúan a megvalósított funkciókról beszélek csak.) Linux alatt meg sokkal jobban karbantatható, ha ezt egy független LVM-el csinálod (a fájlrendszert és a volume managert tudod egymástól függetlenül is frissíteni).

Hát épp ez a lényeg, nincs is rá szükség, ha ezt az eggyel alacsonyabb réteg már megteszi neked, a használt fájlrendszertől függetlenül. https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-int…

A fizikai storage (HDD/SSD) is tárol checksumot, sőt adott esetben a transzport is, mi szükség erre felsőbb rétegekben? :)

A fenti megoldással hogyan szerzel tudomást arról, hogy mely fájljaid sérültek egy hiba esetén? A ZFS ezt azonnal (értsd: gyorsan) megmondja.

egy Hitachi storage teljesen transparensen megoldja, a fájlrendszer lényegtelen

A Hitachi storage milyen hatékonysággal tömörít le egy csupa "A"-kból álló, mondjuk 1 TB-os fájlt, amit a fájlrendszer a töredezettség miatt egyenletes eloszlással írt ki a teljes LBA-térben 512/4k-s blokkokban? Mennyi adatot fog áttolni a HBA-don a fájlrendszer ebben az esetben oda-vissza?
Mennyit kell szívni azzal, hogy eltérő beállításokat (valahol tömörítés nélkül, máshol gyors tömörítéssel, megint máshol maximális tömörítéssel) szeretnél alkalmazni eltérő területeken, és ezeket milyen rugalmassággal tudod kezelni? (pld. nagyon szépen elketyeg a rendszered egy maximális tömörítésű területen, de hirtelen nagyon durva terhelés érkezik, amit már nem bír kiszolgálni, ezt a ZFS-ben felmenő rendszerben tudod állítani ide-oda)

A fenti megoldással hogyan szerzel tudomást arról, hogy mely fájljaid sérültek egy hiba esetén?

Nem is sérülnek fájlok egyáltalán, a raid gondoskodik róla, hogy a fájlrendszer segge alá mindig helyes adatokat tartalmazó szektorok kerüljenek, neked meg bőven elég azt tudni, melyik a hibás diszk, amit mielőbb cserélned kell. (És ha a ZFS alatt egy szektorhiba esetén tényleg megsérülhet fájl, akkor meg megint, minek is használnám?... de egyébként nem, ZFS alatt sem sérülnek a fájlok egy szektorhiba esetén, ezt tudnod kéne, ha már ZFS-t használsz)

A Hitachi storage milyen hatékonysággal tömörít le... Mennyit kell szívni azzal, hogy eltérő beállításokat...

A kérdéseidből látszik, hogy nem vagy képben. Csupán pénz kérdése, mennyire feltunningolt storage-ot vásárolsz. Ez egy hardware-s megoldás (és ilyeneket úgy kell konfolni benne, hogy kihívod a certified mérnököt, aki megcsinálja helyetted, mert Te nem is nyúlhatsz hozzá). Nagy, komoly szervereknél ez így szokás. Egy IBM Mainframe-be se túrkálhatsz csak úgy bele.

Más világ na, amit nem is ismersz. Tényleg nagy és komoly szerverek esetében eleve vasból van megoldva mindaz, amire a ZFS megoldást ígérhet, ezért ott (is) felesleges a ZFS.

Nem is sérülnek fájlok egyáltalán, a raid gondoskodik róla, hogy a fájlrendszer segge alá mindig helyes adatokat tartalmazó szektorok kerüljenek

Sok minden kavarodik már itt, és persze rengeteg technológiai megoldás van, nem is világos, hogy a fenti kijelentést mire teszed, de az biztos, hogy csak ez a mondat önmagában nem állja meg a helyét. A "RAID" önmagában nem gondoskodik arról, hogy a fájlrendszer segge alá helyes adatok kerüljenek.

Bizonyos szintjei, bizonyos implementációi (a paritás miatt pld) képesek lehetnek erre, de itt is találkozhatsz adatkorrupcióval.
Ahhoz ugyanis, hogy a RAID (jellemzően 5,6) implementációd detektálja ezeket, be kell azokat olvasnia (bit rot). Ez történhet egy normál olvasás során is (amely ugye nem garantált, hogy a teljes tartalomra megtörténik, ebben tehát nem bízhatsz), vagy a rendszeres scrub alatt (amit tipikusan alacsony IO intenzitással végeznek, hogy ne befolyásolja a normál IO-t).

Én csak nagyon apró rendszerekkel foglalkoztam az elmúlt 26 évben (egyidejűleg párszáz szerver, párezer diszk, később SSD), de főleg a 2000-es évek elején nem volt jellemző az, ami ma, hogy olyan bőséges IO kapacitás lett volna, így nem volt ritka, hogy egy scrub egy, vagy több hónapig is eltartott. Ennyi idő pedig bőven elég ahhoz, hogy egy nagyobb rendszerben egyszerre több diszken is korrupció legyen, és mint említettem, hiába ilyen alacsony számú eszköz, számtalan esetet tudok neked említeni, amikor tényleges adatkorrupció történt, és ezzel sok vicces éjszakát eltöltöttünk.

Hiába a RAID, ez ellen nem véd, még az sem, amelyik elvben igen.

És ilyenkor igen kellemetlen a következő kérdés: mi sérült valójában? Nem tudod.

ZFS alatt sem sérülnek a fájlok egy szektorhiba esetén

Ez is egy önmagában értelmezhetetlen kijelentés. Attól függ, hogy mit használsz (nincs redundancia, mirror, raidz, draid...), és hogy egyidejűleg mennyi hiba volt, és hol (pld. ugyanannak a rekordnak a replikája/paritása sérült), illetve milyen gyorsan tudod detektálni a hibát (scrub, read), milyen gyorsan tudsz gondoskodni csereeszközről (fizikai csere, spare), és milyen gyorsan tudja azt újraépíteni (ZFS-nél resilver).
Szintén el kell mondjam, hogy nem is szektorhiba, hanem komplett dupla diszkhiba is bőven volt a karrierem során (azaz nem volt idő olyan gyorsan újraépíteni az új diszket, hogy a következő ne hulljon el), de kb. 200 diszkkel egyszer belenyúltunk egy FW hibába is, amely idő előtt kinyírta a diszkeket (! nem SSD, ezek pörgő rozsdák voltak még), és volt, hogy egy hónap alatt 60 diszk halt meg, volt izgulás rendesen, de sajnos hiba is.

Na és itt jön képbe a szerény világlátásod: amikor a "RAID mindent megold"-ban gyorsabban hullik a diszk, mint ahogy a rebuild halad, a te szegmentált, UNIX filozófiádban a RAID6-nál a harmadik diszkhibánál meg vagy lőve, töltheted vissza a backupot (ha van), a ZFS-nél viszont még ilyen esetben is elérhető lehet, ami fizikailag megvan, ráadásul nagyon pontosan látod, hogy mi az, ami nincs meg. Felbecsülhetetlen, ha egyszer is átéltél már ilyet, főleg úgy, hogy a szarrá terhelt (kieső diszkek eleve lassítanak, a rebuild méginkább lassít, emiatt minden torlódik, a backup sem tud futni, így azt is a hajadra kenheted), félholt rendszerről kell valamit visszanyerned, és mindenki azt kérdezgeti, hogy: jó, de mekkora része van meg az adatnak?

Sok sikert a válaszhoz a RAID+külön FS-sel. :)

Csupán pénz kérdése, mennyire feltunningolt storage-ot vásárolsz.

Amit ugye a ZFS-sel ingyen megkapsz.

Ez egy hardware-s megoldás (és ilyeneket úgy kell konfolni benne, hogy kihívod a certified mérnököt, aki megcsinálja helyetted, mert Te nem is nyúlhatsz hozzá). Nagy, komoly szervereknél ez így szokás. Egy IBM Mainframe-be se túrkálhatsz csak úgy bele.

Kivéve, ha kell, mert áll a bál, és a certified mérnökúr amúgy fele annyit nem látott, mint te.

A hardware-es megoldással nem oldod meg azt, amit írtam, illetve egy részét legfeljebb masszív overbookinggal.

Tényleg nagy és komoly szerverek esetében eleve vasból van megoldva mindaz, amire a ZFS megoldást ígérhet, ezért ott (is) felesleges a ZFS.

Hányszor hallottam ezt, és ha tudnád hány elkeseredett arcról van hajnali háromkor fényképem, akik ott állnak a certified mérnökúr feje fölött a gépteremben, és azt kérdezgetik, hogy: mi történt? Hol az adat? Miért nem megy semmi? Mikor fog menni?

A mérnökúr meg csak annyit tud mondani, hogy ő sem érti, ennek a FW upgrade-nek a redundáns storage controllereken probléma nélkül le kellett volna futnia, de mégis az egyik kinullázta a teljes adatterületet, és most van két petabájtnyi kiosztható tárhelyünk. Mert a közhiedelemmel ellentétben azokon is ugyanolyan szoftver fut, mint a ZFS. (emberek írják, és néha hibáznak).

De csak neked még egy sztori: az egyik kedvencem, amikor muszáj volt valami SAN-ról adatterületet használnunk, mert csak ott volt szabadon. ZFS került arra is, és pár év múlva meg is érkezett az első checksum hiba (goto fent: mivel a storage "megoldja", ZFS szinten nem volt redundancia, így ezt adatkorrupció).
Az üzemeltetők olyan szűklátókörű emberkék voltak, mint te, a képzettebbje (a legtöbbnek fingjuk sincs amúgy hogy működik egy ilyen belül, csak a CLI-t/UI-t tudják röcögtetni) rögtön rávágta, hogy szar a szoftver, amit használunk, meg biztos a SAN-ban (értsd: FC szinten) korruptálódott az adat. Jó, rájuk hagytuk, biztos így volt, lezártuk.

Aztán később egy adatbázis omlott össze adatkorrupcióval (mert ugye a RAID megoldja, hogy helyes adatok, blabla), amit már nem tudtak ennyivel lepattintani. Hosszas debug után az eredmény egy új FW verzió lett a storage-on, amiben -meglepetéés- egy adatkorrupciós hibát javítottak.

Más világ na, amit nem is ismersz

A hozzászólásaidból azt látom, hogy vagy oltári szerencséd volt, vagy a nagy számok törvénye elkerült téged eddig, szóval részemről is ennyivel zárnám. :)

a) a zvol egy antipattern, szinte bármire, ebből azért ne vonjunk már le messzemenő következtetéseket

b) biztos rengeteg erőforrást zabál, de ezt egy ~10 éves 32GB RAM-mal ellátott Haswell gép észre sem veszi - egy jobb mai laptop simán combosabb

c) örülök, hogy szerinted a ZFS snapshot helyett van más, mondjuk a git, de nekem sajnos nem sikerült rájönnöm, hogy ~15GB-nyi bináris fájl verzióit (egy Linux build env, amiben csomagok fordulnak és amibe beépülnek - á la rolling distro) hogyan lehetne git repóban hatékonyan tárolni...

d) örülök, hogy még sosem kellett egy komplett fájlrendszer egy vagy több korábbi állapotát ÉS a jelenlegi állapotát egyszerre elérhetővé tenned, de másoknak erre néha szüksége van

e) örülük, hogy sok hatékony módszert ismersz egy online, használatban levő fájlrendszer aszinkron lemásolására (és aszinkron kvázi up-to-date tartására folyamatosan) egy másik gépre, de nekem valahogy egyetlen egy sem jut eszembe, mert ami igen, az a fentiek közül valamit nem tud - a legtöbbször a "hatékony" szónál lesznek a gondok

biztos rengeteg erőforrást zabál, de ezt egy ~10 éves 32GB RAM-mal ellátott Haswell gép észre sem veszi - egy jobb mai laptop simán combosabb

Szóval csak azért pazaroljunk erőforrást, mert van?

de nekem sajnos nem sikerült rájönnöm, hogy ~15GB-nyi bináris fájl verzióit (egy Linux build env, amiben csomagok fordulnak és amibe beépülnek - á la rolling distro) hogyan lehetne git repóban hatékonyan tárolni...

Sehogy, mert nem is arra való. A git nem váltja ki a rendszerszintű backup-ot, ilyent sosem állítottam, azt viszont igenis állítom, hogy egy normális, valamirevaló backup egy független helyre kerül, és nem pedig pont ugyanarra a diszkre, mint a ZFS esetén.

a legtöbbször a "hatékony" szónál lesznek a gondok

A ZFS sem hatékony, szóval...

Szóval csak azért pazaroljunk erőforrást, mert van?

Nincs pazarlás, ez egy félreértés. A rendszer működéséhez erőforrások kellenek. Ezek rendelkezésre állnak. Ameddig az erőforrás használat egyáltalán nem észlelhető a felhasználó számára, addig nincs is miről beszélni.

A git nem váltja ki a rendszerszintű backup-ot,

Az a gond, hogy az volt a javaslatod, hogy nincs is szükség a snapshotra, mert pl. a git kiváltja. Majd most megmondod, hogy nem is váltja ki, de ez nem is baj, mert a backupot nem is kell kiváltania. "Apró" probléma, hogy az én use-case-emben nem rendszerszintű backupra használom a snapshotot. Ergó a normális, valarmirevaló backup nem oldja meg a use-case-emet, de persze a git sem, mert valójában nem alkalmas rá. Most akkor eljutottunk oda, hogy megkérdőjelezed a use-case-emet?

A ZFS sem hatékony, szóval...

Az empírikus tapasztalatok szerint a leghatékonyabb az adott célra. De jöhetsz, és mutathatsz hatékonyabbat, hiszen szerinted bármire is használom a snapshotot, arra biztosan nincs szükség, mivelhogy van jobb (gondolom hatékonyabb is) megoldás a problémámra.

Nagy részében egyetértek veled, de az szerintem túlzás, hogy az egész ZFS technikai zsákutca. Maradjunk abban, hogy desktop OS telepítés root partíciója alá a ZFS overkill, ha snapshot kell, akkor Btrfs (vagy valami más inkrementális backup megoldás) elég, azt sokkal több disztró kezeli rootnak és az erőforrásigénye is kisebb. ZFS-nek inkább szerveren, NAS-on, ilyesmin van értelme, ahol tényleg redundancia kell, és a RAID-et kiváltod vele, meg itt meglesz hozzá az extra erőforrás is (RAM, CPU). Persze, ettől lehet még rendszert ZFS-re telepíteni, akár más disztrón is kiügyeskedhető, a mentő még senkit nem vitt el, aki megpróbálta, de lényegében ágyúval verébre megoldás. Modern desktop gépek, laptopok meg se érzik kellően combos procival és elég RAM-mal, de szerintem is pocsékolás, és úgy általában túl van hájpolva.

Emiatt én FreeBSD-t is mindig UFS-sel telepítek, mert ott sem tartom a ZFS-t rendszer alá szükségesnek, pedig ott még több értelme van ugyebár, mert ott a Btrfs nem játszik.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Nagy részében egyetértek veled, de az szerintem túlzás, hogy az egész ZFS technikai zsákutca.

Azért mondom annak, mert desktop-ra valóban overkill, szervernél meg vannak komolyabb / jobb megoldások (többnyire hardware-s). Egyébként ne értsetek félre, vannak benne zseniális megoldások, csak épp egy olyan problémát próbál megoldani, ami igazából nem is probléma, vagy vannak egyszerűbb és jobb módszerek a megoldására. Ezért nem látom értelmét.

ZFS-nek inkább szerveren, NAS-on, ilyesmin van értelme

A NAS-ra lehet, hogy jó, de egy komolyabb szerver esetén úgyis valami komolyabb storage kerül alá, tehát felesleges.

Emiatt én FreeBSD-t is mindig UFS-sel telepítek

+1, tökéletesen egyetértek az érveléseddel.

hogy összemosni a virtuális diszkeket és a fájlrendszert nagyon nagyon nem jó ötlet, technikailag egyszerűen nem lehet hatékonyan megoldani

márpedig de. a layereket szétválasztani nagyon szép dolog, csak nem a gyarkorlatban (másik szép példa erre a iso/osi network modell). nagyon sok mindent csak a filesystem tud, amire viszont szüksége lenne a raid-nek

csak a legtipikusabb példa: létrehozol egy linux raid 5öt és végignyalja a sok terabyteos diszket... minek? vagy ne beszéljünk a TRIM-ről, ugye...

 

rengeteg erőforrást zabál minden ZFS implementáció (hadd pazaroljuk csak a RAM-ot meg a CPU-t, ugye), a diszk overheadről nem is szólva

pont annyi memóriát eszik, amennyit megadsz neki. én még egy 4GB-os gépben is használok zfs-t

 

igaz, hogy ritkán van vele baj, de ha egyszer baj van, szinte képtelenség bárminemű adatmentés (próbáltatok már egy elcrashelt ZFS-ről adatokat visszaállítani? Mármint amikor a legutolsó snapshot túl régi, és nem elég? Senkinek sem kívánom azt a szopást).

nekem egyszer sikerült megomlott hw raid-on lévő zfs-ről visszaszedni adatokat...

 

a snapshot jól hangzó marketing bullshit, de valójában tök felesleges. Általában bőven megfelel a célnak egy verziókövető is, mint mondjuk a git. Sok-sok évnyi üzemeltetési tapasztalat mellett mondom, hogy még sosem, de tényleg sohasem fordult elő, hogy valóban szükség lett volna egy teljes fájlrendszert kompletten visszaállítani. Soha. A gyakorlatban mindig csak egy-két sérült vagy elkuffantott fájl korábbi verziója kellett.

te sosem szoktál upgradelni? én minden upgrade előtt snapshotolok... konténereket, root filerendszert... sőt, a laptopomon is 5percenként, bizonyos dataset-ekre... és mesélj, tudsz hatékonyabb inkrementális backup megoldást, mint a zfs send/receive?

 

az adatkonzisztenciára is van sokkal hatékonyabb, kevesebb erőforrást pazarló (ráadásul immáron 50-60 éves) megoldás, lásd UFS vagy FILES-11 soft update-el

2023-at írunk, csaxólok

csak a legtipikusabb példa: létrehozol egy linux raid 5öt és végignyalja a sok terabyteos diszket... minek?

És szerinted a ZFS nem nyalja végig a snapshotokat, hogy kiszámolja, jók-e a checksum-ok? De, ugyanúgy végignyal mindent.

pont annyi memóriát eszik, amennyit megadsz neki. én még egy 4GB-os gépben is használok zfs-t

És mekkora a diszk elérés overhead alacsony RAM használtság mellett? Fogadjunk, hogy bármilyen másik fájlrendszerrel százszor gyorsabb lenne a diszked.

nekem egyszer sikerült megomlott hw raid-on lévő zfs-ről visszaszedni adatokat...

Na itt a tökéletes példa. Úgy üzemeltetsz ZFS-t, hogy fingod sincs arról, valójában hogy működik az alsóbb szinteken. ZFS esetén kötelező a soft raid, így hw raid-re rakni eleve elvetemült és hulla felesleges dolog. És egyébként is, ha van hw raid-ed, akkor pl. egy ext-ről is éppúgy vissza tudtad volna nyerni az adatokat, ez egyáltalán nem is a ZFS érdeme...

2023-at írunk, csaxólok

Ezért is siralmas, hogy a mai korosztály elfelejtette a korábban megalkotott jó megoldásokat, és csak újra fel akarja találni a spanyolviaszt. Ez persze tapasztalat hiányában nem sikerül neki. Csak azért, mert a soft update már 50 - 60 éves, egyáltalán nem jelenti azt, hogy elavult lenne, az algoritmusok ugyanis nem szoktak elavulni (csak egy konkrét technikai implementációjuk maximum).

Vegyük például az RFC1951 deflate-t. Hiába 50 - 60 éves, mind a mai napig számtalan helyen használják, és még fogják is sokáig. Nem lett elavult, csak mert időközben lett bzip2 meg ZStandard. (Ennek egyébként az is az oka, hogy egy deflate kicsomagolót meg lehet írni memóriakezelés nélkül, még trehányan kódolva is 20k-ból, míg a zstd hiába gyorsabb és jobb rátájú, mindenképp sok sok megányi dinamikusan allokált RAM kell neki, és lehetetlen a kódot 1M alá szorítani.)

A soft update ugyanez. Az, hogy a kiírandó adatokat egyszerűen sorbarendezzük úgy, hogy minden kiírás után konzisztens legyen a diszken lévő bitkolbász, mindig működni fog, akármi legyen is a fájlrendszer konkrét formátuma. Ez a módszer egyszerűen nem tud elavulni, és csakis erőforrásigényesebb megoldásokkal váltható ki, amik egyáltalán nem biztos, hogy megérik. És megintcsak, ez egy fájlrendszerfüggetlen megoldás, tehát a konzisztencia megint valami, amit nem a fájlrendszerben érdemes megoldani.

És szerinted a ZFS nem nyalja végig a snapshotokat, hogy kiszámolja, jók-e a checksum-ok? De, ugyanúgy végignyal mindent.

Létrehozásról volt szó. A zpool létrehozása (hacsak nincs előtte trim) kb. instant, nem számolgat semmit, nem nyal végig semmit.

Amiről esetleg beszélhetsz, a scrub, amikor a te kérésedre végignézi a teljes adatot (csak a ténylegesen tárolt adatot, azaz ha van egy 200 TB-os storage-od, amin tárolsz 20-at, csak azt a 20-at, nem a 200-at, mivel ugye egyben van az általad kettőben vágyott réteg, így trim nélkül is tudja, hogy mit tárol).

A snapshotokat nem nyalja végig (vagy mást értesz snapshot alatt, mint a ZFS).

És mekkora a diszk elérés overhead alacsony RAM használtság mellett? Fogadjunk, hogy bármilyen másik fájlrendszerrel százszor gyorsabb lenne a diszked.

Workload függő. Van, hogy ZFS alatt százszor gyorsabb.

Úgy üzemeltetsz ZFS-t, hogy fingod sincs arról, valójában hogy működik az alsóbb szinteken. ZFS esetén kötelező a soft raid, így hw raid-re rakni eleve elvetemült és hulla felesleges dolog

Egyrészt nem kötelező, másrészt van, hogy az élet úgy hozza, hogy nincs más megoldásod. Mi pörgettünk olyan HW-eket (adottság), ahol a HW RAID vezérlőben ha csináltál 100 darab RAID0-át (passthrough-t nem tudott), akkor lehasalt, nem bírta a CPU-ja, így több RAID1-et, vagy több diszkes RAID0-át (tudom, csúnya) kellett létrehozni.
A másik vicces dolog az volt, amikor eleve csak x RAID0-át tudsz emellé még létrehozni, azaz rajta van 100 diszked, de mondjuk 30 a korlát.

És egyébként is, ha van hw raid-ed, akkor pl. egy ext-ről is éppúgy vissza tudtad volna nyerni az adatokat, ez egyáltalán nem is a ZFS érdeme

A ZFS-ről jó esetben azt tudod visszanyerni, ami megvan a diszkeken.
Ha mákod van, ez valami, míg egy HW/SW RAID+akármilyen FS esetében ez a semmi.

Létrehozásról volt szó. A zpool létrehozása (hacsak nincs előtte trim) kb. instant, nem számolgat semmit, nem nyal végig semmit.

Mint ahogy a többi volume manager se. Asszem kevered a raid réteget a volume réteggel, mondjuk aki csak ZFS-t ismeri, attól nem is meglepő, hogy nincs tisztában a dolgokkal.

Workload függő. Van, hogy ZFS alatt százszor gyorsabb.

Citation needed! Kérlek csinálj egy ZFS-t, állítsd a RAM buffert a lehető legkissebre, majd adj rá terhelést (mondjuk update-elj és kérj le egy sqlite fájlt 1 milliószor.) Aztán végezd el pontosan ugyanezt a terhelést egy ext4 alatt lévő fájlon, és prezentáld nekünk a mérési éredményeket, akkor majd elhiszem. Addig marad a saját és kollégáim tapasztalata, miszerint kicsi RAM buffer esetén a ZFS teljesítménye beleáll a földbe.

Egyrészt nem kötelező, másrészt van, hogy az élet úgy hozza, hogy nincs más megoldásod.

Hát de. https://www.giis.co.in/Zfs_ondiskformat.pdf Másrészről az élet általában úgy hozza, hogy egy hw raid önmagában, ZFS nélkül is elég ahhoz, hogy ne veszítsél adatokat.

A ZFS-ről jó esetben azt tudod visszanyerni, ami megvan a diszkeken.
Ha mákod van, ez valami, míg egy HW/SW RAID+akármilyen FS esetében ez a semmi.

Ekkora baromságot rég olvastam. Látom veled nem lehet értelemes vitát lefolytatni, mert alapszintű fogalmakkal sem vagy tisztában. (Miheztartás végett, szerinted ha igaz lenne, hogy egy hw raid-ből nem lehet visszanyerni adatokat, akkor mi a rákfenének használnák az emberek??? Merthogy bizony rengetegen használnak hw raid-et ZFS nélkül.)

Mint ahogy a többi volume manager se. Asszem kevered a raid réteget a volume réteggel, mondjuk aki csak ZFS-t ismeri, attól nem is meglepő, hogy nincs tisztában a dolgokkal.

Miért keverném? Egy zpool create 200 diszkkel, raidz2-vel pár másodperc. Ebben benne van a RAID, a volume manager és a fájlrendszer réteg, ha úgy szeretnéd.
Hozz létre kérlek egy bruttó 800 TB-os RAID6-ot (nekem mindegy milyen elrendezésben, hány darabból), tegyél rá egy volume-ot és egy fájlrendszert. Akkor állítsd le a stoppert, amikor kész a feladat, és nincs IO sehol.

A ZFS ezt minimális IO-ból megoldja, mások vagy végigdarálnak mindent, vagy valami indirekciót alkalmaznak.

Citation needed!

Bőven elhiszem, hogy találsz olyat, ahol a ZFS lassú, sokat használtam. Az IO-val tapasztalataim szerint is sokkal pazarlóbban bánik, mint a régi FS-ek. Mondjuk ezért ad is bőven...

De hogy ne kelljen így meghalnod, mondok én is példát: volt egy alkalmazásunk, ami sok fsyncet csinált, és amúgy rengeteg adatot írt, de sűrűn előfordult, hogy ebben üres, illetve nagyon jól tömöríthető részek voltak (pld. rendezett listák). HDD-ken (szűk IO) fényévekkel gyorsabb volt a zfs, mint mondjuk az ext4.

Másrészről az élet általában úgy hozza, hogy egy hw raid önmagában, ZFS nélkül is elég ahhoz, hogy ne veszítsél adatokat.

Általában. Aztán sokszor nem.

Miheztartás végett, szerinted ha igaz lenne, hogy egy hw raid-ből nem lehet visszanyerni adatokat, akkor mi a rákfenének használnák az emberek??? Merthogy bizony rengetegen használnak hw raid-et ZFS nélkül

Látom, kicsit bunkó a stílusod, de azért válaszolok. Ott van egy 16 diszkes RAID6-od, amiből elbuktál három lemezt. Legyen ez egy RAID kártyán a gépedben, vagy a kurva drága Hitachi storage-odon.

Nyerj ki valami adatot pls. (tudom, lehetetlen, hogy egyszerre ennyi diszket veszíts, OK)

Hozz létre kérlek egy bruttó 800 TB-os RAID6-ot (nekem mindegy milyen elrendezésben, hány darabból), tegyél rá egy volume-ot és egy fájlrendszert. Akkor állítsd le a stoppert, amikor kész a feladat, és nincs IO sehol.

bzt még egy dm-integrity-t is betolna a software raid alá... na, azt megkockáztatom, hogy kb. egy hétbe kerülne... egyszer az integritysetup, utána a md...

 

De hogy ne kelljen így meghalnod, mondok én is példát: volt egy alkalmazásunk, ami sok fsyncet csinált, és amúgy rengeteg adatot írt, de sűrűn előfordult, hogy ebben üres, illetve nagyon jól tömöríthető részek voltak (pld. rendezett listák). HDD-ken (szűk IO) fényévekkel gyorsabb volt a zfs, mint mondjuk az ext4.

egy másik példa: mysql slave-ed van, azt akarod, hogy érje utol a mastert... zfs-n simán kikapcsolod a sync-et erre az időre... ez gyarkorlatilag azt jelenti, hogy a fsync hazudik.. de gyors :) (persze, előtte nem árt a snapshot)

 

Általában. Aztán sokszor nem.

én úgy tudom, hogy pl. a raid6 csak hiba esetén szokta megjavítani, újraírni a diszken a hibás blokkot, a bitrotot nem detektálja meg menet közben.

ha scrubbolod, nyilván észreveszi, mert nem talál a parity, ugye... ha szerencséd van és a bitrot a parity diszken történt, akkor azt újraszámolja, újraírja... de ha nem parity diszken van, akkor annak az adatnak lőttek... de javítsatok ki

lehet, hogy a drága hitachi vagy netapp storage-ok hashelnek adatokat (de nem hiszem), de a sima raid vezérlők nem... 

Aztán végezd el pontosan ugyanezt a terhelést egy ext4 alatt lévő fájlon, és prezentáld nekünk a mérési éredményeket, akkor majd elhiszem

Bocs, nem sok időm van ezekre, de bepötyögtem neked hirtelen valamit. A mérési eredményeket prezentált kérlek te. Egy akármilyen pythonnal indítsd el, mondjuk python hupzfs.py 1 paranccsal, az ext4-et, meg a zfs-t a /data könyvtárba rakd.

Itt a script:

https://gist.github.com/bra-fsn/29df78dcffcd72fd5bbb37fd45173100

Olyan eszközön próbáld, ami sávszélességben és/vagy IOPS-ben limitált (pld. egy sima merevlemezen). Nem próbáltam, de az egyik olyan use case-t próbál bemutatni, amivel jó sok éve szembesültem.

Ha a kódból nem lenne egyértelmű, leírom mi a baj: az ext4 egy fd-n történő fsync hívásra az összes "útban" lévő adatot kiírja diszkre, nem csak azt az adatmennyiséget, amit te valójában syncelni szeretnél. Ez bizonyos helyeken rengeteg felesleges adatot jelent, ami durván visszafogja a teljesítményt, a zfs-en pedig megdobja azt.

Nálunk ez egy helyen még azzal is "súlyosbítva" volt, hogy a példához hasonlóan a kiírt adatok nagyon jól tömöríthetők voltak, amin szintén sokat segített a zfs on the fly tömörítése.

Próbáltam megkeresni, hogy az ext4 így működik-e még, ezt találtam: https://lwn.net/Articles/842385/

With ext4, as a side effect of the filesystem structure, all pending data and metadata for all file descriptors will be flushed instead. This creates a lot of I/O traffic that is unneeded to satisfy any given fsync() or fdatasync() call.

Persze ez sem mai, lehet, hogy azóta fejlődött. Mondjuk sokat számomra ez nem jelentett volna, mivel ezzel több, mint 10 éve szoptam. :)

És szerinted a ZFS nem nyalja végig a snapshotokat, hogy kiszámolja, jók-e a checksum-ok? De, ugyanúgy végignyal mindent.

filerendszer létrehozáskor? nem :D

 

És mekkora a diszk elérés overhead alacsony RAM használtság mellett? Fogadjunk, hogy bármilyen másik fájlrendszerrel százszor gyorsabb lenne a diszked.

a nvme ssd-k világában? sokkal fontosabb a megbízhatóság.

 

Na itt a tökéletes példa. Úgy üzemeltetsz ZFS-t, hogy fingod sincs arról, valójában hogy működik az alsóbb szinteken. ZFS esetén kötelező a soft raid, így hw raid-re rakni eleve elvetemült és hulla felesleges dolog. És egyébként is, ha van hw raid-ed, akkor pl. egy ext-ről is éppúgy vissza tudtad volna nyerni az adatokat, ez egyáltalán nem is a ZFS érdeme...

ki mondta, hogy fingom nincs? azt mondtam, hogy ilyen volt a rendszer, ez történt. egyszer meghalt az egyik diszk, amit nem vettek észre, majd meghalt a másik is... ezt kicserélték, majd a raid kontroller újraépítette a tömböt az első hibás diszk alapján, amin 2 hónappal korábbi adatok voltak. amúgy meg ext-ről gyenge eséllyel lehet visszaszedni.

 

Ezért is siralmas, hogy a mai korosztály elfelejtette a korábban megalkotott jó megoldásokat, és csak újra fel akarja találni a spanyolviaszt. Ez persze tapasztalat hiányában nem sikerül neki. Csak azért, mert a soft update már 50 - 60 éves, egyáltalán nem jelenti azt, hogy elavult lenne, az algoritmusok ugyanis nem szoktak elavulni (csak egy konkrét technikai implementációjuk maximum).

félrebeszélsz, nem ezt mondtam. azt mondtam, hogy 2023-ban teljesen más igények vannak egy filerendszert illetően: igenis, a COW az alap, a data checksumming az alap, a snapshotting az alap, a self data healing az alap. És nincs egy stabil filerendszer linuxra, ami ezeket tudná. És nyilván, sok feature, több erőforrás.

 

az algoritmusok ugyanis nem szoktak elavulni

bocs, de ez LOL. akkor te még divx-ben nézed a filmeket? :D

 

Lehet, hogy te nem szereted a zfs-t, de tudod: már bizonyított. Mondhatni, meg van csinálva rendesen.

 

És megintcsak, ez egy fájlrendszerfüggetlen megoldás, tehát a konzisztencia megint valami, amit nem a fájlrendszerben érdemes megoldani.

gyere, meséld el, hogy egy csoda linux RAID hogy fogja neked az adatokat kijavítva tárolni egy esetleges bit flip/rot esetén? sehogy. kontroller rossz adatot ad, a szoftver rossz adatot kap.

a nvme ssd-k világában?

Hol számít, amikor a szűk keresztmetszeted a kicsi RAM buffer és nem is az IO throughput?

azt mondtam, hogy ilyen volt a rendszer, ez történt.

Én meg azt mondtam, hogy hw raid esetén más fájlrendszerrel is működött volna a dolog, nemcsak ZFS-el.

azt mondtam, hogy 2023-ban teljesen más igények vannak egy filerendszert illetően

Na látod, ez az, ahol totális tévedésben élsz. A konzisztencia és az adatintegritás 60 évvel ezelőtt is éppúgy fontos volt, sőt, még jobban, mert az akkori hw-k sokkal megbízhatatlanabbak voltak, mint a maiak. A mondandóm lényege, hogy mára már elfelejtették, hogy akkoriban a kevés erőforrásal rendelkező gépek esetén is hogy-hogynem, meg tudták oldani ezeket. Hogy klasszikust idézzek: "a könyveket olvasni kellett volna, nem elégetni". Így már érted?

bocs, de ez LOL. akkor te még divx-ben nézed a filmeket? :D

És Te komolyan azt hiszed, hogy a divx egy algoritmus??? Atyaég. Az egy kodek, ami számos különböző algoritmus egy konkrét implementációja.

Például egy zlib implementáció elavulhat, de a Huffmann-kódolás algoritmusa soha. Ha valaki csinál egy SIMD-es zlib implementációt, akkor azzal csak az implementáció változik, maga az Huffman-kódolás algoritmusa nem... Az, hogy valaki egy tök új algoritmussal rukkol elő, ami kevesebb erőforrást igényel, miközben hatékonyabb is, nem elképzelhetetlen, de eddig még nem történt meg. Ugyanez van a soft update-el is, léteznek más megoldások is (journaling pl), de azok erőforrásigénye SOKKAL nagyobb (ráadásul speciális bitkolbászt kell tárolni a diszken, míg a soft update esetében nincs ilyesmire szükség).

meséld el, hogy egy csoda linux RAID hogy fogja neked az adatokat kijavítva tárolni

Egyszer már leírtam, de leírom mégegyszer: kevered a szezont a faszommal, pedig a kettő, hidd el nekem, nagyon nem ugyanaz.

A konzisztencia és az integritás ugyanígy, két, teljesen különböző dolog. Nyilván az egyikre adott megoldás nem fogja a másik problémát is varázsütésre megoldani. ZFS esetén sem oldja meg, megsúgom. Olvasd csak el a ZFS specifikációt, mindjárt azzal nyit, hogy három réteget is kénytelen integrálni, hogy ez is, az is legyen benne. És mégegyszer, ezeket értelmes rendszerek fájlrendszerfüggetlenül, kis erőforráspocsékolás mellett is képesek megoldani.

(Egyébként meg a RAID jelentése "Redundant Array of Inexpensive Disks", és mint a neve is suggalja, az adatokat redundánsan tárolja, tehát megvan benne a helyes adat (is). De nem, ennek semmi köze sem a konzisztenciához (minden metaadat mindenkor érvényes állapotban van a diszken), sem az integritáshoz (melyik adat ellenőrzőösszege nem stimmel), ezek tök FÜGGETLEN rétegek.)

Én meg azt mondtam, hogy hw raid esetén más fájlrendszerrel is működött volna a dolog, nemcsak ZFS-el.

én azt arra írtam, hogy előtte azt mondtad, hogy zfs-vel ha peched van, akkor esélyed sincs adatokat visszaszedni. mint bármelyik más filerendszerrel :D

 

Na látod, ez az, ahol totális tévedésben élsz. A konzisztencia és az adatintegritás 60 évvel ezelőtt is éppúgy fontos volt, sőt, még jobban, mert az akkori hw-k sokkal megbízhatatlanabbak voltak, mint a maiak.

nem tudom, te hol nőttél fel, de az én gyerekkoromban ha egy DOS meghalt, az teljesen természetes volt. Ma pedig szisszenünk egy kék képernyő mellett... és sokszor pont a szoftver miatt volt fos...

 

És Te komolyan azt hiszed, hogy a divx egy algoritmus??? Atyaég. Az egy kodek, ami számos különböző algoritmus egy konkrét implementációja.

és egy codec igenis megdefiniál bizonyos algoritmusokat. "The H. 264 standard provides advanced algorithms for motion estimation, inter-prediction, spatial intraprediction and transforms. " mi bajod ezzel? ezek elmennek a búsba, mert meg fognak jelenni más algoritmusok, possibly.

 

ZFS esetén sem oldja meg, megsúgom. 

egy zfs vagy btrfs  mirrornál simán dd-vel felülírom az egyik diszket és egy bitem sem veszik el, linux raidnál pedig igen. s ez pont annak köszönhető, hogy a filerendszer tud az egyes diszkekről és checksumol, amit leellenőriz és ha hiba esetén a másik diszkről olvassa az adatot. és igen, megint mondom: ezen a ponton cseszheted a rétegeidet. S erre a zfs mérnökei rájöttek (ettől tudja a zfs "konzisztensen" tartani magát, miközben megtartja az adataid "integritását"). Te nem.

 

És mégegyszer, ezeket értelmes rendszerek fájlrendszerfüggetlenül, kis erőforráspocsékolás mellett is képesek megoldani.

én is kifejtettem már: sok feature, sok erőforrás. az ext4 lehet gyors, ha alig nyújt valamit.

 

Egyébként meg a RAID jelentése "Redundant Array of Inexpensive Disks", és mint a neve is suggalja, az adatokat redundánsan tárolja, tehát megvan benne a helyes adat (is).

s én pont azt várom el: ha megvan a helyes adat is, akkor azt adja, ne a hibásat. amit, mint mondtam, a "klasszikus" raid nem tud, mert nincs ahogy (se a hw, se a sw).

 

a konzisztencia és az integritás, mindkettő elmegy a francba, ha a hw neked rossz adatot ad.

 

s nekem ne faszomozz mert én sem teszem

én azt arra írtam, hogy előtte azt mondtad, hogy zfs-vel ha peched van, akkor esélyed sincs adatokat visszaszedni. mint bármelyik más filerendszerrel :D

Hatalmas tévedés. PONT. Nemegyszer állítottam már vissza fájlrendszereket raid-ből, nemcsak hogy lehetséges, de pont erre van kitalálva...

de az én gyerekkoromban ha egy DOS meghalt, az teljesen természetes volt.

Amikről írtam, azok évtizedekkel előzik meg a DOS-t. Egyébként meg nem volt természetes, a DOS sosem halt meg nálam, akkoriban ugyanis nem volt még divat félkészen kiadni a programokat. Tényleg sosem halt le nálam a DOS, pedig széthackeltem ezerrel.

mi bajod ezzel?

Az, hogy nem tudod, mi a különbség algoritmus és implementáció között. A kettő nagyon nem ugyanaz.

és egy bitem sem veszik el, linux raidnál pedig igen

Már megint ugyanaz a tévedés. Raid-nél se, pont ez a lényege. Az ugye megvan, hogy a ZFS is pontosan UGYANAZZAL az algoritmussal biztosítja a redundanciát, mint a linux raid meg a hw raid kártyák? Tudnád, ha elolvastad volna a specifikációt, amit linkeltem.

pont annak köszönhető, hogy a filerendszer tud az egyes diszkekről és checksumol

Ja, ezt a kernel csuklóból megoldja, ráadásul bármilyen fájlrendszer esetén, szóval ez nem érv a ZFS mellett. Még be is linkeltem neked a releváns kernel modul dokumentációját, tessék olvasni!

ettől tudja a zfs "konzisztensen" tartani magát, miközben megtartja az adataid "integritását"

Látom, még mindig nem érted, mi a különbség a redundancia, konzisztencia és az integritás között. Tessék utánnaolvasni!

én is kifejtettem már: sok feature, sok erőforrás. az ext4 lehet gyors, ha alig nyújt valamit.

Tényleg nem érted, hogy nem is kell többet nyújtania, mert a többit az alacsonyabb rétegek már biztosítják? Most komolyan, azt hiszed, hogy a ZFS esetében ez nem így van? A fájlrendszer réteg ott sem nyújt semennyi redundanciát vagy integritásellenőrzést se! Az az alacsonyabb vdev réteg dolga. Komolyan, kattints már a linkre, és olvasd el a specifikációt, mielőtt ennyi hülyeséget hordasz itt össze.

s én pont azt várom el: ha megvan a helyes adat is, akkor azt adja, ne a hibásat. amit, mint mondtam, a "klasszikus" raid nem tud, mert nincs ahogy (se a hw, se a sw).

Már megint hülyeségeket beszélsz. Persze, mert nem is dolga, a helyes adatért egy másik réteg felel. Ennyi erővel mondhatnám, hogy a ZFS meg nem zenél.

a konzisztencia és az integritás, mindkettő elmegy a francba, ha a hw neked rossz adatot ad.

Tényleg nem értesz semmit. Nem kapsz rossz adatot, mert az alacsonyabb kernel réteg megoldja neked. Mindig jó adatot kap a fájlrendszer réteg, tök mindegy, hogy milyen fájlrendszerről van szó. Komolyan, ott a link, olvass!

s nekem ne faszomozz mert én sem teszem

Már meg ne sértődj, de folyamatosan azt teszed. Hülyeségeket hordasz itt össze, képtelen vagy felfogni, melyik rétegnek mi a szerepe, de ami a legrosszabb, hogy még arra sem veszed a fáradságot, hogy rákattints a linkekre, és elolvasd, hogy hogyan is működik valójában.

Tessék elolvasni a ZFS specifikációt (különös tekintettel a rétegekre és feladataikra), meg a kernel modul dokumentációt is, amit linkeltem, aztán majd folytatjuk az eszmecserét!

én biztos nem sértődök meg és lehet, hogy hülyeségeket beszélek, de legalább, amit én gondolok, az megfelel a valóságnak... :D

 

Tényleg nem érted, hogy nem is kell többet nyújtania, mert a többit az alacsonyabb rétegek már biztosítják? Most komolyan, azt hiszed, hogy a ZFS esetében ez nem így van? A fájlrendszer réteg ott sem nyújt semennyi redundanciát vagy integritásellenőrzést se! Az az alacsonyabb vdev réteg dolga. Komolyan, kattints már a linkre, és olvasd el a specifikációt, mielőtt ennyi hülyeséget hordasz itt össze

 

az alacsonyabb réteg semmit nem tud arról, hogy a felső réteg adatai pontosan hol vannak a diszken.

itt a példa, nem rocket science:

 

1. csinálsz egy ügyes raid-et, loop deviceokkal:

  fallocate -l 4M alma1.img

  fallocate -l 4M alma2.img  

  losetup /dev/loop0 alma1.img

  losetup /dev/loop1 alma2.img

  mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/loop0 /dev/loop1

  mke2fs /dev/md0

  mount /dev/md0 /mnt/alma

  echo "faszkivan" > /mnt/alma/alma.txt

  umount /dev/md0

  utána megkeresed ügyesen a "faszkivan" stringet az egyik file-ban és kijavítod, majd mount... nagy eséllyel elkapod, hogy az alma.txt-ben rossz adat van  

  kipróbáltam, így működik. és egy scrub sem fogja neked kijavítani a rossz adatot

 

  és a HW raid-ek sem szokták másképp csinálni. ha bitrot van, akkor elcseszted...

 

2. ha pl. btrfs-t csinálsz: mkfs.btrfs -draid1 -mraid1 /dev/loop0 /dev/loop1

  akkor, ügyesen észre fogja venni, hogy rossz a checksum, realtime, és neked automatikusan a másik diszkről fogja venni a jó adatot, miközben ezt silently megjavítja

  akkor is, ha scrubbolod... és itt a scrub megjavítja a rossz adatot

  éz zfs-vel is pontosan így működik

 

ha te olyan borzasztóan érted, ahogy én nem, akkor biztos meg tudod magyarázni...

na, szóval...

Egyébként meg nem volt természetes, a DOS sosem halt meg nálam

ezen felröhögtem

 

mivel, ez egy szakmai fórum, ne az annyapicsázással töltsük az időt...

ha te a linux raid alá beraksz egy dm-integrity-t, akkor az 1. egy nagy gányolás, 2. teljesítményben sehol sincs, 3. hw raidnál cseszheted (tudtommal azok ilyesmit nem nagyon tudnak, de fixme)

 

itt vannak a tesztjeim, egy kingston sata ssd, sata-to-usb átalakítóval:

test1:

 

integritysetup format /dev/sda1 alma1
integritysetup format /dev/sda2 alma2

integritysetup open /dev/sda1 alma1
integritysetup open /dev/sda2 alma2

mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/mapper/alma1 /dev/mapper/alma2
mke2fs /dev/md0

 

(amellett, hogy ISZONYÚAN LASSÚ a 2x32GB-os partícióval a dolog létrehozása, elég gyenge iops-t hoz ki... tartott vagy negyedórát... mit csinálna egy 2x15TB-nál?):

 

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.35
Starting 1 process
test: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=4524KiB/s,w=1864KiB/s][r=1131,w=466 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=2292153: Tue Sep 19 14:25:09 2023
  read: IOPS=2557, BW=9.99MiB/s (10.5MB/s)(3070MiB/307271msec)
   bw (  KiB/s): min=   32, max=19736, per=100.00%, avg=13236.81, stdev=5025.12, samples=475
   iops        : min=    8, max= 4934, avg=3309.16, stdev=1256.28, samples=475
  write: IOPS=854, BW=3419KiB/s (3501kB/s)(1026MiB/307271msec); 0 zone resets
   bw (  KiB/s): min=   56, max= 7320, per=100.00%, avg=4519.31, stdev=1605.13, samples=465
   iops        : min=   14, max= 1830, avg=1129.78, stdev=401.28, samples=465
  cpu          : usr=0.52%, sys=4.21%, ctx=1502979, majf=0, minf=9
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=9.99MiB/s (10.5MB/s), 9.99MiB/s-9.99MiB/s (10.5MB/s-10.5MB/s), io=3070MiB (3219MB), run=307271-307271msec
  WRITE: bw=3419KiB/s (3501kB/s), 3419KiB/s-3419KiB/s (3501kB/s-3501kB/s), io=1026MiB (1076MB), run=307271-307271msec

Disk stats (read/write):
    md0: ios=785822/262681, merge=0/0, ticks=12778083/6884099, in_queue=19662181, util=99.31%, aggrios=392960/262712, aggrmerge=0/0, aggrticks=6389717/3441752, aggrin_queue=9831468, aggrutil=87.20%
    dm-1: ios=491701/262712, merge=0/0, ticks=8095542/4771566, in_queue=12867107, util=87.20%, aggrios=785892/561499, aggrmerge=22/294, aggrticks=363348/135200, aggrin_queue=498548, aggrutil=100.00%
  sda: ios=785892/561499, merge=22/294, ticks=363348/135200, in_queue=498548, util=100.00%
  dm-0: ios=294219/262712, merge=0/0, ticks=4683892/2111939, in_queue=6795830, util=72.65%

 

 

2. sima zfs mirror

zpool create alma mirror /dev/sda1 /dev/sda2 -f
zfs set recordsize=4096 alma

 

[micsalaptop alma]# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.35
Starting 1 process
test: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [m(1)][94.7%][r=300MiB/s,w=99.1MiB/s][r=76.7k,w=25.4k IOPS][eta 00m:02s]
test: (groupid=0, jobs=1): err= 0: pid=2518115: Tue Sep 19 15:00:37 2023
  read: IOPS=22.1k, BW=86.5MiB/s (90.7MB/s)(3070MiB/35489msec)
   bw (  KiB/s): min=144864, max=359384, per=100.00%, avg=313195.79, stdev=58874.61, samples=19
   iops        : min=36216, max=89846, avg=78298.95, stdev=14718.65, samples=19
  write: IOPS=7401, BW=28.9MiB/s (30.3MB/s)(1026MiB/35489msec); 0 zone resets
   bw (  KiB/s): min=48472, max=119736, per=100.00%, avg=104768.00, stdev=19495.49, samples=19
   iops        : min=12118, max=29934, avg=26192.00, stdev=4873.87, samples=19
  cpu          : usr=1.45%, sys=24.81%, ctx=420, majf=0, minf=7
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=86.5MiB/s (90.7MB/s), 86.5MiB/s-86.5MiB/s (90.7MB/s-90.7MB/s), io=3070MiB (3219MB), run=35489-35489msec
  WRITE: bw=28.9MiB/s (30.3MB/s), 28.9MiB/s-28.9MiB/s (30.3MB/s-30.3MB/s), io=1026MiB (1076MB), run=35489-35489msec

 

szóval, egyáltalán nem győztél meg a layereiddel... (ja, és a zfs-t instant létrehozta)

Azóta használok érdemben ZFS-t, hogy a FreeBSD-be (kísérleti jelleggel, még patch szintjén) bekerült. Solarison kicsivel előtte, de azt nem hívnám érdeminek.

Néha egészen durva hibákból is sikerült *valami* adatot visszanyerni, ráadásul olyan módon, hogy egyértelműen tudtam, hogy mi a jó, és mi nem belőle. A snapshotok és a send/receive zseniális, ma már eszembe sem jutna két gép között rsync/tar/stb-t használni, sokkal egyszerűbb (és hatékonyabb) egy send/receive.

A laptopomon is ezt használom ki tudja mióta, a backup annyi, hogy néha rászinkronizálom wifin keresztül a másik gépben (akárhol a világban) lévő tárhelyre a sajátomat, és le van tudva, bármikor fel tudom onnan húzni, sőt, akár dolgozni is tudok róla, bárhol is legyek, úgy, hogy diszk nincs is a gépemben.

Tény, vannak azért még bőven betegségei, de nekem fájna nélküle az élet. :)

sőt, akár dolgozni is tudok róla, bárhol is legyek, úgy, hogy diszk nincs is a gépemben.

Ezt azért elég sok másik megoldás is tudja :-)

Tény, vannak azért még bőven betegségei, de nekem fájna nélküle az élet. :)

Magyarán neked bejött az, hogy nem egy fontos szervert üzemeltetsz, hanem egy laptopot, és lusta vagy utánnajárni a hatékony megoldásoknak, mert neked bőven elég az, hogy van egy működő megoldás. Ne érts félre, nincs is ezzel semmi baj.

Szerencsére már csak nagyon apró dolgokhoz nyúlok hozzá, és nagyon ritkán (50-es nagyságrendű szerver, pár PB környéki adat), szóval ja, bejött. :)

Te magad írtad, hogy laptopról beszélsz, és a válaszom is arra vonatkozott. Te talán 50 laptop vasról üzemeltetsz hálózati szolgáltatásokat? Ha igen, akkor azt nagyon megnézném!

( trey | 2023. 09. 18., h – 11:06 )

Még mindig nem tároltam egy bitet se ZFS-en ...

trey @ gépház

Ha úgy vesszük, én se, bár akkor nem árt definiálni, hogy mit értünk tároláson. Mert virtuális gépes, meg másodgépes próbatelepítéseken volt a rendszer alatt már ZFS-em, de csak kipróbálás szintjén, fontos adatot nem tároltam rajta. A fő rendszerem, és saját adatok alatt nem volt soha, mármint offline tárolásnál, online/felhőt nem tudom.

Nekem egyébként nincs bajom a ZFS-sel, meg azzal, aki használja. Nekem nincs rá szükségem, de támogatom, ha valaki halad a korral, modern megoldást (rendszert, fájlrendszert, formátumot, codec-et, prognyelvet, stb.) használ, nem ragad le a régi, limites dolgoknál. Ha már van, és van, akinek hasznos, a rendszer meg támogatja, miért ne. Mert azt valóban nem lehet csinálni, mint hajbi, mert XP-n ragadtunk volna.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)