A ZFS ökölszabályai

ZFS Fan Club

Sziasztok!

Egy ilyen nekem az elején rengeteget segített volna. A célja elsősorban a ZFS-el ismerkedők eligazítása, illetve a kezdeti lépések segítése. Én írtam a saját tapasztalatimból, illetve a fórumon tárgyaltakból. Ha van még ötlet jöhet, illetve a meglevő pontokra is mehet kritika. Ha hozzáírtok vegyétek figyelembe, hogy olyanoknak íródik akik nem ismerik a ZFS-t. Ez majd kimegy a mediawiki-re.

1. A ZFS nem az n+1-ik fájlrendszer, sokkal több annál, ezért ne is úgy gondolj rá!
A ZFS egy ultramodern rendszer, ami nagyon más mint amit eddig megszoktál. Sajnos egy pár dogot újra kell tanulni miatta, de cserébe itt egy lista, hogy egymaga miket cserél le, ha elkezded használni: hw raid szoftverek, md, lvm, fájlrendszerek (ext3, ext4, xfs, stb.), mkfs, fsck, fstab, dd...

2. Soha de soha ne használj hardver RAID-et ZFS-hez, se bármilyen más szoftver RAID rendszer
Tilos a ZFS alá bármilyen RAID rendszert tenni! A ZFS egy teljes önálló rendszer a disk-re írástól a RAID-en át a fájlrendszerig, nincs szükség alá semmilyen egyéb rendszerre, hardver raid-re meg pláne.

3. A ZFS gyors működéséhez három dolog kell, RAM, RAM és még több RAM
A leggyakoribb probléma a ZFS-el az elégtelen memória méret. Vagy nézz utána mire és mennyi memória kell a ZFS-nek, vagy használd ezt, 4GB éppen elég, 8GB szódával elmegy, 16GB-tól alakul. Ez persze a többi (rendszer, alkalmazások, stb.) memóriafogyasztás felett számítandó!

4. A deduplikáció memóriaigénye, tuti nem hitted volna, de nagy. 4-5GB RAM / 1 TB disk (blocks * 320 bytes) A disk olcsó(bb) ha nem muszáj ne küzdj vele.
A deduplikáció memóriaigénye a többi (pl. ARC) memórián felül számolandó, ezen kívül CPU is kell neki. Nem biztos, hogy megéri az extra teljesítmény és memória ráfordítást, ha megoldható helyette több disk-el, számolj utána.

5. Használj SSD (S)LOG disk-et
Az SLOG lemez használata ez egyik módszer amivel gyorsítani lehet a ZFS írási sebességét. Vagy mégsem, mert csak a sync írást gyorsítja. Járj utána mikor, mire jó és mire nem. Ha nem tudod mi a különbség a ZIL, SLOG, sync és async írás között, ne csodálkozz, ha nem az lesz az eredmény mint amire számítottál.

6. Ha tudsz, inkább használj az CACHE (L2ARC) disk helyett RAM-ot.
A CACHE disk használata nem csodaszer és lehet, hogy semmit nem fog gyorsulni a rendszered tőle, viszont van amikor igen. Értsd meg, számolj, tesztelj.

7. Sok kicsi sokra megy 3 x 10 != 12 x 1
Amivel jelentősen növelhető a teljesítmény az a sok lemez. Ha akarsz például 10TB területet 2 paritás lemezzel akkor sokkal-sokkal jobb a 3x10TB helyett a 7x2TB lemez és még annál is jobb a 12x1TB.

8. Egy POOL kihasználtsága legyen 70% (80%-90%) alatt.
Ez nem csak a ZFS-re igaz, hanem minden fájlrendszerre. Több mindentől függ mikor kezd lassulni, de 70%-kal nem lősz mellé.

( iwanabeguru | 2019. 10. 10., cs – 15:36 )

Onnan hogy kell neki 16G ram hogy használható legyen,elég felejtős, ennyi van a munkahelyi laptopomban.
Azzal odamenni a főnökhöz hogy kéne memória gépembe mert nem megy a filerendszer, enyhén szólva is necces.

===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

Backup szerveremben 8GB RAM van és 14TB-s pool van létrehozva. Benne 2-6TB szabad tárhely, változó. Bizonyos dataset-ek tömörítve vannak, amiket sűrűn írok (heti 4TB) az tömörítés nélkül, amit ritkán írok és pár száz GB (archiv) ott dedup és compress is van.
Elvagyunk, teszi a dolgát.

És alkalmazásoknak, egy desktop user böngészőjének ennek.annakmennyi ram marad...? Ha adott célra (storage szerver) használod, elég, de ha mást is akarsz vele kezdeni, akkor nagyon kevés.
Ja, és persze onnantól kezdve, hogy erőteljesen épít a RAM-ra, illendően ECC-ram és a gépet időben lekapcsoló szünetmentes táp sem maradhat ki a "mi kell hozzá, hogy..." felsorolásból.

( egmont | 2019. 10. 10., cs – 15:48 )

> egymaga miket cserél le, ha elkezded használni: hw raid szoftverek, md, lvm, fájlrendszerek (ext3, ext4, xfs, stb.), mkfs, fsck, fstab, dd...

<troll>
Ez a fájlrendszerek systemd-je? :)
</troll>

( Szenti v | 2019. 10. 10., cs – 16:09 )

Ami elsőre szemet szúr:
* "disk-et" helyesen disket, vagy diszket. Ugyanitt: "raid-et" helyett RAID-et
* konzisztencia: a felsorolások végén vagy mindenhol használj írásjelet, vagy sehol sem! Én az utóbbit használom/javaslom
* konzisztencia: valahol disk szót használsz, máshol pedig lemezt
* Nem tilos hardver raidet tenni a ZFS alá, csak erősen ellenjavallott. Az indok pedig az, hogy a ZFS akkor tud a leghatékonyabb lenni, ha a vezérlő nem rejti el előle a lemez hardware hibáit

HW RAID kártyák esetén általában alapból nem lehet natív diszket OS felé adni, legjobb esetben is egy 1 lemezes stripe kötetet lehet (szoktak) csinálni, és azt látja az OS. Namost, hogy ha a RAID vezérlő úgy gondolja (mondjuk SMART adatból), hogy az adott diszk már nem az igazi, akkor simán kidobja anélkül, hogy a ZFS-nek lenne beleszólása. Ezen felül általában sem gyári számot, sem modellt, sem logikai/fizikai szektor méretet, sem hőmérsékletet, sem SMART adatot nem lehet HW RAID vezérlőkön keresztül megtudni az egyes lemezekről (vagy csak egyedi módon, körülményesen).
Ez szokott a legfőbb indok lenni.
A ZFS-ben a scrub pont azért van, hogy a diszk hibákat felfedezze. Ezen felül minden ZFS alapú rendszer vagy tartalmaz, vagy javasol rendszeres SMART diagnoszikát is.

Különben ez az egyik legtöbbet vitatott kérdés a ZFS-sel kapcsolatban, és szerintem azért, mert sokan RAID vezérlővel szerelt szerverre szeretnék tenni, de további pénzt nem akarnak költeni, mert ugye ott a drága RAID vezérlő, már miért ne lenne az jó. A "gyári" ZFS doksik részletesen kifejtik, miért kell natív, HW szintű hozzáférés a lemezekhez a ZFS-nek. Részemről nem értettem soha, miért vonja ezt annyi ember kétségbe.

Egyébként meg mindenki azt tesz ZFA alá amit szeretne. Ha meg megáll és pool vesztés lesz belőle, az a saját problémája lesz.

HW RAID kártyák esetén általában alapból nem lehet natív diszket OS felé adni, legjobb esetben is egy 1 lemezes stripe kötetet lehet (szoktak) csinálni, és azt látja az OS. Namost, hogy ha a RAID vezérlő úgy gondolja (mondjuk SMART adatból), hogy az adott diszk már nem az igazi, akkor simán kidobja anélkül, hogy a ZFS-nek lenne beleszólása.

Ebben az egyszerű körmondatban mindent leírtál, csak rosszul ejted a szavakat. ;)

Az OS (legyen itt linux meg Windows) nem kezeli teljes körűen a diszkeket. Ezért vállalkozik egy vfs driver (ami ebből a szempontból nem OS, hanem csak egy szoftver), a hardver közvetlen kezelésére. Mégpedig az OS alá nyúlva.

A HW RAID kártyák alapból tudnák adni a natív diszkeket adni az OS felé, csak megint életbe lép az egyes szabály: az OS nem tud mit kezdeni vele. Így aztán vagy fekete doboz, vagy egy OS "mellé helyezett" szoftver a megoldás.

... javasol rendszeres SMART diagnoszikát is.
És akkor mi van?
- A SMART eleve a kommersz diszkekre lett kitalálva
- a lényeges információkat elrejti - így az egyszerűbb a felhasználónak
- valószínűségi adatokkal próbál dolgozni
Ez azt jelenti, hogy 0 hibás diszk is kifinghat a következő pillanatban, de viszonylag sok hibával is mehet évekig.

De még így is létezhet megfelelő megoldás, csak még nem igazán láttam. Helyette:
ha a RAID vezérlő úgy gondolja (mondjuk SMART adatból), hogy az adott diszk már nem az igazi, akkor simán kidobja
Leírom az algoritmust: Már háromszor lottóztál, de még egyetlen találatod sem volt. Az ilyennek minek élni? Tehát megöllek!
Ez logikus. ;)
Hiszen így működik a linux és Windows SW RAID is, tehát biztosan jól csinálják.
A miértjét feljebb leírtam.

valószínűségi adatokkal próbál dolgozni

Egy kikapcsolt hibás szektorban mi a "valószínűségi adat"?

Ez azt jelenti, hogy 0 hibás diszk is kifinghat a következő pillanatban, de viszonylag sok hibával is mehet évekig.

Ennek se füle se farka. Mint ha azt mondanád, hogy nem cserélek olajat a kocsiban, mert úgy is elromolhat. Lehet úgy üzemeltetni, hogy leszarod ezeket és majd csinálsz valamit ha elromlik, meg lehet proaktívan. Aki egy szaporodó bad secotor-os lemezt nem cserél az elég "bátor".

A valószínűségi adat alatt nem az "egy kikapcsolt szektort" értettem. (úgy hívják: marked bad)
Mindössze egy csomó mérési eredményt (google) és néhány tanulmányt foglaltam össze egy fél mondatban. Ha érdekel, bátran nézz utána!

A szaporodó badsector semmit nem jelent. Ha belegondolsz, nagyságrendekkel több tartalák áll rendelkezésre már egy picike diszken is, mint ahány badsectort láttál és hallottál egész életedben. Ajánlom tanulmányozásra a bejáratás-kopás-elhasználódás görbéket és statisztikákat. (Akár az olajcserével kapcsolatban.) Mert ugye, a diszkben sem a tranzisztor kopik el. ;)

A normális diagnosztikai módszer a meghibásodások trendjének a vizsgálata az ezköz futamidejének függvényében. Legalábbis az IBM szerint. ;)

Bár itt is van egy aprócska eltérés. Az IBM nem (S)ATA diszkekről mesélt. A kommersz diszkek esetén néha csak célszoftverrel lehet kínkeservesen kijavítani a hibát. Ehhez meg szinte senki sem ért, ezért a tudósok megmondják: Egy hiba és dobom is ki a 4TB diszket.

Éppen ezért az olajos hasonlat nem állja meg a helyét, mert ott az üzemi/statisztikai adatok alapján pontosan előírjak a tennivalókat. Diszkek esetén meg boldog-boldogtalan fórumozik. Hiszen nem tudsz mutatni egyetlen releváns ajánlott eljárást sem a badsector kezelésére.

Hacsak nem a Hard Disk Sentinel parasztvakítását. Mert ott tudjuk, hogy egyetlen hibás szektor a tetszőleges méretű diszken az pont 99%. :-D

HW RAID kártyák esetén általában alapból nem lehet natív diszket OS felé adni
Tévedés, driver függő. A saját alaplapomban is (igaz, dmraid kategória) olyan raid van, amihez befejezetlen a driver. A Windowshoz a dll a biosból jön. (Tudtad?) Ugyanez a linux alatt a fizikai és raid diszkeket is látja.

...miért kell natív, HW szintű hozzáférés a lemezekhez a ZFS-nek. Részemről nem értettem soha, miért vonja ezt annyi ember kétségbe.
Ezt meg kiegészitéttem. A konkluzió annyi volt, hogy jó dolog az a ZFS és hiánypótló is, de ezeken a diszkeken szart se ér. Ebben azért vagyok teljesen biztos, mert láttam olyat már, amikor az OS nem szorult segédszoftverre a ZFS ilyen irányú képességeit messze meghaladó működéshez. Természetesen a raid is beépített funkció volt, miközben a diszkek kezelése változatlan maradt.

Ha kívánod, leírom harmadik módon, mondjuk átlósan. ;)

