Jó lett, színvonalas, és érthető 
üzenetek
hozzászólások
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 ]
OddMan
(őstag)
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 ]
OddMan
(őstag)
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 ]
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).
MasterMark
(titán)
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.
Ez szerintem eléggé off topic. A ZFS azért van, hogy a lemezkezelést egyszerűsítse és lehetővé tegye az adatbiztonságot. Természetesen be lehet ékelni a fizikai lemez és a zpool közé több réteget. De ezek túlmutatnak a mindennapi felhasználáson, amiről a cikk szól.
É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.
