Nagy jó cikk lett, gratula!

Én voltam figyelmetlen, vagy nem emelted ki, hogy a partíciók létrehozásakor nincs megadva méret. Miért lettek egységesen 151GB-osak?

Na, végre egy szakmai cikk a Logouton! Egyre ritkább sajnos...
Köszönjük, kiváló lett, jól felépített igényes írás!

Otthon én is már jó sok éve használok FreeNAS-t, maximális megelégedéssel. Egyszer húztam újra az egész rendszert, éppen az ZFS miatt, mert -ha jól emlékszem talán a v9.0/9.1 környékén vezették be, vagy akkor vezették ki az UFS-t, már nem tudom-. Korábban UFS-t használtam, mondjuk nekem azzal sem volt adatvesztésem. Bár eleinte én is sokkot kaptam a RAM igénytől, a gyakorlatban tesztelve 16GB-al simán elmegy otthoni környezetben (nálam 6db HDD-vel, összesen 10TB a kapacitás jelenelg, de tervezem lecserélni kevesebb, de nagyobb tárakra).
Az ECC RAM egyébként nem csak adatbiztonság miatt jobb, hanem a sokkal jobb minőség ellenére még olcsóbbak is a használtpiacon!

Szia, köszi. Válaszolva a kérdésedre: ZFS-nél nem kell megadni a partíció méretet. A pool-ban lévő szabad helyet az egyes "alfájlrendszerek" közösen fogyasztják.

Valóban figyelmetlen voltam, oda is írtad hogy már használatban, és látni is hogy "csak"151GB szabad.
Esetleg ezen tulajdonságát jobban is kiemelhetnéd, hiszen nincs szükség az adott partíció méretének megbecslésére.
Ugyanakkor be lehet állítani limitet, hogy az egyik ne nőjön a másik fejére? Pl. egy elszabadult program/felhasználó teleszemeteli, és a többieknek nem marad üres hely.

[ Szerkesztve ]

Nekem még nem volt napi szinten szükségem erre, de lehet kvótát beállítani (majd a napokban hozzáírom. Többféle létezik:
1) A teljes fájlrendszerre vonatkozók:
$ sudo zfs set quota=10G vd-Rocinante/backup
és
$ sudo zfs set refquota=10G vd-Rocinante/backup
A második csak annyiban különbözik, hogy abba nem számítódnak bele a pillanatképek.

2) De lehet felhasználóra és csoportra is létrehozni:
$ sudo zfs set userquota@ubuntu10G vd-Rocinante/backup
$ sudo zfs set groupquota@wheel=20G vd-Rocinante/backup

3) Fenntartani szabad helyet, mint az ext3-4 fájlrendszernél
$ sudo zfs set refreservation=2G vd-Rocinante/backup

Amire vigyázni kell, hogy amikor a kvóta határát elkezdi elérni a felhasználó vagy a fájlrendszer, akkor az IO műveletek belassulnak, ugyanis a ZFS szeretne mindent kiírni, de pont csak annyit amennyit lehet. Mostanság az a törekvés, hogy egy lustább ellenőrzés legyen benne, ami megengedi a túlcsordulást, és akkor nem fog ez a lassulás jelentkezni. (hivatkozást most nem tudok a problémára)

Köszi! Ez a licence dolog érdekelne, csak nemtok külföldiül. Úgy kell elképzelni mint mint régen az mp3 kódek, vagy miért csak modulként lehet jelen?

Amikor megláttam a kötet elnevezését, akkor azon gondolkodtam, hogy ló- vagy irodalom-kedvelő lehetsz - de aztán kiderült, hogy egyik sem

[ Szerkesztve ]

Nem vagyok én sem jogász, de tömören én úgy hámoztam ki, hogy a CDDL csak annyit köt meg, hogy a forráskódnak kell mindig CDDL-nek és nyíltnak kell lennie, míg a lefordított bináris kb tetszőleges license alatt kiadható. A linux GPL-jéhez ha hozzáadunk valamit forráskód szintjén, akkor az GPL-nek kell lennie, vagy legalább át lehessen váltani GPL-re. Ez a kettő ütközik, ezért csak modulként érhető el.

A fent leírtakban nem vagyok teljesen biztos, ha valaki jobban tudja, akkor javítson ki.

Elképesztően jó írás, hiánypótló. Képbe tett rendesen (Pont most NAS-ozgatok btrfs-el, esetleg arról is írhatnál egy "pillanatfelvétel" / snapshot jellegűt, hogy hol tart ma)

Még van lehetőségem áttérni ZFS-re

Szuper, köszönöm.

[ Szerkesztve ]

Azt még érdemes megemlíteni (nem láttam a cikkben), hogy bővíteni csak vdev szinten lehet, szóval egyszerre több diskkel (amiből egy legalább paritás lesz).
Szóval emiatt nem ajánlanám mindenhova, pl házibarkács NASba néhány vinyó mellé a SnapRAID+Mergerfs kombó rugalmasabb, simán hozzá lehet csapni vagy kivenni egy disket.
Mondjuk azt még nem vizsgáltam, hogy milyen a SnapRAID alatti ZFS raidz nélkül, bár elég öszvérnek hangzik.

Nagyon jó, tömör írás.
A ZFS tévhitek és problémák résznél a #2 tévhithez szeretném megjegyezni, hogy valóban lehet nem ECC RAM-ot használni, de ez hasonló jelentőségű hiba, mintha a háttértár redundancia nem megfelelően lenne megtervezve. Ahogy a merevlemezeken is képesek a bitek "átfordulni" ugyan úgy a RAM-ban is előfordulhat ilyen. Ezért használjuk a háttértárakon a ZFS-t és a memóriára az ECC-t.
A nem olyan gyors, mint lehetne: részhez érdemes megjegyezni, hogy nagyon nem mindegy mire fogjuk a rendszert használni és ehhez a PORONIX áprilisi tesztjét elolvasni itt:

Köszönöm a cikket.

Szegény ember vízzel főz, itt a cégnél is sima memóriával (16G) megy a zfs, szintén 6x2T raidz2 elrendezésben. Vagy 5 éve hibátlan, sima desktop gép, bár már jövőre cserélve lesz.

Szerintem félreérthettél. Nem szeretnék arról vitatkozni, hogy hol, milyen drága konfiguráció működik addig míg egy teljes, vagy részleges összeomlás be nem következik és, hogy ez miért érte meg az illető cégnek. Megjegyzésem javító szándékú volt, hiszen a cikk tévesen állítja, hogy a nem ECC RAM megfelelő. A ZFS fájlrendszer éppen a hibák kiküszöbölése, kizárása érdekében készült. Ha a teljes láncolatba, ahol az adatok megfordulnak gyenge láncszemeket rakunk, akkor az egész lánc olyan erős lesz mint a leggyengébb része. Tehát megismétlem a nem általam, hanem komoly szakemberek által is vallottakat: Lehet nem ECC RAM-ot használni, de ez órási hiba és ne kövessük el, ha az adataink érnek valamit. Ezt kellene a cikkben pontosítani.

Végre egy korrekt szakmai cikk, sajnos nagyon sokan nem fogják elolvasni, vagy mert nem értenek hozzá, vagy mert nem érdekli.. inkább a Lego!

A cikkben ezt állítom:
"Szinte minden fontos környezetben elvárás az ECC RAM, hogy ott is meglegyen a hibaellenőrzés. A ZFS is nyugodtabb ilyen körülmények között. Jó lenne az ECC, de sima DDR[1-4] modulokkal is használható."
Annyi csak a lényeg hogy attól, hogy ZFS-re váltunk egy szerveren, azért nem kell ECC RAM-ra váltani. Az adatbiztonság miatt viszont akkor is ECC RAM-ot használjunk, ha más fájlrendszert használunk.
De akkor ezt pontosítom.

[ Szerkesztve ]

De a cikk nem biztonságtechnikai megfontolásokat elemez, vagy ajánl, hanem a ZFS-t mutatja be. A nem ECC RAM megfelelő, hiszen nem kitétel a ZFS működéséhez.

Az teljesen más kérdés, hogy adatbiztonság fokozásának egyik HW-es lépcsőfoka az ECC RAM használata.

[ Szerkesztve ]

Jó lett, színvonalas, és érthető

Szuper írás, köszi szépen!

Először is megköszönöm a befektetett munkát, egyre ritkábban lát ilyet az ember itt és máshol is...

A témával kapcsolatban: előköerült itt az ECC memória kérdése. Amellett, hogy soft raid-hez szerintem is elengedhetetlen, hallottam róla, hogy mintha lenne valamiféle fejlettebb hash eljárás vagy hash generálás, amivel a ZFS képes detektálni a kis mértékű adat hibákat nem ECC memória mellett is, amiből normál esetben silent corruption lesz. Esetleg érdemes lenne foglalkozni ezzel a cikkben, hátha tud olyasmit a ZFS ebben a kategóriában, amit a többi fájlrendszer nem tud. És most nem a normál hash-elésre gondolok, amit a BTRFS is csinál, hanem arra, hogy a hash előállításában vagy visszaellenőrzésében esetleg lehet olyan trükk, amivel kibukhat egy kis mértékű memóriahiba. A topik aktivitását nézve úgy látom másokat is érdekel ez a téma

Nem tudok arról, hogy további védelem lenne benne. A bit-rot (amikor a háttértáron a bit értéke véletlenszerűen ellentétesre vált) detektálás hash alapján történik, az ARC memória hibája esetén pedig a checksum is hibás lesz, ezért újraolvassa az adatot és egy másik memória területen tárolja le az ellenőrzésre. Szerintem egyéb trükk nincs benne. A btrfs checksum-ja is tudja detektálni a bitrot-ot, de csak mirror konfigurációban tudja biztosan kijavítani (raid5-6 -ban nem). A btrfs memória kezelésével pedig már tényleg nem foglalkoztam.

[ Szerkesztve ]

Azt, hogy tudom megnézni, hogy a zfs aktuálisan melyik checksum algoritmust használja?

a zfs get checksum parancsot ha kiadom csak annyit ír ki, hogy checksum on default.

Szuper lett a cikk!
Amúgy nemrég én is építettem egy saját NAS szervert 6x3TB hdd-vel és fedora-t valamint zfs-t (raidz2) használok.

[ Szerkesztve ]

Ezek alapján fletcher4 az on jelentése.

Illetve pl itt tudsz kicsit utána olvasni.

[ Szerkesztve ]

A másik nagy kérdés, hogyha a zfs set checksum=edonor pool_name/dataset_name beállításra kerül, akkor a már régebben kiírt adatokhoz tartozó checksum-okat hogyan lehet újra számoltatni, hogy azok is az edonor-t használják?

[ Szerkesztve ]

edonor = edonr
Bocs elírtam.

Ez csak az új adatokra vonatkozik. A blokk ami már kiírásra került, az marad a régi checksum, recordsize, compression beállításokkal.
Nem lehet újra-számoltatni, az adatokat újra ki kell írni (másolás, áthelyezés).

Ezt freenas-on is igy kell felkonfigolni? Mintha a cikk elejen az lett volna, hogy freenas-on hasznalod, de a freenason levo beallitasrol nem volt szo.

Nem, freenas sokkal egyszerűbb és webes gui van hozzá. Sok mindent megcsinál helyetted.
Linux-ot vettem alapul az íráshoz. De a zfs parancsok mindenhol ugyanazok.

Urak !

Köztudott, hogy ZFS alá nem illik bármi logikait is tenni, de a titkosítás része érdekelne, mivel van, ami titkosított és van ami nem: LUKS-on próbált már vki zfs-t kreálni ? Mondjuk egy mirrort két /dev/mapper-es LUKS titkosított eszközön. (Ez így fullba titkosítaná a motyót és detached header esetén már csak random szemét adat, ami látszik az adathordozón).

[ Szerkesztve ]

A ZFS és a LUKS is eléggé ismertek és népszerűek, ergo felvetődött már párszor a kérdés, igen.

Akkor még egy kérdés, hátha erre is lenne google link

Adott egy natúr ntfs meghajtóm, tele cuccal. Veszek mellé egy másik tökugyanilyet holnap. Mirror-t szeretnék zfs-el.

Meg tudom azt a trükköt játszani, hogy a mirror egyik lábát létrehozom az "új" HDD-n zfs alapon és csak utólag tolom be alá a második lábát ? Ezt linux alatt meg tudnám játszani például md raid-el (U_ státuszú lenne a tömb, UU helyett).

Rámásolnék mindent a régiről (ezáltal defragmentálódik is a motyó rendesen, mert már tök fragmentált minden a régin), majd ha jónak ítélem meg a másolást, merném a régit törölni és a zfs mirrorba 2. lábként betolni.

Replikál, béke. Menne ? Annyira nem triviális nekem az IGEN, mint egy szimpla md raid esetén.

[ Szerkesztve ]

Hagyd a fenébe az md raid-et. Csak megnehezíti a lemez kezelést. Zfs-sel is ugyanezt meg tudod csinálni:
1) létrehozod az új zpool-t és azon a fájlrendszereket.
2) felmásolsz mindent
3) utána hozzáadod a lemezt tükörként:
sudo zpool attach vd-Rocinante /dev/disk/by-id/amin-már-zpool-van /dev/disk/by-id/korábbi-ntfs-hdd
Ekkor lezajlik a resilver és az adatokat a másik lemezre is szinkronizálja. Sőt még további lemezeket is hozzá lehet adni ugyanígy a későbbiekben (3-4 lemezes mirror).

Az otthoni gépen hasonlót csináltam, első körben csak egy 4TB-os hhd-re volt pénzügyi keretem, majd később vettem egy másodikat is és hozzáadtam.

Az a zfs verzió (0.8-tól), amiben van titkosítás az az ubuntu 19.10-ben van benne.

[ Szerkesztve ]

A ZFS-el az a bajom, hogy megmondható, hogy azon a diszken titkosított adat van, teljesen random adat helyett. Nem titkosít mindent a zfs, az utolsó bit-ig is akár... ezt csak LUKS adja úgy, hogy ha akarjuk, még fejlécet sem tesz a titkosított motyó elé.

Ehhez hozzájön a dm-integrity, ami végre blokk szinten checksum-ol és így luks2-vel kombinálva, USB-re detached header-es /boot , olyan rendszert lehet csinálni, amit beindítok USB stick-ről, beröffen, mount-olok neki egy hdd-n lévő /boot-ot, majd kiveszem a stick-et, és kész is. (Ügyelve arra, hogy /boot frissítésekor a stick-en lévőket is sync-eljem azonnal).

Avatatlan szemek ha kihúzzák és ellopják, vagy hasonló, semmit nem látnak rajta tökrandom adaton kívül. Erre a zfs titkosítás önmagában nem képes jelenleg, árulkodik magáról. Nem lehet megcsinálni azt vele, hogy:

1. randommal teleírod /dev/sda-t

2. Létrehozol egy 20 gigás Windows-t vagy ekvivalens bármi egyebet (C: )

3. Létrehozol egy kiterjesztett partíciót a maradék helynek, rajta egy exFAT mondjuk, az egyszerűség kedvéért (D: -nek, quick format)

4. Teszel rá ezt-azt. (D-re)

5. Defrag-olod a free space-t D-n, így az elejére gyűlik a hasznos adat

5. Néha be-be indítod ezt a Windows-t és használod általános dolgokra egy fél órát. A gép ugyebár magától így indulna amúgyis, boot sector, minden adott rajta.

6. Te USB stick-ről indítod az amúgy mókás rendszered, legyen az NAS, bármi egyéb funkciók

7. Mindegyik nagy HDD-n a rajtalévő adat mögött (biztonságban) indítod a titkosítást (headerless, LUKS2, integrity aed-el), letojva azt, hogy a saját Windows-a alatt a diszk végéig logikailag egy exFAT partíció van amúgy (de hát nem írja végig a felületet, ugyebár).

8. A titkosított meghajtókat zfs mirrorba vagy zraid1-2-3-ba teszed, ízlés szerint ahány van, úgy.

Utána fogja Rád bárki, hogy a Windows alaprendszeren és pár fájlon kívül van egyéb is a gépen, ha viszik.

+ a dm-crypt-ben van már veracrypt extension is, truecrypt/veracrypt titkosítást kezel, elér, felold, lezár, itt jön képbe az undeniable encryption, stb.

Szóval a zfs egy iszonyatosan király cucc amúgy, de úgy nem tud titkosítani, hogy ne is sejtse avatatlan szem, hogy ott van a szemeten kívül bármi is a "törmelék" között.

root@DESKTOP:~# zpool status -v
pool: zfsmirror1
state: ONLINE
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Wed Feb 26 19:52:30 2020
907G scanned at 668M/s, 146G issued at 107M/s, 3.32T total
146G resilvered, 4.28% done, 0 days 08:38:26 to go
config:
NAME STATE READ WRITE CKSUM
zfsmirror1 ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-ST4000VN000-1H4168_Z503T7M2 ONLINE 0 0 0
ata-WDC_WD40PURX-64GVNY0_WD-WCE6E3MS78Z9 ONLINE 0 0 0 (resilvering)
errors: No known data errors

