Beleolvastam, nem mindet olvastam el, de gratulálok, na az ilyen cikkek eléggé hiányoznak már innen, amikor tényleg kidolgozod a cikk témáját.
Az pedig, hogy nem mentél bele a ZFS-be annyira, nem is baj azzal legalább kettő ilyen cikket ki lehetne tölteni, csak azzal hogyan működik.
Mindenesetre, szuper, el fogom olvasni, köszi a munkádat.

The further a society drifts from truth, the more it will hate those that speak it. (George Orwell) [Work Machines: HP EliteBook, HP ProBook & Linux Mint 20 ; Entertainment: Apple Macbook AIR M1]

7zip archív helyett esetleg egy veracrypt kötetbe tenni a titkosított headert?
pro-kontra? A 7zip-re nincsen már valami törés, vagy backdoor?

Köszi, örülök, hogy tetszett. Ez csak 1 út a sokból, kinél hogy néz ki a rendszer ugye, lehet ezt tényleg még jobban tekergetni, de nagyjából így kerek.

Ma még mindig ott tartok, hogy 24 karakteres kézi jelszóval oldom fel az USB pendrive boot-ját Grub után, mikor bootol a linux, ez feloldja az SSD-n lévő LUKS titkosított gyökét partíciót, folytatódik a boot folyamat, feloldódik a 3 HDD és él a rendszer.

Múlt héten scrub-oltam (sacc. kéthavonta scrub-olok egyet), szokásos 0 error.

Teszi a dolgát a konfig, én pedig nyugodtabban alszom.

Nemsokára költözök végre jobb környékre, de ez már így marad

Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá

Lehet van rá törés, nem is tudom.. a semminél több.

Veracrypt jogos, sőt.. régen a Truecrypt-el játszottam el hasonlót, Windows alatt anno. A cégből mentett adataim mai napig TC konténerben, Veracrypt feloldja persze. Jó ötlet.

Amúgy ha tényleg így betörő/lopás ellen akarom védeni a motyót (adatokat), igen pici az esélye, hogy az email fiókom akarná header fájlokért törni, úgy, hogy ez kis túlzással szinte lehetetlen egy security-heavy cégnél és termékeinél, ahol az adatokhoz még ők sem férnek hozzá (és én ezt elhiszem nekik. Nekik igen)... szóval akár kódolatlan zipben is lehetne a header és key fájl, ha most azt nézzük, mi ellen csináljuk meg ezt a kicsit nyakatekert, de annyira nem is vészes setup-ot.

Amúgy nagyon poén, amikor a pendrive-ot kihúzom, minden előjel nélkül bootol SSD-ről Windows-ba (Starcraft-ozok jókat néha), nyitom a lemezkezelőt és azonnal dobja fel, mindhárom HDD-mre, hogy ezeken semmi nincs, de még partíciós tábla sem, kreáljon-e.

Na ilyenkor kell vigyázni és - nyilván - ezt elutasítani.

Szóval aki ezt a gépet vitte, vasnak, az anyagilag egész jól jár, de amúgy jó eséllyel arra sem jön rá, hogy a 3 diszk adott esetben értelmes adattal szinte tele, nemhogy nekiálljon küzdeni vele, kb. Mission Impossible. A védelem legelső frontvonala maga a megtévesztés.

Lehetne fokozni hogy USB-be dugható M.2 SSD-t használok boot mellett gyökérre is, na akkor végképp nem rakná össze egy avatatlan szem a dolgot, hogy értelmes adat lehet egyáltalán a 3 diszken. Lát egy legális Windows-t, 1-2 legális játékot és 3db "üres" HDD-t.

Következő irományom elosztott fájlrendszer lesz, Gluster (zfs-el kombinálva).

Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá

Ez parádés !

Össze kellett kaparni, mire mindent felhomályosítottam magamban....

"Mindent"

szrk:
mint valami ördöglakat

[ Szerkesztve ]

"Biztos mint a halál! Sóhaj, Szobaasszony, Fárosz.. 2, 9, 11. " Ha a kacsa nem tud úszni, nem a víz a hülye "

Nézz utána, de ha leveszed windowson belül a betüjelét a lemezeknek, amiket neki nem kéne látnia, akkor nem fog pop-up-olni, hogy nincs semmi számára érthető rajtuk

[ Szerkesztve ]

// #ublockO-HardMode // anti-blockadblock-er // PH! új arculat: 1/ 500 // szeksziboj -nálam van egy pirospontod! // Találtam sárga fényű lézert! (kézit, ceruzaelemest) https://youtu.be/XQnmMjYHgcM //

Nem sokat nyitom már meg a lemezkezelőt, de köszi a tippet. Ha ismét.. rápróbálok.

Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá

Hát figy, működik. ZFS-nél szokták mondani, hogy direktben kell neki odaadni a drive-ot, hogy "lássa" annak paramétereit, talán még SMART-ot is, nem tudom.. passz. Erről nem szoktam leállni vitázni másokkal.

Én azt tudom, hogy megoszlik a szakma véleménye, stackoverflow-tól kezdve mindenhol csak azt látom, hogy rengetegen évek óta simán ráteszik teljes lemeztitkosítás esetén a LUKS által kreált virtuális rétegre a ZFS-t és azt tekinti VDEV-nek. Szerintem zseniális. Ha bit flip történne fizikailag legalsó rétegben, az beolvasáskor szar LUKS szektort eredményezne, a szar LUKS szektor pedig lényegében egy "bad sector"-ként jelentkezik a /dev/mapper-ben lévő feloldott virtuális eszközön, azt meg lekezeli ZFS, mert ráírja a jó adatot (ha tudja, mert nem súlyos fizikai hiba), ez a jó adat pedig ugyanígy a jó titkosított kóddal, jó szektorként újra kiíródik lentebb, így a fizikai rétegre ráíródik ugyanaz az értelmetlen random adat, ami eredetileg is ott volt, csak flippelődött egy bit. Nem nagy kunszt, tehát még a self-healing is működik, titkosítás mellett is, mindaddig, míg a másik meghajtó pöpec és az ott lévő adat + 2 db checksum alapján el tudja dönteni, melyik adat ténylegesen a jó. 2- vagy többtagú mirror, raidz1, raidz2, raidz3 esetén is ez a jótékony tulajdonság adott.

A RAW fájljaim már amúgy nem tudom, hanyadjára költöznek , elsőként 0.x-es alapverzióként kezdte mindenem 3db 2T-s WD Green-en.

( )

Aztán mikor elhullott egy, meg mégegy (később), letettem erről, a green sem ajánlott NAS célra, meg a nonstop fejparkoltatás anno, ahh, itt volt 1-2 nyűg ezekkel. Ezután jöttek a 4T-s Seagate NAS-ok + WD Purple + WD Red, 6 diszk összesen, végül - most is ezeken élek - 3x 8T Seagate Ironwolf (NAS). Mindig úgy bővítettem a poolt diszkenként, hogy betettem az új HDD-t, LUKS-al belőttem, majd az így /dev/mapper -ben létrejött eszközt adtam be neki, a régi HDD-t "replace"-elve. Mikor a 3. HDD cseréje is lement, az autoexpand=on miatt a pool méretem automatikusan felugrott a bővített méretre.

Ha lenne pincém, ahol nem zavar a kicsit nagyobb géphang, valószínűleg kreálnék raizd2 típusú pool-t úgy 6-8 db HDD-vel aztán jónapot. A sebesség nem téma.

Cache, SLOG továbbra sincs, minek. Csak a szinkron írásokat gyorsítja, média tartalomra felesleges - nekem legalábbis, adatbázist pedig nem futtatok, VM-eket sem, a pool-on..

