Keresés: - [Re:] OpenZFS a mindennapokra

Hirdetés

Legfrissebb anyagok

LOGOUT témák

PROHARDVER! témák

Mobilarena témák

IT café témák

GAMEPOD témák

Keresés

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

Dißnäëß nagyúr

#147 2025-01-09 09:46:11

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

Dißnäëß

nagyúr

Nnnna, jön a kánaán OpenZFS-re a 2.3-as szériával: RAIDZ expansion.
Dißnäëß nagyúr

#100
#97 stopperos
2022-06-18 23:06:58

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

Dißnäëß

nagyúr

#97 stopperos

Mekkora sebességnövekedés nagy fájlos pool-on a recordsize növelés ? Szignifikáns, vagy "csak kicsit jobb" ?
Dißnäëß nagyúr

#75
#74 loki7903
2021-04-14 11:07:49

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

Dißnäëß

nagyúr

#74 loki7903

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.
Dißnäëß nagyúr

#73
#72 Dißnäëß
2021-04-08 10:32:20

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

Dißnäëß

nagyúr

#72 Dißnäëß

* diszkessé vált = resilvered, újra egészséges lett a pool.
Valamit nagyon félreírt a telóm..
Dißnäëß nagyúr

#72
#71 stopperos
2021-04-08 09:56:16

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

Dißnäëß

nagyúr

#71 stopperos

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.
Dißnäëß nagyúr

#70
#69 stopperos
2021-04-08 07:22:17

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

Dißnäëß

nagyúr

#69 stopperos

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.
Dißnäëß nagyúr

#68 2020-12-09 20:00:43

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

Dißnäëß

nagyúr

Kijött a ZFS On Linux 2.0, ami egyben át is neveződött OpenZFS-re, és forrás repo-t illetően összeolvadt a FreeBSD-s ZFS-el. [link]
Dißnäëß nagyúr

#67
#66 Dißnäëß
2020-11-21 21:04:46

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

Dißnäëß

nagyúr

#66 Diß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ön
Nincs több kérdés, kiváló.
Dißnäëß nagyúr

#66 2020-11-17 09:29:06

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

Dißnäëß

nagyúr

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).
Dißnäëß nagyúr

#62 2020-03-02 10:53:28

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

Dißnäëß

nagyúr

Ha esetleg más is olvassa a topic-ot, egy érdekes sebesség és zfs "raid" konfigurációs stat 4TB-s diszkekkel: [link]
Dißnäëß nagyúr

#61
#60 stopperos
2020-03-02 10:34:29

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

Dißnäëß

nagyúr

#60 stopperos

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).
Dißnäëß nagyúr

#59
#58 stopperos
2020-03-02 09:51:39

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

Dißnäëß

nagyúr

#58 stopperos

É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.
Dißnäëß nagyúr

#57 2020-03-01 11:54:39

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

Dißnäëß

nagyúr

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).
Dißnäëß nagyúr

#56
#55 stopperos
2020-02-27 21:42:31

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

Dißnäëß

nagyúr

#55 stopperos

Aaa tényleg, ez a fa rendszer. Olvastam, rémlik. Értem. Tisza.
Dißnäëß nagyúr

#54 2020-02-27 19:03:01

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

Dißnäëß

nagyúr

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ők
A 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).
Dißnäëß nagyúr

#53
#52 stopperos
2020-02-27 15:33:51

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

Dißnäëß

nagyúr

#52 stopperos

Ezt is jó tudni. Jól benne vagy már a témában Köszi a tippeket, hála.
Dißnäëß nagyúr

#51 2020-02-27 15:19:11

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

Dißnäëß

nagyúr

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 ?
Dißnäëß nagyúr

#50
#49 stopperos
2020-02-27 15:14:27

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

Dißnäëß

nagyúr

#49 stopperos
Dißnäëß nagyúr

#48
#47 stopperos
2020-02-27 14:25:20

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

Dißnäëß

nagyúr

#47 stopperos

É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).
Dißnäëß nagyúr

#46 2020-02-27 11:20:48

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

Dißnäëß

nagyúr

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).
Dißnäëß nagyúr

#45
#44 stopperos
2020-02-27 09:27:38

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

Dißnäëß

nagyúr

#44 stopperos

Ú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).
Dißnäëß nagyúr

#43 2020-02-26 21:08:32

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

Dißnäëß

nagyúr

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.
Dißnäëß nagyúr

#42 2020-02-26 20:33:28

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

Dißnäëß

nagyúr

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 ?
Dißnäëß nagyúr

#41
#37 stopperos
2020-02-26 20:31:23

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

Dißnäëß

nagyúr

#37 stopperos

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
Dißnäëß nagyúr

#40
#39 stopperos
2020-01-07 15:20:17

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

Dißnäëß

nagyúr

#39 stopperos

É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.
Dißnäëß nagyúr

#38
#37 stopperos
2020-01-07 08:38:28

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

Dißnäëß

nagyúr

#37 stopperos

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.
Dißnäëß nagyúr

#36 2020-01-06 21:16:54

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

Dißnäëß

nagyúr

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.
Dißnäëß nagyúr

#35
#34 Kendek
2020-01-06 18:01:44

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

Dißnäëß

nagyúr

#34 Kendek
Dißnäëß nagyúr

#33 2020-01-06 15:58:03

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

Dißnäëß

nagyúr

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).
Dißnäëß nagyúr

#9 2019-12-09 12:57:03

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

Dißnäëß

nagyúr

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.