[ Szerkesztve ]

Szóval végül megfogadtam a tanácsod és belevágtam. Jópár sikeres teszt és az ECC RAM-jaim érkezésével el is indult nemrég a móka.

A neten azt olvasom mindenhol, hogy - nyilván - nem ajánlott, de egyébként bármikor nyugodtan reboot-olhatok, vagy gép kikapcs és reggel bekapcs, folytatja tovább, nincs adatvesztés (lényegében a zfs zseniális alapelveinek és működésének köszönhetően lehet ez így igaz állítás). Stimm ?

[ Szerkesztve ]

Ja és brahiból compression=gzip-9 Az első telemásoláskor tekert elég jól mind a 12 proci szál, de így is kimaxolta a HDD fizikai átviteli sebességét lazán. Vegyes motyók vannak-lesznek rajta, kíváncsi leszek, hogyan viselkedik hosszabb távon ez a megoldás, sokat nem nyerek rajta, de direkt ezt húztam be most.

Arra is kiv. leszek, olvasáskor mennyi CPU terhelést kapok, 1 lemezzel, illetve 2-vel majd. Lemérem majd.

Szia,
Újra lehet indítani közben a gépet, nem lesz semmi gond. Újrakezdéskor a meta szektorokat újraolvassa, de az nagyon gyorsan megvan. Utána pedig folytatja ott ahol ezek alapján szerinte abbamaradt.
Azért próbálj meg egy al-fájlrendszert lz4-gyel is.

Úgy lesz, megpróbálom.

Érdekes, hogy attach-kor az ashift=12-t meg kellett adnom neki, de egyéb paramétereket nem (pl. xattr=sa, atime=off -ot nem tudta az attach értelmezni, de mivel a meglévő dataset így ezekkel lett létrehozva, azt gondolom, attach-kor az új csatlakozó fizikai tároló is megkapja ezeket a jellemzőket, ahogy mirror-á konvertálódik az egyedülálló dataset és már ketten vannak). Compression-t sem fogadta el az attach... igazából elég leszűkített opciókat fogad, ahogy olvastam man pages-ben és neten is, de valszeg ez okkal, mert hát meglévő dolgokhoz csatlakozik és akkor azok property-jeit felveszi, gondolom, ami nagyon okos működési logika lenne).

Mindenesetre gyönyörűen elindult a resilver, tényleg csak ashift=12 volt az attach parancsban a plussz.

4 tera (3.4 használt), most jár 70% körül.
(Kikapcsoltam este, reggel boot, szépen folytatja a resilveringet azóta is).

[ Szerkesztve ]

Azt jól vettem ki a doksiból és innen-onnan, hogy ha a sima "add" paranccsal hozzáadok fizikai tárolót a meglévő pool-omhoz, amiben immár van egy mirror, akkor a rendszer egy "raid0" (stripe) dolgot hoz össze a mirror-al és az új diszkkel ?

Szóval
- ha a mirrorba akarnék harmadikat: zpool attach
- ha a mirror mellé akarnék még egy két diszkes mirrort: zfs add mirror dev3 dev4 ?

(És így kapok a két mirrorból egy raid0-t, összesen a raid10-et lényegében).

Jól írod, az "attach" egy diszkhez ad hozzá tükörként mégegyet, míg az "add"-al egy új vdev-et lehet hozzadni a meglévőhöz, ez nem pont raid10 lesz, hanem mintha hozzáadná az elérhető szabad helyet. Az írások viszont elosztva mennek ki, terheléstől függően.

És ha jól tudom, automatikusan megtörténik a balanszozása is az adatoknak, tehát a meglévő mirror-0 -mon lévő 4T adatomat elteríti úgy, hogy fizikailag a végén 2T marad a mirror-0-n, 2T pedig az új 4T-s különálló HDD-n, ha egy olyat tolok be hozzá "add"-al.

Legalábbis ezt olvastam. (És ilyenkor raid0 szerű működést kapok). De elvileg ez automatikusan végbemegy a háttérben, nem ?

(Kipróbálom ma este egy virtuális gép alá betolt kisméretű virtuális HDD-kkel).

Nem fog balanszolni, mert ami adat már egy blokkon van, azt nem mozgatja.