Azt gondolom felesleges lenne, mert úgy sem érteném pontosan azt hiszem. :-)
Annyi lejött, hogy utalsz valamire, ami az én ismereteimből teljesen hiányzik, így pontosan azt sem tudom, mire. Csak a szövegkörnyezetből érzem. Ezen felül más hozzászólásból hozzálegóztam, hogy HP-UX, meg más, "nagyon vállalati" rendszerekre gondolhatsz az utalásokban (ill. azok tudására), de ezeket én egyáltalán nem ismerem. Plusz, szerintem a kezdőknek szóló ZFS javaslatok szempontjából nem is fontosak/relevánsak. Itt nem azt vitatnák meg, hogy a ZFS úgy általában jó-e, vagy lopott ötlet-e, hanem csupán annyit, hogy ha valaki használná, először, akkor mi mindent tehet azért, hogy ne szívassa magát nagyon meg kapásból.

Az biztos, hogy a legtöbb modern HW RAID kártya virtuális diszket ad az OS felé alapból, elfedve a fizikai lemezt teljesen (az most nem is releváns szerintem, hogy az OS alatt egy külön SW réteg kezeli ezt is - más kérdés, hogy én OS alatt ezen SW rétegek összességét értem). Egyes típusokat egyszerűen át lehet kapcsolni HBA módba, amikor is a diszkekhez közvetlen hozzáférése lesz az OS-nek, más modelleket újra lehet szoftverezni HBA üzemmódhoz, megint másokat nem lehet sehogy a HBA működésre bírni.

Mi itt java részt egyszerű népek vagyunk, a Dell PERC sorozata és a HP P sorozata a legtöbbünknek a csúcs HW diszkvezérlő, amivel dolgoznunk kellett, jellemzően x86 platformon, jellemzően Windows vagy Linux (esetleg BSD) környezetben. Ezen a szinten a Linux-ból ismert LVM lehet összehasonlítási alap.

Azt persze jó látni, hogy ezek a technológiák (vagy az elvük, vagy az alapjaik) a jó öreg (csillió dolláros) vállalati világból szivárogtak le a köznéphez, ami biztató az átgondoltságukra és kidolgozottságukra nézve.

Igazad van, de nem HP-UX, hanem AIX alatt dolgoztam közel 20 évet. Amit a diszkekről tudni lehetett, azt tudtam és éltem is a lehetőségekkel. Az árak tényleg nagynak tűntek, de ilyenek a számítógépek. Az első 8MHz-es IBM PC-AT, amit kirakatban láthattunk 1MFt volt. Ugyanakkor a fizetésem 10500. ;) A '95-96-tól kezem alá kerülő dupla gép bolti ára 80MFt volt. Gépenkét 7 diszk 2 SCSI (a harmadik az alaplapon a szalagnak és cédének) és egy két portos SSA csatoló volt.
Az utóbbi egy majdnem tele diszk-tornyon ment át: gép 1 - 7 diszk - gép 2 - gép 1, azaz loop ;), és két ilyen loop volt. A gépeken HACMP (IBM cluster) futott. Szóval volt min játsznom! :-D
(Rosszmájú megjegyzés: Állítólag a HP a későbbiekben diszkkezelő alrendszert vásárolt. Az IBM meg semmi ilyet nem tett. ;))
Volt 96-ban egy PowerPC 604-es gépem, 2004-ben meg 1,9MFt-ért vettem egy POWER4+ alapú gépet 4 diszkkel. Az már csak egy izmosabb Intel alapú szerver ára volt.

No, ez volt az esszé beveszető szakasza, ti. láttam már diszkeket. :) Persze sokkal több gépet is.
Az AIX szerverekben akkoriban kizárólag SCSI diszkek voltak, ami eleve egy nem kommersz kategória. De ez sem elég, mert IBM firware volt bennük. Az ilyen ott volt a rendszer adatbázisában, együttműködött az oprendszerrel, vagy 50 féle paraméterrel tudtam kialakítani a diszk rendszert. Kezelt idegen diszkeket is, mint "osdisk" = other scsi disk, és ott elég kevés lehetőség volt a játékra.
No, éppen egy ilyen idegen diszk náthás lett - olvastuk a logban:
- 5 szektoron írás hiba volt
- parancsot adtam a hw relokációra
- sikertelen volt
- sw relokáltam a hibás szektorokat
Ugyanitt, amikor a gép 380-at kapott, kiírta: 001
Kerestük és megtaláltuk a szervizkönyvben: Hibás a hálózati feszültség. :-)

A lényeg néhány pontba szedve.

Az AIX mint operációs rendszer teljes körűen kezeli a láncot:
fizikai driver - logikai driver - lvm - raid - fs - OS (illeszthetsz +vsf drivert is)
A linux esetében már hiányos a fizikai driver. A fenti hibaüzenet sort még nem láttam. Az lvm kevesebb és hiányosabb, bár látszólag többet tud, hiszen tetszőleges bejárást biztosít az egyes elemek között. De ez csak szoftver, hiába van beépítve a kernelbe. A teljes hardver drivert csak a kernel átlépésével tudod megvalósítani - mint a ZFS.

A diszk közvetlen kezelése - bárki is tegye - egy S(ATA) diszknél látszólag megoldható, de nem ugyanazokat az eszközözöket vezették ki a felhasználóhoz. A hibás blokk detektálása és javítása nem minden esetben sikeres, és ilyenkor csak külső szoftverrel lehet próbálkozni.

A fentiek alapján megértem azokat is, akik egyetlen hibás szektor után cserélik a diszket. Nem értenek hozzá, a javítás hosszadalmas és korlátok miatt gyakran eredménytelen lehet.

Tehát semmi pró vagy kontra az ZFS-hez. Mindössze arra hívom fel a figyelmet, hogy bizonyos diszkeknél csalóka lehet a biztonság, hiába igyekszik a ZFS megoldani. Ezeket a diszkeket nem ilyenre találták ki.

bizonyos diszkeknél csalóka lehet a biztonság, hiába igyekszik a ZFS megoldani. Ezeket a diszkeket nem ilyenre találták ki.

A ZFS minden blokk mellé tesz egy cheksumot a lemezre, minden egyes RAID lemezre pontosan , egyik ok a közvetlen portra, (HW RAID-nél ez a funkció is hatástalan,mert egy lemeznek látja a tömböt), olvasáskor ellenőrzi, ha sérült az adat a checksum szerint,, nem is kell BAD BLOCK, vagy hasonló, meg tudja állapítani a hibát, azt hogy hol van a hibás adat és megkeresi a többin a jó adatot. Többek között ezért sincs értelme a HW RAID-nek és ezért kell látnia a lemezt közvetlenül.

Tehát akkor az ECC-re rakott checksum segítségével kiküszöböli azt a hibát, amikor egy rendszer alól úgy hullik ki az összes diszk, mint a villámcsapás. Most már értem! ;)
Láttam olyan HW RAID kártyát, amin két processzor is volt. Szerinted mit csináltak?

Persze bármi is tök felesleges, ha nincs hiba. Ha meg van, akkor a BAD BLOCK vagy hasnonló (wtf?) sem kell, hiszen ezt beépítetten kezelik a diszkek. Ha nagy a baj, akkor rosszabb esetben vissza se kapod a vezérlést. Aztán mehet a ZFS a sóhivatalba, mert nem tudja megállapítani a checksum értékét. ;) Tudod hogyan működik egy diszk?

tudod hogyan működik egy diszk?

Nem vagyok elektroménök, nem tudom , hogyan programozzák a HDD léptetőmotorjait és hány miliamper kell az írófejnek. DE itt nem ez a téma. Pedig a léptetőmotorok programozását egy délután meg lehet tanulni, a BME-n:

https://www.youtube.com/watch?v=nGUpVIg3e8E

Ezt például nem írta senki, én sem :
tehát akkor az ECC-re rakott checksum segítségével kiküszöböli azt a hibát, amikor egy rendszer alól úgy hullik ki az összes diszk, mint a villámcsapás. Most már értem! ;)

Abban igazad van, ha az összes disk kihullik, gáz van. Jól látod, ilyenkor szerintem is adatvesztés léphet föl.

Láttam olyan HW RAID kártyát, amin két processzor is volt. Szerinted mit csináltak?
Funkcionálisan pontosan ugyanazt mint a szoftver RAID-nél az alaplapi processzorok csináltak és csinálnak.

Sejtettem.
HDD léptetőmotort már én is láttam a 36 track-es diszkekben (1MB), még a 80-as években. Azokat a drájvokat hívtuk mosógépnek a méretük miatt. ;) Akkoriban még a 10-20-40-80MB kapacitású diszkek is így működtek.
Azóta a diszkek lineáris motorral működnek. Az alkalmazott szervó algoritmusokat meg igen sok délután alatt sem fogod megtanulni.

Talán ezért sem tudtad, hogy az ECC (hibajavító kód) az a technológia, amivel az elektronika felír egy blokkot a lemezre. Az interfészről meg még azt is kiolvashatod, hogy hibátlan, hibátlan de javított vagy hibás a blokk. A RAID, ZFS vagy bármely hasonló technológia az alap hibakezelését az adatok redundanciájának növelésével javítja, de...

Arról karattyolok, hogy a kommersz operációs rendszerek hiányosságai miatt a diszkgyártók a hibás blokkok javítását javarészt elrejtették az operációs rendszer elől. Emiatt a fícsör miatt adódik néha a meglepi.

Javaslom ezt átolvasni, úgy talán világosabb lesz mire való a ZFS, a Cern-ben ezért álltak át a használatára.

https://indico.cern.ch/event/518392/contributions/2195790/attachments/1…

Tehát akkor az ECC-re rakott checksum segítségével kiküszöböli azt a hibát, amikor egy rendszer alól úgy hullik ki az összes diszk, mint a villámcsapás. Most már értem! ;)
Láttam olyan HW RAID kártyát, amin két processzor is volt. Szerinted mit csináltak?

Tehát akkor felesleges minden védelem, mert úgy is elromolhat annyi lemez, hogy vége mindennek, akárhány processzor van akárhol. Értem, átállok a papír ceruzára, bár annak meg kitörhet a hegye... :)

Köszi, tanulságos iromány.
Tehát a ZFS képes jobb eredménnyel és teljesítménnyel kiváltani, ha a szakemberek
- inkompatibilis RAID csatolót,
- hibás RAID csatolót,
- gagyi RAID csatolót,
- fimware hibás diszket,
- nem optimális konfigurációban használnak.
A kialakított rendszer hibaaránya 300.000.000x rosszabb lett.
Szép teljesítmény.
Az is kiderült, hogy a RAID csak egy besorolás és mit nem garantál.

Csaxólok, hogy a ZSF-ről eddig egy kukkot nem szóltam, ezért felesleges bizonygatni, hogy jó-e.

Tehát akkor felesleges minden védelem, mert úgy is elromolhat annyi lemez, hogy vége mindennek, akárhány processzor van akárhol.
Erre csak egy anyagbeszerző aranyköpését idézem, amikoris különböző gyártóktól szereztünk be X db terméket Y db tartalékkal.
"Az IBM-ből nem kell tartalék, mert az úgy sem romlik el."
:-D

Ok, akkor tehát "a dll a bios-ból jön"(TM), a Cern-esek hülyék, minden szar ami nem IBM, az ECC-re rakjuk a checksum-ot, mindenki mindent rosszul tud, ZFS az alap hibakezelését az adatok redundanciájának növelésével javítja, tiéd a szent igaz út. Kérlek beszélj még mester, áhítattal hallgatjuk kioktatásod és szavaid.
Részemről befejeztem...

No, ha ezzel kezded, akkor mindjárt vágom, hogy az IBM fénykorában fejlesztett, tökéletesnek szánt és végletekig csiszolt rendszerhez hasonlítod a mai kommersz rendszerek (itt: ZFS) képességeit, lehetőségeit. Összehasonlítható végül is, de nem korrekt teljesen. Ezen felül ha az IBM ma tervezne/készítene ilyesmit, akkor tuti nem fejlesztene ilyen egyedi rendszert, hanem a meglévőket használná, vagy formálná a saját igényeire (sőt, az sem kizárt, hogy a FOSS fejlesztéshez tenné hozzá amit kitalál, manapság nagy divat, mert így más cégek erőforrásaihoz is hozzájut áttételesen).

Sajnos ilyen integráltság és összecsiszoltság a mai világban már nem nagyon van. Legalább is a "kommersz" számítástechnikában (AIX-en és mainframe gépeken innen). Más kérdés, hogy bizonyos funkciók annyira nem fontosak, mert pl. sokkal olcsóbb a tárkapacitás, és ha valami elromlik csak kidobjuk és csere (a 3-500 ezres lemezek esetében ez azért nem így ment még...). Az egyedi FW a diszkeken ma is meg van még (pl. HP előszeretettel hisztizik érte, Dell csak mutatja, hogy az nem olyan), de ez leginkább azért van, hogy mindenki inkább a márkafeliratos, túlárazott terméket vegye (azzal a címszóval, hogy az tuti kompatibilis - na nem már). Ha a gyártók a szabványokat követnék (és nem egészítgetnék ki egyedi dolgokkal folyton, semmi gond nem lenne. Én arra tippelek, az általad említett többlet funkciók AIX és IBM FW esetén is inkább szoftveres korlátok voltak, mint valósak.

Viszont innen nézve azért elég szép, amit a ZFS ebből megvalósít egymagában. Ha pedig nagyon a biztonságra akar valaki menni kommersz szoftver és hardver felhasználásával (ZFS-sel), akkor az igazán fontos dataset-re beállít 2 vagy több példányt (a RAID megoldáson felül természetesen), és akkor egy diszk bármilyen szerktor szintű hibájánál nemhogy észreveszi a hibát a checksum alapján, de előveszi a blokk teljesen hibátlan példányát... Ezt ma már meg lehet tenni büntetlenül, mert mint említettem, olcsó a diszk. Innentől nem is fontos, hogy a ZFS vagy az OS vagy a diszk FW milyen szinten/módon tudja javítani a szektor hibákat.

Ide illik az a gondolat, amit egy jó barátom szokott mondani: ha rajta múlna, csak mainframe képek alkotnák a számítástechnikát, és azokhoz csak magasan képzett szakemberek nyúlhatnának. Akkor adott lenne a tökéletes hardver, szoftver és felhasználás. :-)

Az IBM fénykorában fejlesztett (30 éve, mainframe-ről áthozott diszkkezelési technológiát), amit a végletekig csiszolt, és ma is árul belépő szintű szerverektől a szuperszámítógépekig mindenhez, változatlanul. Ezt hasonlítom egy 15 éve fejlesztett, nem kommersz rendszerekre készült, de ma már kommersz rendszereken is használt (itt: ZFS) képességeivel.
Így egy kicsit másképp hangzik. Tudtad, hogy az AIX 1.0 (?) volt pécére is. Legalábbis beszéltem olyannal, aki már hallott róla. ;) Nem véletlen, hogy ez is csak valami játék lehetett. Egy jól kidolgozott OS (itt: diszkkezelés) csak harmonikus hardveren ütőképes.
Tehát nem a két féle diszkkezelést hasonlítottam össze. Csak annyit állítottam, hogy a fejlett diszkkezelés kommersz hardveren a biztonság téves illúziójába ringat. Hasonlóan a ferrari motoros trabanthoz.

Tehát a ZFS nyilvánvalóan jó, pótolja az OS hiányosságait, de sokkal többet nem várok tőle, mint az alárakott diszkek minősége.

Való igaz, hogy a megbízhatóságot több irányból lehet közelíteni. A redundáns tároláshoz akalmazhatsz néhány drága és magas megbízhatóságú elemet, vagy nagyobb számú és olcsó elemet. (google) Az utóbbi esetben a "házi" felhasználásnál - a kis darabszám miatt - inkább használnám a "megbízhatóság" helyett a "szerencse" kifejezést. :-D

Azt sem értem, hogy mit értesz az IBM (nem)fénykorán. Talán azt, hogy ledobta a kommersz üzletágakat, és így csak a fejlesztést, tanácsadást és csúcsrendszereket tartotta meg? Ha megnézed, jelenleg is árul kis szervert, amibe tehetsz 1TB memóriát és van benne POWER9 - 8 core - amiből 1 core kb. leveri a laptopodat + szerveredet + a szomszédpistike gamer gépét egymagában. ;)
A FOSS fejlesztéshez meg elég sok millió dollárt invesztált. A fenti gépen fut a linux is. Sajnos a Windows nem, pedig akkor sokkal népszerűbb lenne...

Az az igazság - és ezt ne bántásnak vedd -, hogy nekem úgy tűnik, inkább offenzív vitát folytatunk, mint megbeszélést a ZFS-ről és annak képességeiről, határairól.

Nekem semmiképp sem kell bebizonyítanod, hogy az IBM által sok évig fejlesztett, gyártott hardveren, a saját AIX rendszerük sokkal sokkal megbízhatóbb és összeszedettebb, mint tetszőleges gyártó(k)tól származó, kommersz x86 hardverre telepített FOSS projektben készült szoftver. Ez tény, nincs mit vitázni rajta.
De Power9-es AIX-es rendszert a nagy (vidéki) KKV-k (ezen a pár milliárdos forgalmú cégeket értem) sem vesznek manapság (bármennyire jók), nem még azoknál kisebb cégek, pláne magánszemélyek. Mivel a sokkal olcsóbb, kommersz x86-os gépekből is lehet olyan megbízhatóságú rendszert építeni manapság, ami az adott üzletmenethez megfelel.

Az IBM fénykora alatt én azt értem, amikor az IBM volt "A" számítástechnika. Azért bármennyire nagyszerű cég, ma ez már nincs így. Innováció messze nincs annyi, amennyi régen, és ami van is, azt is a csúcs árkategóriát elfogadó vevőknek fejlesztik. Tehát az informatika túlnyomó részéhez (még az open source munkájukat is hozzávéve) messze nem tesznek annyit, mint régen. De nyilván ezek tisztán pénzügyi érdekek mentén alakulnak, nem a képességek vagy szándékok döntik el.
A "koloc" üzletágak ledobálása meg nem műszaki vagy egyéb igény alapján történt, csak idióta, pillanatnyi tőzsdei befektetői érdekek miatt volt. Hogy-hogynem a Lenovo pl. teljesen sikeresen viszi tovább a PC, laptop és x86 szerver üzletágat, amit az IBM-nek dobnia kellett, mert állítólag csak ráfizetés volt. A mainframe-ek pedig szerintem a számítástechnikai abszolút csúcsai a mai napig (20-40 év folyamatos üzemidőt semmi sem tud a mai napig, jellemzően még nagy klaszterek sem), de ez megint csak a leggazdagabbak játékszere maradt. És ott is jönnek az új, okos, csippmagazinból szakmázó emberek és cseréltetik le (több-kevesebb sikerrel...) Linux alapú HA rendszerekre (ez mondjuk nagy hiba, de üzletileg könnyű megvédeni olyan vezető előtt, aki csak az összegeket nézi).

Szóval ez a mai IBM már akárhogy szépítem, nem "az" az IBM.
A ZFS meg nem az eredeti IBM hardveren futó AIX által nyújtott tároló-kezelésnek az "ellenfele".

A megbízhatóság meg leginkább tervezés kérdése, nem a konkrét hardveren múlik. 5 percenként elromló hardverből is lehet ötkilences SLA, csak kellően sok kell belőle. Így kommersz diszkkel is lehet magas megbízhatóságú tárolót építeni, csak megfelelő darabszám és szervezés kell. Ha pedig nem megbízható a kommersz diszkekből álló rendszer, akkor arról nem a diszk tehet, hanem a rendszer tervezője. Biztos vagyok benne, hogy AIX alatt is lehet olyan konfigot összehozni eredeti IBM (FW-es) lemezekkel, ami össze tud borulni aránylag könnyen (bizonyos feltételek teljesülésekor, nem csak úgy magától). Semelyik számítógép nem véd az azt működtető ember ellen...

> Biztos vagyok benne, hogy AIX alatt is lehet olyan konfigot összehozni eredeti IBM (FW-es) lemezekkel, ami össze tud borulni aránylag könnyen

Hehe, korai 4-es AIX-en sikerült olyan vacakul az LVM alrendszer SMIT-en keresztüli admin felülete, hogy egy nem túl szokványos beállítást használva, és előbb hozzáadva majd elvéve egy diszket, szépen kezelhetetlen állapotba kergette magát. (Mintha valami Murphy-törvény is lenne arról, hogy hány soros program kell ahhoz, hogy biztosan legyen benne hiba ;-) )

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Rosszat idéztél, ezt kellett volna: ;)
Semelyik számítógép nem véd az azt működtető ember ellen...
Az az igazság, hogy a SMIT csak néhány alapfeladatra jó. Pontosan a 4-es AIX-től kezdve senki sem használta, mert a kívánt konfiguráció kialakítására alkalmatlan volt. A gui verzója meg még annál is rosszab.
De puskának igen jó, mert a művelet befejezése helyett F6, és kimásolhattad a parancsot vagy a szkriptet, ha nem tudtad fejből.
Persze sokkal célszerűbb a diszkek pakolgatása előtt megtervezni mit is szeretnél csinálni.

Ami ennél sokkal szörnyűbb, hogy linux lvm-ben nincs map opció és strategy paraméter. Vagy tévedek, de akkor megköszönném az infót.

AIX alatt minden fizikai diszk max. 1016 partícióra osztható. Ez nem azonos a DOS és egyéb partíciós tábla bejegyzésekkel, hanem ekkora granuláltsággal kezeli a diszkeket a rendszer. Vagyis ez a legkisebb egység, amire bizonyos műveleteket végre lehet hajtani.

A diszkek, ha állandó fordatszámmal és adatsebességgel mennek, akkor a lemez külső részén (a legnagyobb sugáron) a legnagyobb a sebesség. Minél nagyobb a sugár (és a kerület), annál nagyobb biztonsággal lehet felírni az adatot, ráadásul és többet/gyorsabban, mert kevesebbet kell lépnie az író olvasó fejnek is. A legkülsőbb track a track0.

A fentiek miatt a gyártók sebességi zónákra osztják a diszkeket. Van még 36GB SCSI diszkem, ahol a gyártó 2 zónára osztja a felületet: 36MB/s belső és 45MB/s külső - és ez meg is van adva az adatlapon. Egy 500GB SATA diszk esetén specifikálnak valmilyen b/s sebességet. Ezt a firmware belsőleg 16 (asszem) zónaként kezeli, aminek a sugár függvényében különböző a sebessége.

AIX alatt ez úgy néz ki, hogy a diszket 5 zónaként kezeli: outer edge, outer middle, center, inner midle, inner edge. (Néha csak három részre osztja, de ebbe most ne menjünk bele!)

Ezek után már ismerős a történet. A VG összeáll egy vagy több PV-ből. Ezek után készítheszt LV-ket, és ha kell, akkor az LV-re fs-t is.
Az LV elhelyezkedése a sebesség szempontjából fontos. Ha kívül van, akkor gyorsabb, de hát nem csak egy LV van a rendszeren. Egy példa:
- OS = outer edge
- journal log = outer edge/outer middle
- adatbázis = outer middle/center
Ezzel tudjuk, hogy multiuser terhelésnél - programindítás, adatbázis műveletek, no és a journal írogatása sűrűn előfordul. Ha a fenti sorrendben helyezkednek el az LV-k, akkor az egyes műveletek végzésekor a diszk kényelmesen elevátorozgathat az egyes területek között. Ha nem ilyen a stratégia akkor kialakulhat olyan helyzet, hogy az író-olvasó fejnek sokat kell ugrabugrálni és leesik a sebesség.
És akkor jön a tipikus eset! A kolléga szól, hogy elindított egy feldolgozást, ami fél óra múlva lefut, de nincs elég hely. ;) Ekkor bedugunk még egy diszket, hozzácsapjuk a fogyatékos munkaterülethez. Békeidőben, azaz alacsony workloadnál meg a migratepv és migratelv parancsokkal megkérjük a rendszert, hogy a megadott stratégia szerint rendezze át a diszkeket és LV-ket. A stratégia nem csak a zóna szerinti elhelyezkedést, hanem a másolatok (partition copy) diszkenkénti elhelyezkedését is megadhatja.
A mapfile a LV elhelyezés finomhangolására alkalmas. Ha tudod mit csinálsz, esetleg egy topológiát pontosan meg akarsz ismételni, vagy finomítani szeretnéd az 5 zónás kiosztást, akkor pontosan megadhatod az LV elhelyezését egy map file-ban: PV#:[PV#:PV#:]LV#:[LV#:LV#] - felsorolva, hogy mely fizikai diszken, milyen pozícióban szeretnéd látni az adott LV adott számú partícióját, illetve annak másolatait.
Az utóbbi magyarázata pedig az, hogy az AIX mirror3-at támogat, majd később az OS-re HS-t is. Meg tudtam adni, hogy a csatolók/diszkek sorosan vagy párhuzamosan végezzék a műveleteket, illetve elég, ha 1 copy hibátlan, vagy bevárja az összeset a hibátlan művelethez. Ha a megbízhatóság kell fokozni, akkor a "mirror write consistency" flag hatására a lezárt partíció másolatok tranzakcióit naplózza a track0-ra. Ez ugyan 8x-os lassulást eredményezett, de tudtuk, hogy az adatbázisszerver területe biztosan hibátlan.

Ennek a miskulanciának a tetején még kialakíthatsz RAID konfigurációt is csatoló nélkül, mert ezt is kezeli. Opcionálisan tartozhat hozzá egy "raid gyorsító kártya", amit csak be kell dugni a buszba. Soha nem használtam ilyen rendszeren RAID-et, mert minek. ;)
Szerintem a linuxhoz képest van +1 réteg, amit kezel is az AIX.
Tudom, ma már SSD a divat, de van egy pár terület, ahova nem jó.