[ 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áááá

Több helyen nagyon tudálékos és nagyképűen (leginkább önteteltséget sugárzó) megfogalmazott leírás. A világmegváltó tudatzavarral bíró tinik fogalmaznak így. Ha nagyon fiatal vagy elnézhető. Vagy ha szakmailag elismertséget szerzett nagy ember vagy elnézhető.

De így nem lehet elismerni semmilyen szakmai tudást. Bocs.

[ Szerkesztve ]

Gondolkodj globálisan és tegyél lokálisan!

Bocs, Te milyet írtál?

The further a society drifts from truth, the more it will hate those that speak it. (George Orwell) [Work Machines: HP EliteBook, HP ProBook & Linux Mint 20 ; Entertainment: Apple Macbook AIR M1]

Nézd, a stílus maga az ember, de egy szakmai cikket lehet olvasni hasznos és haszontalan módon is...

Földszinti lakás, rács nélkül és nem biztonsági ajtó. Valószínűleg túlreagálom, jó a környék, van külső lépcsőházajtó is, de az ördög sosem alszik. Így döntöttem a teljes gép full titkosítása mellett - egy nem szokványos módszerrel megfűszerezve.

Meglehetősen. A kutyát nem fogja érdekelni a lakásod

I'm gangsta!

Gratulálok.
Esetleg annyi javaslat, hogy a beütött parancsokat emeld ki új bekezdésbe monospace vagy programkóddal, hogy jobban kiemelkedjenek.
"- LUKS2-zz titkosításkor (cryptsetup luksFormat --type luks2 ...)"
Helyett:
- LUKS2-zz titkosításkor:
$ cryptsetup luksFormat --type luks2 /dev/ESZKÖZ

A zpool remove raidz esetén nem működik, valamint csak top level vdev-et lehet eltávolítani: van egy 2x2 mirror pool-od és az egyik mirror vdev-et ki akarod venni. Ekkor az azon lévő adatokat átírja a bennmaradó mirror-re és egy mappingot hoz létre a régi adathely és az új adathely között. Egy ilyen furcsa állapotban lesz a pool, de ahogy az adatok frissülnek úgy a mapping tábla mérete is szép lassan a 0 felé fog tartani.

"What is Linux? I only joined because of the the penguin..." - meanwhile in the linux community. http://9gag.com/gag/arpZGOy

Es a cikk ala odakopsz egy olyan kommentet ami tokeletesen megfelel a leirasodnak, vegtelenul arrogans okoskodas

[ Szerkesztve ]

Köszi !

Azóta annyi változott, hogy átmigrálódtam 4x14T Seagate Exos SAS vinyóra (raidz1 továbbra is, lehet bővítek +2 diszkkel és akkor raidz2, csak hova teszem ezt a millió adatot, még fejvakarós, bár csak fele van még tele), .. jött egy alkalmi vétel. Alapvetően továbbra is favorit a motyó, 400-550 Mb/sec körül írogat-olvasgat kevés seek mellett, mikor milyenje van, bőven kielégítő nekem.

Samba-val volt kissé nyűg összehozni, sőt, nagyon nagy nyűg.. de ha jól emlékszem, az lett a megoldás, hogy a Linux saját SMB stack-jét használtam és a pool-on zfs-en pedig offoltam.

Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá

Linuxon a saját sambát kell használni.
A trükk, amit keresel, hogy 2 új lemezt raid0-ba rakod. Arra felmásolsz mindent (zfs send | zfs recv), és bízol benne, hogy a scrub nem dob hibát. A felszabaduló 4 lemezből csinálsz egy raidz2-t, de úgy hogy még két 13T méretűre allokált fájlt hozzáadsz. Itt nincs foglalás, Amikor létrejön, akkor azonnal offline-ba rakod a két fájlt, hogy ne kezdjen rá írni. Visszamásolsz mindent, majd a 2 fájlt kicseréled a raid0 lemezeire.
Legalább 2 helyen lehet adatveszés, de ez az egy lehetőség van ha nincs több lemezed.

"What is Linux? I only joined because of the the penguin..." - meanwhile in the linux community. http://9gag.com/gag/arpZGOy

Igen, ez necces menet lesz. Kösz a tippet, vad dolog, de kivitelezhetô. Még alszom rá egyet. Ha bukik a dolog, nagy a rizikó. Esetleg vmi kölcsön diszk vagy nem tudom, majd kifaggatom cimbiket.

Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá

Említetted h Linuxon ?
Mi a másik még ? BSD ? Mert látom, Windows-ra is megy a portolás, de arról semmi infóm igazából, lehet be van késve rendesen..

Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá

FreeBSD-re működik a zfsből a samba. Windows nincs még kész, ne is várj rá. Hamarabb lesz mac-re.

"What is Linux? I only joined because of the the penguin..." - meanwhile in the linux community. http://9gag.com/gag/arpZGOy

Illetve szeretném ezt a 4 diszkes pool-t kicsit szofisztikálni majd, alátenni 2-3 SSD-t, caching, log, nem is tudom, mivel lenne érdemes kiterjeszteni úgy, hogy

1. az is konzisztens legyen, ha kell (tehát mirror)

2. a pool az adatokat a 4 HDD-vel is megôrizze, ha az összes SSD-t leveszem róla, úgy is.

3. Gyorsuljon (nyilván), nem feltétlen szekvenciálisban, hanem sok kb. 50-100 megás fájl ráírása-visszaolvasása esetén. (Fényképezôgép raw-k, írja az Explorer, olvassa az Adobe Bridge az elônézetikhez, de lehet maradok 4 HDD-vel így nyersben és a teljes képkidolgozási folyamatot abszolválom elôtte az SSD-ken, aztán ha már nem molyolok velük, áttolom a NAS-ra).

3.1 Könyvtárbeolvasás. Minden start/reboot után ha belépek a fotós mappámba, tele könyvtárakkal, úgy recseg és tölt az egész, hogy pislogok.. eltelik 2-4 hosszú mp, mire felnyalja az alkönyvtárakat és mutatja ôket az Intézô. Utána már villám (RAM cache).

Egy elképzelésem már van fejben, még finomodik..

[ 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áááá

Gondolom nagy TBW tûrésû SSD lenne ideális alá, Pro-s Samu, vagy valami Enterprise célra szánt ekvivalens. Auto garbage coll. már fejlett ma, mondjuk a ZFS CoW nem eszi ôket durván, de ezek cache/log lennének, az megint más felhasználás.

Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá