Új hozzászólás Aktív témák
-
Dißnäëß
veterán
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 ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
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 ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
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 ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
válasz
stopperos
#37
üzenetére
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.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
válasz
stopperos
#39
üzenetére
Én nem feltétlen a cikkre reflektáltam, viszont akkor átmegyek szívesen a ZFS topic-ba, ha van ilyen. Ha nincs, indítani lehet(ne)..
A ZFS rengeteg mindenre van, az adatbiztonság pedig kettébomlik azonnal, egyik az integritás (tehát amit tegnap kiírtál, az még ma is az beolvasáskor), másik a titkosítás (hozzáférés).
Nem gondolom, hogy bármelyik miatt off lenne.
Van egy cikk egy tokaji fordításról és elkezdünk beszélgetni arról, hogy ha a szomszéd szamorodniját ilyen és ilyen fűszerezésű csirkéhez vagy kacsához fogyasztod, vajon milyen ízvilágot kapsz a végére és a kettő fog-e hasonlítani egymásra. Ez nálam nem off, de ez ízlés dolga, szerintem 1 vitát nem ér meg.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
válasz
stopperos
#37
üzenetére
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 ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
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.
![;]](//cdn.rios.hu/dl/s/v1.gif)
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 ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
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.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
válasz
stopperos
#44
üzenetére
Ú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 ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
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).
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
válasz
stopperos
#47
üzenetére
É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).
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
Szóval ha két új meghajtót hozok, hogy azokon kevésbé fontos dolgokat tároljak és ez a mirror megmarad, akkor:
1. semmiképpen sem a meglévő poolba tenném őket "add"-al (sem "attach"-el nyilván), hanem
új pool kreálás és oda "add" mindkettőt. Mivel csupaszok lesznek még, valszeg egyenlően fogja elosztani rajtuk az adatokat (raid0-szerű működés). Mount-olva logikailag kb:
- mirror (hdd1, hdd2)
- stripe (hdd3, hdd4)2. ha pedig érintetlenül szeretném hagyni őket, egymástól függetlenül, akkor 2 új pool és mindegyikbe "add" 1-1 HDD, így lesz végül 3 pool-om, amiknek fel-mount-olt könyvtárai:
- mirror (hdd1, hdd2)
- standalone (hdd3)
- standalone (hdd4)Stimm ?
[ Szerkesztve ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
A zfs 1 lemez esetén is biztosít némi integrity-t, kis hiba esetén ?
Tud olyat, hogy akárcsak a cache-t, SSD-re tenni mondjuk az ellenőrző kódokat ?
Példa:
4T HDD: adat + ellenőrzők
512G SSD: cache (vagy sem) + ellenőrzőkA két ellenőrző garancia lehetne arra, hogy egy kis HDD silent bit rot esetén egyértelműen tudja a rendszer, az adat szar-e, vagy az ellenőrzője. Kérdés, hogy ha erre (mivel két ellenőrzőnk lenne) rájön, tehát ellenőrzők jók és adat szar, vissza tudja-e kalkulálni az adatot matekból, vagy ahhoz minimum 2 fizikai diszk kell (mirror).
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
Arrol mi a velemenyed, hogy a zfs titkositassal az adat ugyan vedve van, de a hdd-rol kiderithetik meg, hogy zfs titkositott adat van rajta, mig LUKS titkositott, header-t NEM tartalmazo HDD totalrandom adathalmaz... Igy emiatt LUKS kotetet szoktak tolni a paranoidok a zfs ala, es a zpool-ba a fizikai eszkoz helyett mar a logikai eszkozt adjak be.
Csak mert ezzel a megoldassal en is szemezek, a kerdes csak az, hogy a zfs oriasi elonye, az integritas ilyenkor hogyan valosul meg.
Pelda:
Tegyuk fel, mirrort szeretnek zfs-el. Titkositott hdd-kkel, legyen 2db. Mivel paranoid vagyok, usb-rol boot-olok (amit utana kiveszek a gepbol, ha mar fut, /boot-ot at-mount-olom elotte a feloldott HDD-re). Az usb-n van a detached header is, azaz a LUKS2 header, kulcs meg vagy a fejemben, vagy fajlban az is az usb-n, ez mar reszletkerdes.A HDD-ket tehat LUKS2-vel titkositom.
Lesz ket dm-encrypt akarmilyen nevu eszkozom (mapper talan, ha jol remlik korabbrol). Ez mar logikai szint.
Ha ezekkel hozom letre a zfs mirrort, fasza vagyok, mukodik a dolog.
Nade itt jon a kerdesem: ha a fizikai lemezen tortenik egy bit hiba, es nincs az korrigalva, a felette levo LUKS titkositasban kepes bizonyos szintig ezt kikorrigalni a rendszer ? Mert a fizikai bithiba a titkositas miatt azt az adott LUKS blokkot megoli ugy, ahogy van. Ez ki tudja, hany kilobyte, de a LUKS szint is azt fogja mondani, hogy az a blokk szar, titkositas nem oldja fel a beolvasott adatot, ergo nincs mit a mapper eszkoznek tovabbadnia.
Beall vmi hibaval a rendszer, vagy tovabbadja mint hibas szektort a mappernek a LUKS ?
Utobbi jo lenne, mert zfs lekezelne ezt a mirroros felallasban nativan. Mint hibas szektort, nem mint bit flip-et. Sima bit flip nem jutna el a zfs-ig bit flip-kent, hiszen az az 1 atfordult bit a titkositas miatt egy x kb-os titkositott blokk resze es miatta az egesz blokk feloldhatatlan elvileg, tehat zfs szamara mar egy egesz blokk hibaja latszil, ha LUKS tovabbadja ezt a fentebbi retegnek.
(Ha nem, lehet a LUKS is elhasal hibaval es cseszhetunk mindent).
Na ezekrol semmi infom, mert tok jo lenne am kombinalni az integritast a LUKS-al.
Van erre lehetoseg, a dm-integrity erre valo, es ha LUKS2 alatt ugy formazom a ket hdd-t, hogy --integrity, akkor tartalmazni fog ellenorzo adatot minden egyes LUKS2 titkositott blokk is. Az mas (es ez a baj!), hogy nem annyira szofisztikaltan tobb peldanyban, mint a zfs. Ergo, bithiba ellen ved egy dm-integrity alapu megoldas, de ha ott tobb szektor is szar, vele egyutt - mivel ugyanott a hiba teruleten van az ellenorzo is - az ellenorzo is eluszik, hibasodik, tehat cseszhetjuk.
A zfs ha tudna ugy titkositani, mint a LUKS2, nativan, hogy ember meg nem mondja, ott titkositott adat van (header kulon meghajton), az lenne az igazi, de ilyenre nem kepes meg.
A sima integrity-s linuxos megoldasok meg azt a fajta kreativ es okos logikat mellozik, ami a zfs alapmukodesere jellemzo.
Szoval ... szivas, jol latom ? (Ha bebizonyithatatlanul titkositani akarnek ket HDD-t, zfs mirrorkent).
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
válasz
stopperos
#58
üzenetére
Értem. Arról van infód, mennyire stabil enterprise/vállalati környezetben a zfs ? Biztosan hülye kérdés, de lehet ezzel egy komoly, akár 50-100 diszkes storage farm-ot is építeni ? (Hardver adott). Gondolom, ha Solaris gyökerei vannak, kifejezetten jól zenél ilyen célra is, főleg adatbázis, analitika, ilyesmire lenne használva.. ezt már csak úgy féloff-ban kérdem.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
válasz
stopperos
#60
üzenetére
Sejtettem. Tökéletes. Kísérletezgetek, gondoltam azért megkérdezlek. (Linux-os verzióval tolom, legfrissebbel, de állítólag stabil ő is, főleg ha maga a rendszer is stabil alatta).
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
Kedves stopperos. Ismét Hozzád fordulok, hátha csináltál már ilyet.
(Jól el-privizünk itt, ennyire senki sem ZFS-ezik ? ) 
Van két pool-om, egy mirror (2x4TB) és egy raidz1 (4x4TB).
Kérdéseim lennének:
1. Át tudom őket valahogy alakítani további külső eszköz igénybevétele nélkül titkosított pool-okká ? Akár kockáztatva is a redundanciát (szóval diszkenként lépkedve).
2. ZFS titkosítás: elég erős, vagy látszanak még dolgok, meta, header, ilyesmik, mondjuk egy LUKS2-höz képest ? (Ahol a header-t ki lehet vinni külön eszközre, pl. usb-re és azzal feloldani mindent, ha pedig nincs header kéznél, random adat az egész egy ismeretlen számára).
Úgy döntöttem, az egész gépem titkosítanám, lopás ellen/miatt. Nem vagyok vmi jó környéken és mindig ettől "rettegek". Nem az eneszéjt kellene megállítanom, csak szimplán ha neadjisten elviszik a hónuk alatt a gépházat, ne tudjanak hozzáérni semmihez (max törölni, de külső backup van a legfontosabbakról).
Te hogy csinálnád ? (Látom, sokan LUKS2 dm-crypto eszközökkel alkotnak pool-okat, nem tudom, ez hogyan viselkedik adatintegritás szempontból a felsőbb ZFS szinten, vagy ha fizikai hiba van egy hordozón).
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
Na közben utánajártam dolgoknak, végül LUKS2 mellett döntöttem.
Egy kis vinyós pool-on elpróbáltam:
- lementettem máshova a tartalmát
- zpool destroy ...
- cryptsetup luksFormat ...
- zpool create ... a /dev/mapper ... eszközönNincs több kérdés, kiváló.
[ Szerkesztve ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
válasz
stopperos
#69
üzenetére
Szerintem ketten vagyunk összesen. Te utat törtél, én haladok a nyomdokaidban.
Gyakorlatilag a rendszeren (ext4) kívül mindenem zfs, most a 6db 4T-s HDD-m két pool-ját tettem egyetlen raidz1-esbe 3db 8T-sre (NAS jelleg, de desktop használat, Debian Testing).
Többször is nagyon merész dolgokat tettem, amit senkinek nem ajánlok, nekem kényszer volt kicsit, mint pl. egyesével kicserélni a korábbi raidz1 pool hdd-it egyesével, önmaga titkosított mására (offline-oltam, luks-al letitkositott verziojat a /dev/mapper-bol visszaadtam a pool-ba replace-el, resilvering lement es oke, utana ugyanez a masodikkal es vegul a harmadikkal is). Masodik korben mar a 8T-s luks titkositott NAS diszkekkel replace-elgettem egyenkent a meglevoket, az egeszet pedig crypttab-bol feloldja a rendszer, a root particio ker indulaskor kezi jelszot, minden mast boot folyamat soran elintez (luks2 4096 byte kulcs, header fajlok is az ssd-n a root konyvtarban, a hdd-ken nincs header).
Tudom, nem a legoptimalisabbnak tartott dolog a zfs ala barmit is tenni, de igazsag szerint volt mar pici hibam egy Purple-el, scrub alatt, ott is a titkositott layeren volt a zfs. Nyilvan ha bithiba van fizikai szinten feluleten, akkor a felette levo titkositasi blokk szinten hibas lesz, amit zfs ugyanugy erzekel es kijavit, ez is tortent.
A zfs encryption meg annyira nem jar ott, mint egy teljes diszk encryption header nelkul, de majd beerik ez is.
A Debian Testinget frissitve raneztem a zfs verziora es a 2.0-asat mutatja mar, mig a pool-ok meg 0.83-asok voltak (fejbol, ha jol emlekszem). Egyelore stabil a 2-es verzio, azt latom, minden ok.
Megelegedessel hasznalom a zfs-t, erdekes volt a slog-rol es az l2arc mukodeserol olvasni, meg finomhangolni a poolt itt-ott aprosagokkal, most a sebessege is mar elfogadhato.
Szeretem ezt az egyszeru kezelest, egyszeru (nalam default-automatikus) atmeretezest, ha minden vdev-je nagyobb mereture cserelodik es az alapkoncepciot az egesz mogott.
[ Szerkesztve ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
válasz
stopperos
#71
üzenetére
Igen, de az új pool-t már 2-esen hoztam létre és simán rsync-el húztam át mindent a régirôl.
Volt olyan, hogy a HDD-k eladogatása miatt a fontosabb adatokat tartalmazó régi mirror-om egylábas volt a migráció alatt, a kevésbé fontos (de azért fàjt volna) raidz1-em pedig 2 meghajtós degraded.
Mindenféle trükköt összevissza kipróbáltam és makulátlanul túléltek az adatok, nagyon jó volt kicsit belemélyedni.
Az új pool v2-es, a régieket upgrade-elte pár mp. alatt, de végül úgyis destroy-oltam ôket, amint a 3. 8T-s hdd is befutott és e diszkessé vált, a régi diszkek meg kaptak bizt. kedvéért egy telibe dd-t.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
-
Dißnäëß
veterán
Szia, raidz1 esetén nem lehet.
A VDEV-ek száma (eltekintve a cache, log, stb-ktől) fix raidz1-2 esetén.Itt csak úgy tudsz nőni, ha egyesével cseréled őket nagyobbra, és mikor az utolsó nagyobb eszköz is bekerült, akkor felnöveli a ZFS a pool méretét (legalábbis default beállításban, de szerintem Freenas ezt így hagyta).
Mirror-nál megy csak.
[ Szerkesztve ]
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
(Pont most NAS-ozgatok btrfs-el, esetleg arról is írhatnál egy "pillanatfelvétel" / snapshot jellegűt, hogy hol tart ma) 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
lo Az otthon tárolt adatmennyiség növekedése miatt szükségessé válhat saját NAS, melyhez kiváló a ZFS fájlrendszer.
- Elemlámpa, zseblámpa
- Windows 11
- Witcher topik
- Kínai, és egyéb olcsó órák topikja
- YouTube
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Yettel topik
- Suzuki topik
- Autós topik látogatók beszélgetős, offolós topikja
- További aktív témák...
- Seasonic Focus GX 850 Gold - 10év papíros garanciával, újszerű állapotban, dobozában!
- GIGABYTE RTX 3070 GAMING OC 8GB GDDR6 SAMSUNG OC 256bits eladó!
- Asus VivoBook PRO - 14" 2.8k OLED / i5-11300H / 16Gb DDR4 / 512Gb NVME / RTX 3050 / HUN / 1.45 kg
- Alphacool Eisbaer LT360 vízhűtés
- O-K-G gép I5 7.generációs eladó, ajándék Logitech G102 Lightsync gaming egér és RGB gaming billentyű