> Az az igazság, hogy a SMIT csak néhány alapfeladatra jó. Pontosan a 4-es AIX-től kezdve senki sem használta, mert a kívánt konfiguráció kialakítására alkalmatlan volt.

Ezt meséld el az IBM-nek, az őáltaluk gyártott tananyagban jellemzően a SMIT-ről volt szó, és általában csak lábjegyzet (vagy az se) szintjén hangzott el a mögöttes tartalom. Ráadásul egy kezdő admin nyilván igyekszik az ilyen kliketi-klikk eszközöket használni - speciel én is mindig az F6-ot emlegettem, mint tanulási metódus.

(Amúgy kedvencem volt az egyik tananyagnak az a mondata, hogy "ezt a parancsot csak ebben a tananyagban dokumentáltuk" - mondjuk ott is csak félig, mert a példákban szereplő opcióknak kb. a fele volt leírva és a maradéknak is csak kb. a felét lehetett triviálisan kitalálni, hogy mire jó.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

A tanfolyamokat általában külső cégek tartják, és a tananyagot is ők állítják össze. Kicsit rosszmájúan: Az ott dolgozók képességei szerint. Az első AIX tanfolyamon - amin elég kezdő junikszosként vettem részt - javaslatomra rögtön kiegészítették két lényeges tudnivalóval az anyagot. Olyannal, amit még az oktató sem hallott. ;) Hogyan lehetséges ez?
AIX alatt volt egy Info, ami egész részletes magyarázattal szolgált elég sok dologra.
Az egyes parancsok részletes leírását meg a man tartalmazza, nem a SMIT. ;)

Persze hülyeségek mindenhol vannak. Sokat lehetett tanulni az akkor még csk 6800 soros bosinst (base operating system install) scriptből. Potosan látod hogyan épül fel a rendszer, meg hogyaszongya:
- ha a gépben nincs grafikus csatoló
- ha a bundle nem tartamaz grafikát
- ha a júzer nem kérte
- és megkérdeztem, de arra is no-t nyomott
AKKOR IS FELRAKOM AZ X-et!! XD

Miért gondolod, hogy egy szoba megismeréséhez elegendő egy apró lyukon benézni, amin keresztül egy spanyolfal apró darabját látod? Először nézd meg egy igen egyszerű parancs manját és dokumentációját (ez külön entitás lehet)! Aztán ugyanazt nézd meg linuxon! Szerintem ezek után igen hosszasan csendben fogsz maradni. :-D

A SMIT és a hálózati konfiguráció is egy nagy rejtély. Sokszor mindent előről kell kezdeni. Ez egészen addig van így, amíg nem érted a rendszer felépítését a sys0 ojjektumtól kezdve. Egy hálózati csatoló cseréje meg maga a halál! - Egészen addig, míg nem érted a felépítést. Ha meg igen, akkor rájössz, hogy a Windows XP is ugyanúgy épül fel. Khmmm...azért nem teljesen. ;)

Nem is veszem bántásnak, mert majdnem ugyanazt írtad le, amit én.
Legfeljebb néhány jelentéktelen véleménykülönbség van.

Az IBM a széles körben elterjesztett számítástechnikát úgy indította, hogy elérhetővé tette a PC dokumentációit. Állítólag attól félt, hogy nem tud elég nagy példányszámot gyártani ahhoz, hogy ipari szabvány lehessen.
Ma meg visszavonult a csúcsszuper gépeivel. Bár, ha AMD processzort használsz, abban ott csücsül néhány IBM POWERx-ben használatos technológia is. Csak legfeljebb nem olvastad.

A ZFS meg nem az eredeti IBM hardveren futó AIX által nyújtott tároló-kezelésnek az "ellenfele".
Nem is írtam ilyet. Pontosan azt ítam, hogy a ma általánosan haszált diszkek pont nem olyanok, és azt sem kezelik és részben nem is tudnák kezelni a mai oprendszerek. És ezzel marhára kell vigyázni!
Azt is írtam, hogy a ZFS javarészt kiküszöböli a fenti hiányosságokat. De nem tudja mindet...

Mi itt java részt egyszerű népek vagyunk...5 percenként elromló hardverből is lehet ötkilences SLA, csak kellően sok kell belőle.
Egy kis csúsztatást érzek. :-D
Pedíg én is leírtam ugyanezt:
Való igaz, hogy a megbízhatóságot több irányból lehet közelíteni. A redundáns tároláshoz akalmazhatsz néhány drága és magas megbízhatóságú elemet, vagy nagyobb számú és olcsó elemet. (google) Az utóbbi esetben a "házi" felhasználásnál - a kis darabszám miatt - inkább használnám a "megbízhatóság" helyett a "szerencse" kifejezést. :-D

"amiből 1 core kb. leveri a laptopodat + szerveredet + a szomszédpistike gamer gépét egymagában. ;)"

Ok, csak kit érdekel, ha nem a megfelelő feladatot oldja meg? Nekünk pl. kellett előző helyen 10-12 TB nettó tárhely alapvetően backupra meg kamerák felvételeinek rögzítésére lehetőleg úgy, hogy bővíthető is legyen és ne legyen kuka az egész, ha kihullik disk. Vettünk egy 2U -s Supermicro házat, lapot, 8G rammal a legkisebb Celeron procival. Ment rá FreeNAS, és TADA.WAV. IBM-nél ezt miből hoztuk volna létre?

Igazad van.
Most éppen a POWER5 után 8 bites PIC mcu a platform. Hidd el, pont abban vagyok jó, hogy mi mire jó és soha nem keverem össze.
Például azt is tudom, hogy egyes diszkeknek van streaming módja. Ha van ilyen, akkor rögzíteni is lehet rá ilyen módban, és se FreeNAS, se POW ;) NAS nem lesz gazdaságos. Csinálj ötöt belőle és máris megérte. De semmiképp ne keverd a backup szervert és kamera rögzítést, mert más prioritás és pontosság kell mindegyikhez.
Nyivánvalóan egy POWER9 - egyrészt nem diszk ;) - másrészt nem a ZFS alternatívájaként került szóba. Ha figyeltél, akkor arra hoztam példát, hogy az IBM fénykora elmúlt-e vagy sem. Ehhez pedig annak semmi köze, hogy hány millió nintedót, vagy vécémosó kefét ad el évente. Kapisch?

Ok.
Akkor a válaszok alapján a 2-es pontot át kellene fogalmazni úgy, hogy "felesleges HW RAID-et tenni ZFS alá, mert a ZFS kiváltja a HW RAID funkcióit és bizonyos esetekben jobban/hatékonyabban kezeli a hardware hibát, viszont a HW RAID elfedhet olyan problémákat, amik adatvesztést okozhatnak". Vagy valami ilyesmi.

A helyesírási dolgokat javítom, köszi.
A tilost azért használtam, mert tilos használni. Nem ellenjavallat, hanem orosz rulett ha a kontroller nem azt írja ki a lemezre amit a ZFS hisz, és ez nem hatékonysági kérdés. A vége pool összeomlás lehet. Pont ez a lényege ezeknek a pontoknak, hogy a kezdő ne fusson bele egy cumiba.

>nem azt írja ki a lemezre amit a ZFS hisz
Ez megis hogy fordulhat elo?
Bekapcsolt cache a kontrolleren BBU nelkul nyilvan veszelyes, de ez nem csak a ZFS-re nezve az, barmely fajlrendszer megrottyanhat, ha hirtelen elmegy az aram, mikozben 1GByte cucc var a sorara a kontrolleren. Ezert nem kapcsol be ertelmes ember cache-t BBU nelkul.
De ezt leszamitva el nem tudom kepzelni, hogy miert irna mast a kontroller a lemezre, mint amit kene.

Ez nem igazan valaszolja meg a kerdest.
Felreertes ne essek, en nem akarom megkerdojelezni, hogy a ZFS hatekonyabban tud dolgozni, ha kozvetlenul ralat a lemezekre. Nem ismerem a ZFS belso mukodeset igy velemenyt sem akarok mondani rola.
Nekem csak az csipi a szememet, hogy a ZFS elterjedese ota sokan elkezdtek ugy tenni, mintha a HW raid kartyak csak annyira lennenek megbizhatok, mint a magyar posta.

De ezt leszamítva el nem tudom képzelni, hogy miért írna mást a kontroller a lemezre, mint amit kéne.

Igen, Azt írja a lemezre a BBU-s HW és szerintem is egy tévhit az összeomlás. Állítólag ez a FREENAS-osoktól kezdett terjedni..
A különbség inkább ott van, hogy zfs fájlrendszer szinten látja a lemezeket, a hw raid ezt elfedi, ezért pl. rossz blokkok miatti hibákat sokkal jobban -és gyorsabban- tudja lekezelni ZFS, HW raid pedig csak lemez blokkokat lát, még a fájlrendszerről sem tud.

Inkább azt mondanám hogy nincs értelme hw raid vezérlőre zfs-t tenni, mert a legtöbb előnyt elveszted.

Hát itt egy példa 1 perc google után a pool megrogyásra:
https://www.ixsystems.com/community/threads/lost-zfs-pool-after-power-l…
A végén vissza lehetett szedni a poolt, meg lehet, hogy a ZFS már megoldja valahogy, mint ahogy az ECC ram sem szükséges, de akkor is értelmezhetetlen a hw raid egy ZFS alatt. Olyan mint ha vennél egy új teherautót, aminek önjavító motorja van :) és azt feltennéd a régi teherautód platójára és úgy hordanál vele sódert. Értelme semmi.

BBU nélküli HW RAID kártyája volt. (Areca ARC-1226)
De ettöl függetlenül, ne használj HW RAID kártyát, mert megkapod a HW RAID kártya összes kellemetlen tulajdonságát, és elveszted a ZFS RAID összes előnyét.
pl nem lesz csak egy cheksum az összes lemezhez, a metaadatok sem a tényleges helyre mutatnak, beékelődik a raid kártya mint "fekete doboz", ami nem javítja az olvasás sebességét. Nem árt ha van tartalék HW RAID kártyád , mert csak egy pontosan
ugyanolyannal tudod helyettesíteni és egy jó BBU-s kártya nem olcsó. HW RAID csak lemez blokkokat lát, nem tud semmit a fájl rendszerről , lényegében 1 hiba - 1 lemezcsere. ZFS látja a fájl rendszert lemezenként ott a cheksum, ezért "ügyesebben" kezeli a lemezhibákat is.

Nem kerestem, nem néztem soha ilyen szemmel a doksikat.
Az ellenkezőjéből fordítottam meg magamnak: soha sehol semmilyen utalást nem láttam arra vonatkozólag, hogy távoli és/vagy virtuális eszközöket javasolna bárki bevonni ZFS VDEV-be. Ellenben minden leírás arról szól, hogy közvetlen hardver szintű hozzáférést biztosító eszközöket kell a ZFS VDEV-ben használni, a ZFS-nek közvetlen a hardverhez kell hozzáférnie a tökéletes (tervezett) működéséhez.

Ettől függetlenül nem igazán jövök rá, hogy mi értelme lenne egy SAN-ról felvett blokk eszközre ZFS-t tenni. Pláne többre, valamilyen redundáns elrendezésben. Ilyen dokumentációt sem olvastam eddig.

Ez kb. az lenne, mintha egy HW RAID kártyára SAN-ról származó LUN-okat tennék, és abból alakítanák ki redundáns kötetet. Ha meg is lehetne csinálni, mi értelme lenne?
Vagy Linux MD-vel ugyan ez (mert ez még meg is oldható a valóságban, műszakilag). Mi lenne benne a jó?
A SAN általában már valamilyen (sőt, elég magas szinten) biztosított tárolást tesz elérhetővé. Miért lenne jó még egy réteget ráhúzni?

Értem. Csak azt nem értem, hogy mennyire realitás azt feltételezni, hogy a Sun nekiállt kifejleszteni egy Zettabyte FS-t direktbe kötött diszkekhez, miközben azért a szerver világ jelentős része használt (már akkor is) távoli diszkdobozokat.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ennyire reális: https://www.backblaze.com/blog/open-source-data-storage-server/
60 lemez fér egy vasba, ha telerakod 16TB-os lemezzel, az 960TB. Nincs a zetabyte olyan messze, a Sun nem 1 percere gondolkozott előre.

Te kevered a Ceph szerű software storage platform megoldásokkal, ami alma és körte, teljesen másra való.

Szerintem (mert nem találtam konkrét erről szóló írást) amikor ez indult (2001-ben, 2005-ben jelent meg az első prod. verzió), akkor nagy dolog volt egy szerverre rákötni mondjuk 4-8 JBOD dobozt, és összesen elérni 48-96-128 db meghajtót (vagy kevesebbet, vagy még többet). Pláne az olyan hardveres megoldások, amik ezt kezelni tudták, nagyjából a megfizethetetlen kategóriába estek (még vállalati szinten is). Nem igazán volt akkoriban olyan kiforrott (szoftver)rendszer, ami ezt "egyben" (nem egy kötetként, hanem "központosítottan", egyszerűen) kezelte volna. Szóval szerintem hálózaton elérhető adattárak nélkül is van értelme/létjogosultsága a ZFS-nek.

Én is raktam össze 4 db 8 diszkes Jamaica(*) diszkdobozzal, HP-UX-szal és LVM-mel gépet (igazából 2-node-os clustert), ismerem a dolgot.

A HP-UX 9.0-ban (1990-ben!) már volt LVM, amely LVM - ma 1.0-nak hívott verziója - max 255 db diszket tudott egy db. Volume Group-ba összefogni. És kb. az első pillanattól az a mondás, hogy mindegy, hogy az direktben kötött (paralel) SCSI, vagy épp valami SAN-ról jövő izé. (Igaz, ez a kötetkezelő réteg, az így csinált virtuális diszkre kell aztán egy FS-réteg.) Hasonlóan a Digital/Compaq-féle AdvFS (**) is hasonló paraméterekkel rendelkezett (szintén késő 80-as, kora 90-es évek) - ráadásul az a HP-UX-os LVM-mel szemben pont ugyanúgy egy kötetkezelő+FS-egyben, mint a ZFS. Szóval amikor a ZFS elindult, akkor azért nem volt olyan elrugaszkodott ötlet, hogy sok lokális és hálózati eszköz van összefogva, és egyben kezelve.

Röviden: én azon csodálkozom, hogy mennyire egyértelmű számotokra, hogy SAN-ról kiajánlott volume-ra ne akarjunk ZFS-t rakni.

(*) Ennek valami más a hivatalos neve, majd Saabi elárulja ha erre jár
(**) Pofátlan módon, mikor bemutatták Mo-n a ZFS-t (2005-ben a Solaris 10 kapcsán az Árpád-híd budai hídfője mellett valami szállodában), én rá is kérdeztem nyílt színen, hogy az akkor már legalább 10-15 éve létező AdvFS-ről nem hallottak a fejlesztők? (Nem arattam osztatlan sikert az előadók körében.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

+1
A SAN az tulajdonképpen fizikai diszk.

Az AIX is eleve LVM alapú. Ha jól emléxem, úgy '97-ben adtam tanácsokat egy rendszerhez. A 11-es szám biztos, azaz összesen 11x16=176 SSA diszk volt a rendszerben. A diszkek két géphez fizikailag kapcsolódtak, gépenként egy csatolóval. (Ha tévedek kettő.) A VG kialakítása meg mindegy, mert bármit mehetett rajta. A két gépben még lehetett volna 7-7 diszk.
Igaz, akkoriban még kisebbek voltak a diszkek, de a diszkek darabszámának és későbbiekben a méretének sem volt igazi korlátja.

Igen, ez biztosan így van (én semennyire sem ismerem a HP-UX-et). Viszont a HP-UX egy zárt, egyedi rendszer, csak HP hardveren, és rettentő drágán volt elérhető. Nyilván amilyen szintű feladatokhoz azt tervezték-készítették, ott alap volt, hogy kezelje a nagy tárkapacitást, biztonságosan, gyorsan. Ugyan így nincs ismeretem DEC rendszerekről sem, de nem kétlem, hogy a maguk korában penge dolgok voltak.
Viszont az én értelmezésemben a Sun a ZFS-sel ezt a szolgáltatást sokkal nagyobb tömegeknek szerette volna elérhetővé tenni, és még tovább szerette volna vinni a teljesen integrált szoftveres tároló kezelést (igaz, a Sun gépei sem voltak kifejezetten olcsóak, vagy kommerszek).

De ez sem releváns, mert amiről mi itt most beszélünk, az a tényleg mindenki számára elérhető x86 alapú rendszerek, és az ingyenes (FOSS) ZFS megvalósítások.
És mint ilyen - pláne egy kezdőnek - nem a legszerencsésebb hálózati volume-okat betenni a ZFS pool-ba. Nem nem lehet, hanem ezen a szinten értelmetlen. Mert jó eséllyel egyetlen hálózati kapcsolaton, egyetlen, nem redundáns tárolóról van kiajánlva, és ez sok mindenre garancia, de a probléma mentességre nem. Ha meg már redundáns az elérés, a tárolás, stb. akkor meg nagyjából minek behúzni ZFS alá?

Részemről, ha osztott tárolást szeretnék (mondjuk virtualizációs klaszter alá), akkor valami jóféle storage, iSCSI-val (multipath-szal), vagy minden node-on CEPH-fel csinálnám. Semmiképp sem ZFS-sel operálva (a node-ok szintjén). Persze ZFS alapú storage vehető-építhető ehhez, de ott meg megint csak nem releváns szerintem hálózaról behúzni alá blokk eszközöket, hogy aztán tovább ajánlja hálózaton.

Nem, semmiképp nem ajánlott virtuális lemezekre ZFS-t tenni. Persze tesztelésre lehet, működik, de már otthoni hobbi rendszerre sem jó, nem még prod környezetbe.
Virtualizáció esetén viszont az tökéletesen működik (már az iXSystems szerint is, egy ideje), hogy a virtuális FreeNAS VM a host-tól PCI Passthrough-val megkapja a HBA-t.

Erre hol láttok utalást, hogy NEM való virtuális lemezekre? Egy rakat hivatalos doksit átolvastam, de ilyet nem láttam.
OK, hogyha szerencsésebb, jobb direkt hardware kapcsolattal használni, mint raid kártyával vagy más egyéb módon (hálózati fájlrendszer stb) mert nyilván elveszted a zpool adta lehetőségeket, DE összes többi jó tulajdonsága (snapshot, send-receive
, tömörítés, stb) attól még megmarad...

Hogy nem ismeri az alatta lévő hardvert így nem tud rá reagálni? Hát ilyen esetekben jellemzően azt az alatta lévő rétegnek kell megoldani, és ha bármilyen más fájlrendszert használnék, akkor se lenne rá megoldás...

Az iXsystems-nek volt egy érdekes cikke, ahol a poolba nfs hálózaton lévő fájlokat használtak device-nak és így hoztak létre 3 gépes hálózati adattárolást. (Mondjuk azt tán én se használnám:-))))

A doksik valóban nem írnak ilyent explicit módon. Azt írják, hogy ha megbízható rendszert szeretnél, a legjobb, ha fizikai diszk (és vezérlő) hozzáférést kap a ZFS. Ebből érti mindenki (én is), hogy nem igazán jó, ha nem fizikai hozzáférést kap (hálózati megosztás, virtuális lemez, stb.).

Az sehol nincs leírva, hogy nem működik ilyen esetekben a ZFS, szerintem nem is állította senki.

( uid_20269 | 2019. 10. 10., cs – 16:25 )

Főnév
ökölszabály

Gyakorlatban könnyen alkalmazható durva becslési módszer (főleg szembeállítva egy pontosabb módszerrel, amely azonban lényegesen bonyolultabb és/vagy kevésbé megvalósítható).

--
God bless you, Captain Hindsight..

( kisg v | 2019. 10. 10., cs – 17:14 )

A 7-es szerintem általános szabály, nem ZFS specifikus, hiszen megvan, hogy egy eszköz hány IOPS-t tud. Ezért fogja egy CEPH cluster lenyomni az 1 db ZFS-es szervert egy idő után. És ezért lenne jó a ZFS-t továbbvinni clustered irányba. Meg még tök jó lenne, ha nem csak POSIX API lenne felette, hanem mondjuk lehetne használni közvetlenül S3 kompatibilis object store-ként... :)

Az igaz, hogy általános de érdemes benne hagyni, mert több kollégával találkoztam már, aki kifejtette nekem, hogy minél több lemez van egy RAID tömbben annál lassabb lesz, mert többet kell a kontrollernek számolnia...
Azt beleírhatom, hogy az általános szabály itt is igaz.
Viszont szerintem a ZFS kontra CEPH az alma és körte, nem ugyan arra valók.

( ggallo | 2019. 10. 10., cs – 18:23 )

Én az 5. és 6. pontot átírnám kompletten ezzel a tematikával: Alapjában véve (indulásnál) nem kell sem L2ARC sem SLOG, ne erőlködj vele.
Ha ez a lista kezdőknek szól, akkor időben érdemes elterelni a figyelmüket arról amivel csak szívnak, költenek és valószínű nem lesznek előrébb. Majd ha idővel belejön, és kezdi érteni az egészet, akkor már el tudja dönteni, hogy kell-e a kettőből bármelyik, és ha kell, akkor min és hogyan fog segíteni.

Újabb pontnak pedig fel kellene írni (ezt az itt olvasható hozzászólások is megerősítik), hogy a ZFS elsősorban kiszolgálóra való rendszer, szerver célra, komoly hardverekre. Nem játék, nem desktop hardverre, nem kicsi pénzből, stb. Emiatt nem is univerzális, nem is mindenkinek való és nem is nyújt megoldást minden tárolással kapcsolatos problémára. De amire megfelelő rendszer, arra viszont (valószínűleg) a legjobb a lehetőségek közül.
Persze, elfut így meg elfut úgy is. Meg ezen is meg azon is. Már itt is látható, hogy "azért nem olyan jó mint mondják..." - az ilyen megállapítás mind abból fakad, hogy nincs megfelelő hardver alatta, és/vagy nem megfelelően van tervezve és kivitelezve, és/vagy nem a (ZFS-nek) megfelelő célra használják. Egy laptop vagy desktop gép egy szem lemezére miért kellene ZFS ugyan? Mi előnye lenne abban a környezetben bármi mással szemben? Ellenben egy 64 vagy 128 GB ECC memóriát tartalmazó kiszolgálónál nem mindegy, hogy 8 vagy 16 GB memóriaigénye van a komplett lemez alrendszer kezelésnek, ha az sokkal egyszerűbbé teszi az életet abban a környezetben?

Mikor nyomtam az Beküldés-t, már tudtam, hogy valaki beírja majd, hogy ez nem igaz, mert mennyit segít.

Odaírtam, hogy a kezdők - akiknek ez az összeállítás szól - ne erőlködjenek vele, mert hozzáértés nélkül felesleges.

Természetesen, ha olyan a terhelés, olyan a pool, és olyan az SLOG, akkor nagyon sokat segít. De a legtöbben elsőre összedobnak egy ilyent (lehetőleg 3 db 10TB-os HDD-vel, RaidZ1-ben, mert azt olcsón lehet kiműteni WD MyBook-ból), rácsapnak egy 20 TB-os médiatárat Plex vagy Kodi alá, aztán csodálkoznak, hogy a Filebot a letöltött anyag helyére másolása közben nem táltosodott meg a drága SLOG meghajtótól írás közben... Na ezért nem kell az első építésnél semmilyen L2ARC meg SLOG eszközzel foglalkozni.

Bocsi, de én ezt nem látom sehol hogy " jótanácsok kezdőknek." Legfeljebb kezdeti lépések, az meg azért más. 5-ös pont erről szól, csak kiegészítettem. Hátha első építésnél nem mindenki KODI meg torrent miatt érdeklődik, hanem pl. proxmox.
De lényeg a lényeg, ne mi döntsük már el ki mit csináljon. Mi olyan bonyolult ebben, hogy hosszú évek gyakorlata kellene hozzá.
5 perc google. vagy HUP, hacsak az illető nem szellemi fogyatékos. Akkor 10 perc. :)

Nekem az a tapasztalatom, hogy a ZFS-t használók 90%-a hosszú évek után is tévedésben élnek az SLOG és L2ARC dolgokról. Akinek ilyen irányú igénye van, az nyilván utána olvas idővel. Akinek nincs, azt meg csak elviszi a rossz irányba a próbálkozás, és jön a "nekem mégsem olyan gyors, szar ez az egész" duma.

Egyébként így kezdődik a poszt: "Sziasztok! Egy ilyen nekem az elején rengeteget segített volna. A célja elsősorban a ZFS-el ismerkedők eligazítása, illetve a kezdeti lépések segítése."

A cache dolgokon (5-6) én is agyaltam lehet, hogy igazad van, mert amikor elkezdem használni azzal szívtam talán a legtöbbet, de az SLOG tényleg brutál növekedést tud okozni. Persze csak ha van szinkron írás. Átírom valamennyire holnap.

0-ik pontnak írok egyet ami az lesz, hogy mire való, mikor érdemes használni, ez jó ötlet, de én nem vagyok ennyire szigorú :) Alapvetően tényleg szerver technika, de ha jól bánsz vele simán megy "gagyi" vason. Több előadáson belefutottam már ebbe: "ZFS loves cheap disks" Ha jól emlékszem azt meg egy ZFS fejlesztő mondta, csak akkor érdemes ZFS-t használni, ha érdekel, hogy az van-e a lemezen amit oda írni akartál :)
Ráadásul pár napos hír, hogy az Ubuntu 19.10-es desktop telepítőjébe benne lesz a ZFS választható rendszernek a root-nak. Ezen pislogtam párat én is, lesz itt nemsokára egy rakás "de szar", meg "mi a jó ebben" :)
Érdekes kérdés mindenesetre, hogy érdemes-e egy lemezen desktop gépen használni. Az Ubuntu szerint igen.

( szilard_ v | 2019. 10. 10., cs – 19:00 )

A 7-est még nem értem miért, de így írnám, ha már a teljesítményről szól:

7. Sok kicsi sokra megy: 3 x 10 < 12 x 1

Érteni értem, de amire itt utalás van, az a következő:

3 * 10 != 12 * 1

Ami teljesen igaz, és semmi extrát nem takar. A való világban elterjedt matematikában is igaz, hogy 30 != 12. Valaki pedig előttem jelezte, hogy e helyett kicsit feltűnőbb lenne a

3 * 10 < 12 * 1

forma, ami viszont - mivel matematikailag nem annyira egyértelmű, mint az előző verzió, talán jobban felhívja a figyelmet arra, hogy ezt is jobban meg kéne érteni. Mivel a topicgazda jelezte, hogy "igen, lehet hogy jobb ötlet, javítani fogom", erre kérdeztem rá, hogy na jó, de mikor.

Persze lehet, hogy ezt is félreértettem.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( sigellef | 2019. 10. 10., cs – 22:56 )

Egy ökölszabály még kimaradt: mikor használjunk ZFS-t?
Gondolom, nem desktop környezethez, mert így csak a fájlrendszer felemészt 8G RAM-ot, és még semmit sem dolgoztam a géppel.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Itt nem arról van szó, hogy az operatív memóriát hatalmas méretben használja fel pufferként? Ez kezdi elvinni a gondolatmenetet abba az irányba, hogy a látványos sebességnövekedést az okozza, hogy a memóriaelérés és műveletei sokkal gyorsabbak, mint bármelyik SSD? Ez persze pozitívum adott esetben és jó ötlet: érts, kiterjesztett zram feeling.

A ZFS memóriakezelése egy tankönyvet is megtölthetne. Több különböző dolgra is használja, de legnagyobb fogyasztó (dedup nélkül) az ARC cache. Ez kb. úgy működik, hogy mindent amit olvas betesz a memóriába, annyiba amennyit kap ez állítható, utána pedig intelligensen figyeli, hogy mit használsz többet és az mard illetve, arra cseréli. Kell neki idő is, hogy "betanuljon". Ez az olvasási teljesítmény mérését eléggé el tudja vinni. Gyakorlatban olyanokat tud csinálni, hogy mérsz 200 MB/s-t utána meg 5000 MB/s-t :D Ez a módszer gyakorlatilag használat függően egészen eltérő eredményt tud adni.

( pepo v | 2019. 10. 11., p – 09:52 )

Gyuri, küldtem levelet, ha nem kapod meg, kérlek, írj rám.

( mogorva v | 2019. 10. 12., szo – 09:32 )

Igazából miről van itt szó?
Általános ZFS, ZoL, OpenZFS?
Mindegy?

( debtamas88 | 2019. 10. 12., szo – 10:46 )


2. Soha de soha ne használj hardver RAID-et ZFS-hez, se bármilyen más szoftver RAID rendszer
Tilos a ZFS alá bármilyen RAID rendszert tenni! A ZFS egy teljes önálló rendszer a disk-re írástól a RAID-en át a fájlrendszerig, nincs szükség alá semmilyen egyéb rendszerre, hardver raid-re meg pláne.

Ezzel nem egészen értek egyet, a következők miatt:

RAID kártyát lehet használni JBOD/RAID0 módban (minden egyes diszket egy RAID0-tömbbe raksz bele - ami az OS alatt sima diszkeknek látszik):
-Az I/O műveletek nem a CPU-t terhelik, hanem a RAID-kártyán lévő SOC-ot.
-Raid kártyán lévő cache memória gyorsítja az I/O műveleteket.
-Az OS felől a SMART adatok lekérdezhetőek.

Raid kártya pl.:
HPE SmartArray P840/4GB FBWC

ggallo említette már:
"ez az egyik legtöbbet vitatott kérdés a ZFS-sel kapcsolatban"

A fő probléma
HA az adatokat a RAID kártyán lévő hardveres gyorsítótárba írják, a ZFS-t folyamatosan tévesen informálódik az írás tényleges megtörténtéről komittálásáról. Ez egy ideig jól működhet, de áramszünet esetén katasztrofális károkat okozhat a ZFS „pool”, ha a kulcsfontosságú metaadatok elvesztek az átvitel során.

https://mangolassi.it/topic/12047/zfs-is-perfectly-safe-on-hardware-raid

Itt egy "ellen" cikk, nem fogja elönteni a kérdést, -csakis BBU-s RAID kártyáról beszéljünk- , arról ír hogy a ZFS 3 "termék" egy fájlrendszer, egy logikai kötetkezelő és egy szoftver RAID rendszer. Ha te úgy döntesz, egyet nem használsz és a RAID-Z helyett használod a BBU-s HW RAID-et, akkor használd, nincs veszély, de egy csomó elöny elveszik. És azért megemlíti a cikk :
passzthrough vagy a RAID 0 mód használata a RAID hardveren rossz ötlet;
Nincs ok HW RAID kártyát használni.Abban a következtetésben lehet hogy igaza van a vitatőknak, ha a BBU-s RAID adatvesztést okoz , akkor adatvesztést okozna bármelyik másik fájlrendszeren is.

Raid kártyán lévő cache memória gyorsítja az I/O műveleteket.- ez nem biztos minden esetben.
A sebességeket meg nem elmélkedéssel lehet meghatározni, meg kell mérni. Talán hasznos lenne egy ilyen teszt.
Vannak power lost tesztek is, kipróbálod lesz-e adatvesztés és döntesz. A tapasztalatokat majd írd meg , ha van ilyesmire időd meg hangulatod.

> egy ideig jól működhet, de áramszünet esetén katasztrofális károkat okozhat
> a ZFS „pool”, ha a kulcsfontosságú metaadatok elvesztek az átvitel

Itt ugyebár arról van szó, hogy power loss esetén a BBU hajtja a DRAM-ot, ami tartja a ki nem írt adatot amíg bírja.
Ha már nem bírja, akkor (meta)adatvesztés képzelhető el.

> A sebességeket meg nem elmélkedéssel lehet meghatározni, meg kell mérni. Talán hasznos lenne egy ilyen teszt.

Csak az a gond, hogy nem mindenkinek van erőforrása (idő, pénz, ember) lePOC-olni több alternatívát, hanem felcsap egy ilyen fórumot és abból próbálja meg kihámozni az okosságot. :)

Félig off, adatvesztés teszt: itthon az RPi-n ki akartam próbálni, hogy ha különböző módokon lerángatom az DATA-nak használt external HDD-t, akkor milyen FS esetén mi történik. rsync-kel küldtem kismillió file-t és közben ilyeneket csináltam:
- kihúztam az USB kábelt
- kirántottak a diskből a tápot

Visszadugás után az XFS és az ext4 is szépen talpra állt, javította magát, stb.
Gondoltam, akkor kb. mindegy, legyen XFS!

Abban az időben kb. fél év alatt lett 3 áramszünet itthon.
Az XFS össze-vissza fosta magát, a headless RPI állandóan konzolos beavatkozást meg kézi xfs repairt reklamált.

Újra formáztam az egészet ext4-gyel és azóta nincs baj (pedig volt pár áramszünet), boot közben összekaparta magát a journal-ból és kész.

Szóval csak azt akarom mondani, hogy néha még a teszt sem segít.

Itt ugyebár arról van szó, hogy power loss esetén a BBU hajtja a DRAM-ot, ami tartja a ki nem írt adatot amíg bírja.

A Power Loss Protection-os SSD-knél kikapcsoláskor, RAID kártya következő bekapcsoláskor írja viszza, ha jól tudom.

Ha már nem bírja, akkor (meta)adatvesztés képzelhető el.

Reméljük bírja és nem tréfából írták az adott termékre, mert viccnek azért erős lenne.

És mivel a RAID kártya lemez blokk szinten működik, nem érdekli a fájlrendszer, nem tulzó kérdés az hogy ok, nem ajánlott, de mitől van adatvesztés?

"de áramszünet esetén katasztrofális károkat okozhat" - a csilliógigabájtnyi ram-ban tárolt motyó elvesztése az nem gond, csak a raid-vezérlő aksis cache-e. Ééértem... Ja, nem.
Ramban tárolt metaadatokesetén volt adatveszéts egy tápkábel kirángatás után, a bbwc tartalmát viszont nem sikerült ilyenformán elveszíteni.

(zeller) a csilliógigabájtnyi ram-ban tárolt motyó elvesztése az nem gond,
Nyilván gond, most a fájlrendszer konzisztenciájának megőrzéséről , illetve a szinkron írások biztonságos végrehajtásáról van csak szó. Adatvesztés a szinkron írásoknál szintén nem fordulhat elő a ZIL miatt.

(ggallo) aZFS-t használók 90%-a hosszú évek után is tévedésben élnek az SLOG és L2ARC dolgokról

Kezdőknek mégiscsak hasznos SLOG és ZIL tanácsok következnek, ne legyenek tévedésben: Nehogy ilyen ZIL-t szerezzetek be, tévesen, vagy ilyet próbáljatok beszerelni( ne is keressétek a SATA csatlakozót, fölösleges):
https://hu.wikipedia.org/wiki/ZiL%E2%80%93130

Az aszinkron írások igen, elvesznek, de fájlrendszer hiba nem lesz, nem kell fsck. COW, másolás közben akár kihúzhatod a 220-ból a gépet, nem sérül a fájlrendszer,

Ha pedig gond akkor a "pool"-t be tudod állítani kötelező szinkron írásra , ekkor minden írás "biztonságos" szinkron írás lesz, az aszinkron is.(set sync=always).

Abban igazad van, pontosabban kell megfogalmazni, hogy mit jelent a "hardver RAID" mert egy HBA (JBOD) módban levő P840 akkor most mi. Ez jogos.
A RAID 0 már nem jó ötlet.

Ez az OpenZFS doksiból van:

"Hardware RAID

Hardware RAID should not be used with ZFS."

Tudom, hogy vannak, mostanában divatosan mondva "unortodox" üzemeltetők, akik mindent jobban tudnak mint maga a szoftver írója. De szerintem a "gyártó" nem viccből írja ezeket. A ZFS nem fájlrendszer, hanem egy integrált RAID, kötetkezelő és fájlrendszer egyben.

A ZFS hw RAID-en használva olyan, mit ha a két hw RAID kártyád lenne. Az elsővel szerveznél pl egy RAID5-öt és utána azt odaadnád egy másik hw RAID kártyánk ahol RAID 0-ba raknád. Hát én még nem láttam ilyet...


RAID kártyát lehet használni JBOD/RAID0 módban (minden egyes diszket egy RAID0-tömbbe raksz bele - ami az OS alatt sima diszkeknek látszik)

Itt szerintem nem elég érthetően fogalmaztam.
Tehát arról van szó, hogy van pl.: 12db diszked, akkor lesz 12db RAID-0 tömb - nem pedig 1db "nagy" RAID-0 tömb.

Azért én egy óriási különbséget csak látok a natív HBA és a megtrükközött RAID0 volume-ok üzemeltetése között: a kártya hibája esetén a HBA helyére bármilyen más (gyártmányú, kialakítású) HBA mehet (aminek van elég portja a diszkek számára), vagy épp SATA diszkek használata esetén bármilyen más (kellően sok SATA porttal rendelkező) alaplap/kártya mehet a HBA helyett (átmenetileg vagy végleg) cserébe. Ellenben a HW RAID kártyával kialakított volume-okat csak egy ugyan olyan tudású (valószínű azonos gyártótól származó és azonos vagy magasabb kategóriájú) kártya tudja majd kezelni (és még gépészkedni is kell, hogy a diszkeken lévő RAID konfigurációt felvegye a csere kártya). Ez azért nem mindegy szerintem.

Több szálon is fut ez a "vita" a HW RAID kártyák használatáról, és az okfejtésről, hogy ez miért is nem baj az, sőt majdnem hogy jó.

Én kicsit onnan is megnézném, hogy minek elpocsékolni egy méreg drága HW RAID kártyát erre, ha egy nagyságrendekkel olcsóbb kártya is megteszi?

Cégesen, új hardvert véve egyértelmű, hogy nem rendelek HW RAID-et, ha ZFS alapú rendszert/tárolót építek, mert nettó pénzkidobás. Otthonra meg, ha mondjuk van egy örökölt/ajánkékba kapott HW RAID kártyám (ami történetesen nem váltható natív HBA módba), akkor sem használom. Én részemről vettem a meglévő PERC H710 helyett egy H310-es 15 ezerért (használtan), és FW-t cseréltem HBA üzemmódhoz (a H710 nem alkalmas erre), úgy használom. A H710 meg kéznél van, ha mondjuk egy VMware alá akarok normális tárolót tenni egy másik szóló gépbe local storage-nek...

Én úgy látom, azok erőltetik leginkább a HW RAID kártyák használatát, akik elő tudnak kapni egy olyan használaton kívüli szervert, amiben ilyen van, és nem akarnak vagy tudnak egy HBA-t beszerezni. Ahogy itt már többen leírták, működni fog. De ha előkerül valami megmagyarázhatatlan hiba, amire a Google az első két lapon nem ad megoldást, akkor senki sem fog tudni segíteni, és a HW RAID meghallása után nem is akar.
Ahogy régen a HP desktop-oknál volt: fagyogaott a Windows 3.1 (mint kiderült utóbb, RAM hiba miatt), de a HP megtagadta a garanciális javítást, mert nem eredeti HP 5.25"-os meghajtó volt a gépbe szerelve, és szerintük annak inkompatibilitása miatt történik a fagyás (nem floppy műveletnél természetesen). Aztán egy eredeti HP meghajtót vásárolva majd beépítve az újabb garanciális szerviz megállapította a RAM hibát és cserélték is... Na kb. ilyen a megfoghatatlan ZFS hiba HW RAID használata mellett esete a világhálón.

Szóval a HW RAID ellen: egyetlen ZFS doksi sem javasolja ÉS sokkal drágább is. Mellette nincsenek érveim. Szóval nem értem miért is kell erre a kérdésre (úgy általában, nem csak itt) ekkora hangsúlyt fektetni. Ha valaki mondana valami valódi pro dolgot (a sok kontra ellen), isten bizony megfontolnám HW RAID használatát a fentiek ellenére magam is.

Én csak ezt a részét cáfoltam:

kártya hibája esetén a HBA helyére bármilyen más (gyártmányú, kialakítású) HBA mehet (aminek van elég portja a diszkek számára), vagy épp SATA diszkek használata esetén bármilyen más (kellően sok SATA porttal rendelkező) alaplap/kártya mehet a HBA helyett (átmenetileg vagy végleg) cserébe.

Amúgy HBA módba nincs write-cache, ami azért HDD-nél hasznos, még ha a felettes rétegnek van is saját cache megoldása.

A HBA kártyát nem kell managelni. Ha egy Pxxx kártyát HBA módba állítasz nem is lehet állítani rajta kb. semmit, mert a OS közvetlenül éri el a lemezt (tudom lehet pi..a szőrt hasogatni, hogy nem, mert ott a hdd firmware, meg mikrokontroller kód etc. de az itt nem lényeg) a RAID-et a ZFS (vagy valami más szoftver RAID) kezeli. Ez inkább előny mert ha van egy összerakott moniotring rendszered és más gépet kapsz legközelebb akkor írhatod újra az egészet. Ezen kivűl egy alaplap hiba esetén ha nincs kéznél ugyan olyan gép, akkor lehet szaladgálni, hogy hozzáférj az adataidhoz.

( hyper80 | 2019. 10. 12., szo – 10:53 )

Sokan írtátok, és már lassan ökölszabállyá válik, hogy a ZFS hez rengeteg memória kell, hogy jól működjön.
Ezzel nem is vitatkozok, de bizonyos esetekben nem felétlenűl kell neki egy rahedli memória. Ha valahol a teljesítmény nem elsődleges szempont ott simán elműködik kevesebb memóriával is.
Konkrétan nekem évekig jól ment 2Gb RAM-al később pedig (és jelenleg is) 4Gb-al, egy 2Tb pool -on.
Vannak snapshot-jaim, és csinálok scrub-ot is rendszeresen. Folyamatosan figyeltem a memóriát, és nem került a rendszer kritikus állapotba. Az elsődleges szempont nálam az adatbiztonság volt, ezért a lemezeket a ZFS simán tükörben hajtja, és azért ZFS, mert olyan fájlrendszert szerettem volna használni, ami checksumming-ot készít az adatokról. (Ugyanis volt már szerencsém olyan lemezhez amin csendben olvasási hiba nélkül megváltoztak az adatok)
Ezek közül a btrfs és a zfs volt elérhető, és hosszas tesztelés után a zfs mellett döntöttem.
Lehet, hogy bizonyos terhelés mellett leesik az átviteli sebességem 100Mb/s ről 50-re, vagy ha sok kis fájlt kezelek akkor lassabban megy, de ez engem ebben a szituban nem izgat. Elsősorban hosszú időre arhívált adatok vannak rajta, nem működő sql adatbázisok vagy weboldalak. ÉS így nekem teljesen bevált.

Hogy valami (talán)hasznos tanácsot is hozzátegyek a szálhoz: ZFS Pool létrehozásakor érdemes nevesített GPT partíciókat létrehozni a lemezeken, és a pool-ba ezeket a nevesített partíciókat belerakni a /dev/mapper -en keresztül. Így ha valami katasztrófa után egy másik gépbe át kell raknom a lemezt adatmentés céljából a ZFS pool-ban lévő eszköznév nem változik és ott is elérhető lesz. Ha a partíciónevek utalnak a lemez paramétereire akkor az még praktikusabb. Pl: wd_red2tb_down2

Sokat teszteltem a ZFS, a btrfs-t és a hagyományos sw raid-lvm-ext4 kombinációkat is virtuális gépeken, úgy hogy direkt beletúrtam a virtuális disk-ek adataiba, hogy hibákat idézzek elő, és minkét checksumming fs kiállta a próbát.

Éppen arra akartam utalni a fenti hozzászólásommal, hogy az én tapasztalatom szerint arra _IS_ teljesen jó lehet ha otthonra akar valaki egy sima pc hardverre egy robosztus tárolót építeni, házi NAS céljából. Ebben az esetben megkapjuk a snapshotok készítésének a lehetőséget, a checksumminggal támogatott raid-et, a Copy On Write tulajdonságot, és egy ilyen esetben legtöbbünket nem fog zavarni, ha az io sebesség kicsit leesik, ha túl sokat írunk rá egyszerre.

Nekem egyre inkább úgy tűnik, hogy a ZFS az storage service alá való megoldás

Azért ennyire nem rossz a helyzet :) Én 10+ Proxmox szervert üzemeltettek ZFS-el, jó pár FreeNAS-t, és már vannak már Ubuntu-s szervereim is ZFS-el. 8GB RAM-ot a RIAD rendszerre szánni, mikor már a telefonokban is 32GB-van szvsz nem egy horrorisztikus igény.

Átgondoló amit írsz, mert talán túl ijesztő amit írtam. Tényleg van olyan eset amikor elég lehet kevesebb is, de ezzel vigyázni kell, mert nagyon súlyos problémát okozhat a kevés ram, ezzel van bőven tapasztalatom :) Tesztelni, meg archiváló gépnek, kis terhelésű NAS-nak a sarokba elég lehet, de ez mindenképp a lehetőségek "kisebbsége".

Mit értesz az alatt, hogy vigyázni kell, mire vigyázzunk? Milyen probléma adódhat a kevesebb memória miatt a teljesítmény visszaesésen kívűl egy házi szervernél? Azért kérdezem, mert én nem tapasztaltam ilyet, ha te igen akkor oszd már meg légyszíves az ilyen irányú tapasztalataidat!

Te is írtad, hogy 100Mb-ről 50Mb-re csökkent a hálózaton a sebesség, ez látatlanban memóriára visszavezethető lassulás. A legnagyobb gond a load elképesztő méretűre növekedése. Jelenleg is van olyan gyenge szerverem, ahol ez simán fel tud szaladni 40-50-re de itt még úgy ahogy bírja, nem lesz a szolgáltatásokkal gond. A túl kevés memóriával ez a terhelés, illetve lassulás elér egy "elviselhetetlen" szintet ahol már a futó szolgáltatások megadják magukat. Ez, én úgy tapasztaltam, hogy erősen függ az adott process/daemon implementálásától. Az Apache pl. egyszerűen megáll és kész. Az ssh meg egyre lassabb lesz, volt amikor stopperrel mértem 3 perc felett volt egy billentyűleütés. Ha virtualizálsz, pl Proxmox a vm-ek megállnak. Ahogy kidőlnek a szolgáltatások, idővel csökken a terhelés és újra javul a dolog, de volt olyan tesztem is ahol nullára megállt a gép. Lehet, hogy ha vártam volna 1-2 órát magához tért volna, de az nyilvánvalóan nem vállalható. Ez az állapot ha mondjuk másolsz egy jó nagy fájlt igen sokáig eltarthat, mert elindít egy "öngerjesztő" folyamatot, az egyre lassuló rendszeren, egyre tovább tart a művelet.
Ebben az a szívás, lehet, hogy elsőre fel sem tűnik, csak ha összeáll egy elfogyó memória / nagy io terhelés helyzet. Meg kell találni azt a memória mennyiséget ahol ez a "jelenség" nem jön elő. Nekem eltartott egy darabig, míg felfogtam, hogy ezzel nem játszom, inkább adok a ZFS-nek memóriát gazdagon. Ezért ajánl a FreeNAS minimum 8GB Ram-ot. Ekkora mennyiségnél a maximális io terhelés mellett sem lesz olyan állapot, hogy "behalnak" a szolgáltatások és nem jelentkezik ez az öngerjesztő katasztrofális lassulás. A memória további növelésével pedig egyre jobban javulhat a teljesítmény, de ez több mindentől függ. Egy adott gép minimális memóriájának meghatározására nincs egzakt képet (legalább is én nem találtam), mert erősen használatfüggő. Ezért van, hogy olyan memória mennyiségek az ajánlottak, ahol ez nem fordul elő. Akkora tudásom nincs, hogy pontosan tudjam, hogy mi történik a ZFS lelki világával amikor túl kevés lesz neki a memória, de jól kitapasztalható a jelenség ami ilyenkor történik.

Elsősorban az ARC cache-t állítgattam. Nem tudom igaz-e, de azt tapasztaltam, ha az elég nagy és gépben a memória 0-ra elfogy akkor sincs gond. Mintha adna a cache a "többieknek" (ZFS többi része) belőle. A másik meg az, hogy úgy tervezed meg a gépet, hogy legyen benne elég memória. Ez ZFS nélkül sem árt.

Hát bevallom az első véleményem a ZFS-ről az volt, hogy ez egy rakás szar :) aztán nem hagyott nyugodni a dolog. Utána minél jobban megismertem annál jobban megszerettem.
Ha jobban belegondolsz mindenek van előírt memória/hw igénye és ha azt nem kapja meg jönnek a gondok. Senki sem próbál windows-t 1GB ram-mal használni, és nem magyaráz, hogy de gáz, hogy nem megy vele. Aki futott bele abba, hogy a BBU beszarik a RAID kontrollerben és az lekapcsolja a write cache-t, az tudja hogy anélkül nagyjából használhatatlan lesz. Egyszer egy ilyen eset miatt egy P440-es kontrolleren egy 40GB-os vm restore a gépre 48-órát futott. Hétvégén nem tudtam szerezni kapacitort. Volt olyan esetem is régebben, hogy 3 db ML150-hez kaptunk a HP-től olyan kontrollert ajándékba egy bocsi mellett ami drágább volt mint maga a gép, mert az alaplapi RAID maximális teljesítménynél úgy belassult, hogy a Windows megállt rajta. A P840-nek meg 4GB memóriája van.

Szóval szerintem nem ördögtől való, hogy valaminek van hw igénye és az be kell tartani.

Tehat ha jol ertem ugy kezelted es alligattad be hogy hasznaljon minnel tobb memoriat, akar az osszeset a zfs arc cache nyugodtan?

Nekem a ZFS-es gépek többsége Proxmox egy rakás VM-el, ott nem adhatom oda az összeset. Általában 16GB-ot adok a ZFS-nek, de van 8GB-is és arra figyelek, hogy ne "koppanjon ki" a memória a gépeken. Van egy darab 4GB-os ZFS beállításom, és a szerverben 16GB RAM van összesen. Azon négy darab kis(ebb) igényű gép fut, amiket DNS, SeaFile, Postfix meg ilyesmire haasználok. Simán elvan a 4GB-al. Nehéz konkrét számot mondani a ZFS igényének, mert nagyon függ a felhasználás módjától, hogy mennyi az elég. A FreeNAS-okon meg közel az összeset neki adom. Van kettő Ubuntu-m is ZFS-el azoknál is sokat adok neki, de azok iscsi meg smb kiszolgálók.

Nem ertem minek hoztad fel a mindennek van hw igenye temat, en nem arrol beszeltem.

Akkor félre értettelek, és amúgy sem kioktatásnak szántam, ha úgy tűnt bocsi. Arra akartam felhívni a figyelmet, hogy a ZFS nem egy fájlrendszer, hanem egy RAID/kötetkezelő/fájlrendszer kombó. Ez sokszor elkerüli a figyelmét a használóinak és "igazságtalanul" hasonlítják össze pl az ext4-el.

Tudom hogy zfs nem csak filerendszer, nem is allitottam ilyet csak azt mondtam hogy amit leirtal szarul hangzik.
Az hogy egy gyenge szervernel konnyen felszalad a load 50-re az akkor nincs jol beallitva vagy limitalva. Lehet hogy nem erzekeled hogy kulonosebb gond lenne, de akkor is arra utal hogy valamilyen feladatok varakozni kenyszerulnek vagyis valahol lassulas van (felteve, hogy nem maga a program van rosszul megcsinalva hanem alatta OS, hw stb nem szolgalja ki rendesen), max szerencsesebb esetben meg nem eszreveheto, de rosszul fest.
Ha tul keves memoria miatt annyira belassul ahogy irtad, akkor olyat tudok elkepzelni hogy hirtelen megugrik a memoria hasznalat erosen, swap-elni kenyszerul amit azzal a tempoval nyilvan nem fog birni diszkre irni mint memoriaba, de ez meg annak is soknak tunik. Vagy oom killer forradalmart kezd jatszani es felszabadit a memoriabol ha annyira elfogyott csak valami folyamatosan rogton elviszi ujra. Esetleg nem memoria gond valojaban hanem kiesett a diszk alola es nem erzekeli vagy nem tudja kezelni, probalna irni ra de nem tud es varakozni kenyszerul, network diszk eseten ez konnyebben elojohet halozati hiba eseten. De ezek nemigazan filerendszer/storage problemak igazabol hacsak nem zfs annyira zabalja a memoriat mert szarul kezeli/nem allitottad be jol, esetleg ha raid-ben levo diszkekbol meghal/nagyon belassul az egyik es ahelyett hogy kidobna kuzd vele es emiatt lassul le, mert akkor zfs hiba.
Esetleg rosszul meretezted a write cache-nek szant reszt, ha pl ssd-d van ra es oda letarolodik sok random adatod gyorsan viszont azzal a tempoval kozel se tudja a lassu diszkekre lerakni, de az irasmuveletek nem csitulnak akkor lehet olyan eset, hogy write cache megtelik/eleri a limitet es akkor meg kellene varnia mig a diszkekre ki tudja kuldeni ami a cache-ben van es addig nem vagy nagyon lassan tud befogadni uj irast.

Ezert is kerdeztem hogy miket alligattal, csak arc cache max meretet vagy tobbet is, l2arc, zil?
Netan hogy miket cache-eljen, sysctl parametereket, mount parameterek, van-e tomorites, dedup stb. Ha mar virtualizacio akkor vm-eknek tarhelye hogy van letrehozva es odaadva?

"Egy adott gép minimális memóriájának meghatározására nincs egzakt képet"
"Egy POOL kihasználtsága legyen 70% (80%-90%) alatt."
...
Ez a egyik fo problemam nekem a zfs-el hogy megfoghatatlan sokszor, vagy meretezd tul erosen vagy jatszogathatsz vele hol vannak a hatarai adott rendszerben, mert nincs keplet amivel ki lehetne szamolni de egyertelmu ajanlasok se igazan.
Masik gond meg szerintem hogy sok rendszeren nincs eleg jol implementalva a rendszerhez, pl ha jol remlik freebsd11-nel (de minimum 10) lattam olyat, default-ban vm.v_free_target erteke nagyobb mint a vfs.zfs.arc_free_target erteke (sysctl parameterek), ami annyit tesz ha keves a memoria akkor ahelyett hogy zfs arc cache-bol venne vissza, inkabb rendszer vesz vissza ahonnan csak tud minden fele buffer cache-t es egyebet, meg pakol ki swap-ra (ha van) amit csak tud, mikozben lehet zfs cache tovabb novekszuk, mert v_free_target kuszobot elobb fogja elerni es csak ha mar minden elfogyott akkor kezd el zfs cache-bol visszavenni, kozben meg lassul. Ez csak mert nincs jol osszehangolva es kulon kezeli a rendszer a zfs cache-t az egyeb dolgoktol.

A gyengébb gépeken általában egy pool van, nincs slog és l2arc sem. Az a tapasztalatom, hogy olcsó ssd-vel nem igazán hozza amit várnék tőle, de erről már folyt itt hosszabb eszmecsere. Tömörítés mindig van, dedup soha. A VM lemezek zvol-on vannak. A legrosszabb kontroller amivel dolgoztam HP ML10-ben levő B120-as, az egy vicc. Ami viszont pozitív csalódás a DeLock 89384, sokkal jobb mint vártam, pedig nem éppen a top márka. Ezek persze a belépő csóró szint, a legolcsóbb megoldások. Az átlagos (most elsősorban KKV-ról beszélek) szervereimben min 128GB ram van, abból nem kell cipőkanállal mérni a ZFS-nek.
Tervezzük a wiki oldalra egy "mérési jegyzőkönyv" listát, ahová várjuk majd a teljesítmény méréseket mindenféle konfigról. Én ilyet még nem találtam sehol, ha lesz elég beküldő kolléga, szvsz nagyon tanulságos táblázat jöhet össze belőle.

Köszi a tapasztalatokat. Az általad leírt teljesítmény csökkenésnek én közelébe sem kerültem még a 2gb -al sem, igaz nem webszervereket, adatbázisokat vagy vm-ek et hajtottam vele. Ja és azt is hozzátenném, hogy a rendszer teljesen külön lemezen van, zfs csak a fontos adatoknak van becsatolva.

( gyuri23 | 2019. 10. 17., cs – 15:08 )

Átdolgoztam a javaslatok alapján, megköszönöm a lektorálást.

1. Mikor használj ZFS-t.
A ZFS alapvetően egy szerverekre szánt nagy integritású és megbízhatóságú rendszer, érezhető hardver és tudásigénnyel. Természetesen nincs akadálya, hogy desktop rendszeren használd, az 19.10-es Ubuntu telepítője például már támogatja a használatát.

2. A ZFS nem az n+1-ik fájlrendszer, sokkal több annál, ezért ne is úgy gondolj rá!
A ZFS három kulcsfontosságú tárolási réteget (RAID, logikai kötetkezelés és fájlrendszer) egyetlen entitásba csomagol, ezért nem lehet egyszerű fájlrendszerként tekinteni rá. Ennek számos előnye van, a nagyobb integritástól, az egyszerűbb kezelésig. Sajnos egy pár dogot újra kell tanulni miatta, de cserébe itt egy lista, hogy egymaga miket cserél le, ha elkezded használni: hw raid szoftverek, md, lvm, fájlrendszerek (ext3, ext4, xfs, stb.), mkfs, fsck, fstab, dd...

3. Ne használj semmilyen RAID rendszert a ZFS alatt, különösen hardver, de szoftver RAID-et sem.
A ZFS nem támogatja a hardver RAID használatát. A ZFS egy teljes önálló rendszer a lemezre írástól a RAID és kötetkezelesen át a fájlrendszerig, nincs szükség alá semmilyen egyéb rendszerre, hardver RAID-re meg pláne. Gondolom nem használsz egy szerverben egymás alatt két RAID kontrollert, a ZFS alá se tegyél, használj HBA kontrollert. Az újabb RAID kontrollereket át lehet kapcsolni HBA módra, az természetesen jól használható.

4. A ZFS gyors működéséhez három dolog kell, RAM, RAM és még több RAM.
A leggyakoribb probléma a ZFS-el az elégtelen memória méret. 2 GB elég lehet tesztelésre, vagy a sarokba egy nagyon kis terhelésű NAS-nak de komoly munkára nem elég. 4 GB-val el lehet indulni, de inkább 8 GB-ot számolj minimumnak. Terhelés függően lehet, hogy még ezt is érdemes lesz növelni. Ez persze a többi (rendszer, alkalmazások, stb.) memóriafogyasztás felett számítandó!

5. A deduplikáció memóriaigénye, nagyon nagy. 4-5GB RAM / 1 TB adatmennyiség (blocks * 320 bytes) A lemez olcsó(bb) ha nem muszáj ne használd.
A deduplikáció memóriaigénye a többi (pl. ARC) memórián felül számolandó, ezen kívül CPU is kell neki. Nem biztos, hogy megéri az extra teljesítmény és memória ráfordítást, ha megoldható helyette több lemezzel, számolj utána.

6. A LOG (Separate Intent Log SLOG) használata nem biztos, hogy növeli a teljesítményt.
Az SLOG (ZIL-nek is szokták nevezni tévesen) lemez használata ez egyik módszer amivel gyorsítani lehet a ZFS írási sebességét. Vagy mégsem, mert csak a sync írást gyorsítja. Járj utána mikor, mire jó és mire nem. Ha nem tudod mi a különbség a ZIL, SLOG, sync és async írás között, ne csodálkozz, ha nem az lesz az eredmény mint amire számítottál. Csak akkor használd, ha pontosan tudod mire jó, különben pénzkidobás lesz a vége.

7. Ha tudsz, inkább használj az CACHE (L2ARC) lemez helyett RAM-ot.
A CACHE lemez használata nem csodaszer és lehet, hogy semmit nem fog gyorsulni a rendszered tőle, viszont van amikor igen. Abban hasonlít az SLOG-ra, hogy nem minden esetben van értelme. Csak akkor használd, ha pontosan tudod mire jó, különben pénzkidobás lesz a vége.

8. Sok kicsi sokra megy 12 x 1 > 3 x 10
Amivel jelentősen növelhető a teljesítmény az a sok lemez. Ha akarsz például 10TB területet 2 paritás lemezzel akkor sokkal jobb a 3x10TB helyett a 7x2TB lemez és még annál is jobb a 12x1TB.

9. Egy POOL kihasználtsága legyen lehetőleg 70% alatt.
Ez nem csak a ZFS-re igaz, hanem minden fájlrendszerre. Több mindentől függ mikor kezd lassulni, de 70%-kal nem lősz mellé.

( uid_4656 v | 2019. 10. 25., p – 01:33 )

Elolvasva ezt az egészet:

- Az otthoni/munkahelyi PC-itekben és laptopjaitokban tényleg HDD-k vannak és nem SSD-k? SSD-n és otthoni/munkahelyi használatban teljesen lényegtelen a RAID, LVM, fájlrendszer stb. A HDD-SSD ugrás nagyon sokkal nagyobb változás, mint amit bármi más hoz ezekben az esetekben. Személyes használatú gépen még fontos adatot nem tartunk, csak cache-ként használva a gépet :-)

- Az IBM jelenlegi termékei vacakok. Bocs, hogy ilyen nyersen mondom. A Power procik teljesen feleslegesek bármilyen nem speciális workloadhoz ÉS elég drágák, főleg a hozzáértő mérnökkel és supporttal együtt. 3 db Power géppel több hardveres bajunk volt 5 év alatt, még mint 6 keret HP és Cisco blade-del összesen. A storage-ok (FS900, Vx000) és az SVC-k dettó. Szétesik az SVC replikáció? Firmware frissítés kell! Eltűnik a LUN? Firmware frissítés kell! IBM MQ a csoda DB2-vel a háttérben? Tizedannyi pénzből nagyon sokkal jobban skálázható bármelyik *MQ széltében...

Biztos én vagyok helikopter mondjuk...

Azért A csicsó blédekkel kapcsolatban olyanokat hallottam "valakitől", hogy azt azért értelmes gyártó nem engedte volna termékként eladni. Az IBM esetén igen, firmware frissítés is szükséges lehet, merthogy ott a hardware/firmware/OS alkot egy egységet, és hiba esetén a megfelelő komponenst cserélik/javítják, nem pedig egy másik rétegben taknyolják körül a többi hibáját.

Mondjuk onnan nem volt nehéz javulni... :-) És igen, a POwer architektúrához megfelelő workload megtalálása, kialakítsa nem egyszerű feladat - egyszálú számolgatós-adatbázisturkálós dologra például pont nem jó :-) Egyébként meg ilyen alapon a storage-ra épített virtualizációs környezet is sz@r, mert láttunk olyan workload-ot, amihez egy asztali pécé+ssd jobb/gyorsabb volt, még úgy is, hogy a virtuális környezetből mentés a pécére, ott adatok megcsócsál, majd ZUtty vissza a vm-re :-)

+1
Nem, nem a helikopterre. ;)
Egész értelmesen leírtad, hogy hibásan méretezett (wtf volt olyan?) rendszer, hozzáértés nélkül nagyon drága. Ráadásul, ha POWER szervert veszel - mert mondjuk én azt állítottam, hogy az jó - akkor az előbbi feltételek mellett baromi drága.

Való igaz, hogy az IBM szervereket - és nem csak ma - két fő szempont szerint alakítják ki. Vagy nagy számítási igényre, vagy nagy teljesítményre. Sok esetben mindkettőre, mióta egységesek lettek a processzorok.
A DB2 biztosan rossz, bár az IBM rendre azzal nyerte az "adatbázis versenyeket", feleannyi core felhasználásával. ;) Nyilvánvalóan ezt is lehet rosszul használni, mint bármit.