A wikire mehet majd, jöhetnek az ötletek:
pro:
• COW (Copy-On-Write) azt írja a lemezre amit oda írni akartál, garantált adat integritás (ez egy nagyon érdekes olvasmány https://indico.cern.ch/event/518392/contributions/2195790/attachments/1…)
• az fsck-t el lehet felejteni
• három kulcsfontosságú tárolási réteg (RAID, logikai kötetkezelés és fájlrendszer) egyetlen entitásba csomagolása, amelyet így könnyebben lehet kezelni, egyszerű az adminisztráció
• gyors és hatékony tömörítés
• korrekt pillanatkép, mivel a ZFS ismeri a fájlokat, és ő csinálja a pillanatképet ezért a pillanatkép nem „vág ész nélkül ketté semmit” egy LVM például semmit sem tud a rajta levő fájlrendszerről ezért a pillanatkép a visszaállításnál okozhat problémát
• a pillanatkép nem lassítja a rendszert
• hordozhatóság (nem kell ugyan olyan RAID kontroller ha hordozni kell)
• natív titkosítás
• scrub, nincs „silent corruption” vagy más néven "bit rot"
kontra:
• érteni kell hozzá
• nagy a memóriaigénye
• nem lehet dinamikusan újrakonfigurálni egy meglevő raid vedev-et, azaz nem lehet egy lemezt hozzáadni közvetlenül ez RAIDZ (tömbhöz) vdev-hez, de ez a funkció fejlesztés alatt áll, rövidesen elérhető lesz
Hozzászólások
pro:
ZFS
con:
ZFS
-------------------------
Hivatásos pitiáner
neut @
pro: ZOL (Linuxon is elérhető és stabil pedig nem erre írták eredetileg)
kontra: ZOL (a licencelés és ebből eredő irgalmatlan szopások)
Tényleg a CDDL :(
Mihez képest? Például amit leírtál azt a Linux kernelben levő Btrfs is tudja.
Még én is keresem, hogy a 4.19 és újabb kernelben lévőnek milyen korlátai, hibái lehetnek.
Csak általánosságban, ez nem összehasonlító lista. Olyat is tervezek majd.
A btrfs még mindig nem javallott raid5/6-hoz.
RAID5/6 mellett sajnos nem tud a BTRFS natív titkosítást se, az pl. nekem nagyon hiányzik is.
>a 4.19 és újabb kernelben lévőnek milyen korlátai, hibái lehetnek.
Hivatalosan csak a RAID, nem hivatalosan azért még mindig bele lehet szaladni kellemes fallosz porszívózásba. Most pl. azzal szívok, hogy egy 3TB-s lemezt csak 2TB-snek lát. Lövésem sincs miért, nem az a gond, hogy teleallokálja (BTRFS betegség), a btrfs balance nem is segít emiatt.
De volt már olyan szívásom is, amikor a btrfs send/receive tört el rejtélyes módon, csak úgy tudtam átküldeni a subvolumet ha fogtam és a tartalmát egy új subvolumeba másoltam "hagyományosan" (nesze neked inkrementális backup).
Vagy olyan (igaz ez több éve már), amikor adathibás lett egy lemezem, és vissza akartam nyerni róla fájlokat, amikről épp nem volt (még) backup, de csak a legsötétebb fekete mágiával és rengeteg kézi vacakolással lehetett bármit is csinálni, mivel a dedikált eszközök nem mentek (mount -o recovery,ro), vagy segfaulttal elszálltak (btrfs check --repair).
2 TB korlát MBR-ben van, tuti GPT táblája van?
Ez volt az első gondolatom nekem is, de nem. Bár szerintem akkor 2TiB-nél nagyobb fájlrendszert se lehetne létrehozni rá.
Nem is 2TiB-nél telik meg pontosan, hanem 2,1x TiB-nél valahol. A btrfs fi usage kiírja, hogy még van 600 giga unallocated free space, de a fájlrendszer ugat, hogy ez bizony már tele van, ha írnék rá.
If your device is large...
https://btrfs.wiki.kernel.org/index.php/FAQ
Vagy elfogytak az inode-ok?
A pro tulajdonságok közül én hiányolnám a checksumming-ot. Igaz a scrub-al kapcsolatban utaltál rá, de nem csak scrub esetén jön jól. Például raidbe fogott lemezek esetén egészen új szintre viszi az adatintegritást. Olvasáskor mindig ellenőrzi a checksum-okat is. Ha hibás adatot olvas automatikusan javítja a hibásan olvasott adatot.
A kontra részben én a "nagy memóriaigény" helyett valami olyanra finomítanám, hogy "a megfeleő teljesítményhez sok memóriára van szüksége". Sejtem, hogy már unod az ilyen irányú kekeckedésemet, de azért mondom, mert már többször is találkoztam olyan szakmabeli emberrel, aki az otthoni nas célból beállított kis gépére azért nem rakott ZFS-t mert elriasztotta az az információ, hogy sok ramra van szüksége. Végül felpakolt egy ext4-et... Lehet hogy sokan teljes megelégedéssel használtak volna adott esetben 4Gb ram-al ZFS-t ilyen célra, és boldogan használták volna a "pro" rész összes lehetőségét az otthoni képekre, zenékre, családi videókra stb.
A checksumming az első pontot gondoltam, de igazad van aki nem ismer a COW rendszerek, annak lehet, hogy nem fog átjönni. Bővítem, meg a memóriás részt is finomítom, mert tényleg nem az elijesztés a cél :)
Gyakori tévhit, hogy a ZFS-hez "rengeteg memória kell". Első körben elmondható róla, hogy ez egy nagyvállalati körülményekre és igényekre tervezett rendszer. Elmegy kis mennyiségű adathoz (<=2TB) 8GB-tal is, ami ma talán nem számít komoly követelménynek - feltéve, hogy nincs szükséged deduplikációra, mert az a feature valóban sok memóriát eszik. Tervezni természetesen minden esetben kell, illetve konfigurálni is, mert nagyon nem mindegy a use-case és nagyon sok lehetőség van a filerendszer viselkedését és működését befolyásolni. Én deduplikáció nélkül használom SLOG és L2ARC mellett, mert csak 8 gigabyte memória van a gépben, amit leginkább általános célú NAS-ként veszek igénybe. A mindenkori ARC méret 3-5 GB. Úgynevezett hybrid pool a felállás: két merevlemez alkot benne egy kétutas tükröt, és 2 SSD szolgál gyorsítótárként, utóbbiak - az ajánlásokkal kényszerűségből szembemenve - elosztva: a log device tükrözve, a cache device csíkozva. A hálózat egy 2Gb-es LACP aggregation. A szűk keresztmetszet esetemben a processzor, mert a tömörítésnek van egy magától értetődő overhead-je. Nem szoktam benchmark-olgatni, de ez a HP N36L mosolyogva tudja azt, amire nekem szükségem van, és alig kér cserébe bármit is. :)
Tudnál valami linket dinamikus újrakonfigurálósról mutatni. Pár éve még az volt mondás, hogy soha sem lesz..
https://twitter.com/OpenZFS/status/921042446275944448
HW RAID kártyánál vagy MD/LVM esetében van arra lehetőség (úgy általában, nem egy-egy kivételes esetben), hogy meglévő kötetet átalakítson/bővítsen/szűkítsen a user?
Nem tudom egyáltalán, sose volt ilyenre szükségem, azért kérdezem.
Mert ha nincs, akkor nem igazán értem, miért van ez a kontrában. Ha semmi sem tudja, akkor inkább hiányosság (mindnél), mint ellene szóló dolog.
LVM tud ilyet, a tobbi nem hiszem.
Lvm-nel lehet vg-hez plusz diszket adni es az alapjan novelni lv-ket, vagy ha pv-t novelsz (virtualis gep vagy raid van alatta pl) akkor azt szinten lehet kezelni.
Sw raid eseten is van lehetoseg plusz diszk hozzaadasra
HW raid eseten leginkabb csak akkor ha van cache memoria es battery is hozza, kulonben letiltja raid vezerlo, de persze meg ott is gyarto valogatja engedi-e es milyen megkotesekkel.
A csokkentes mar sokkal macerasabb altalaban, azt erdemesebb elkerulni inkabb.
Azt tudtam, hogy egy VG-hez lehet PV-ket adni (sőt, ez a lényege általában az LVM használatnak), de a kérdés itt az, hogy RAID tömböt át lehet-e konfigurálni. Tehát egy 3 lemezes RAID5-höz lehet plusz egy lemezt adni, vagy egy 5 lemezes RAID5-öt lehet RAID6-ra alakítani, stb.?
Mert VDEV-et növelni ZFS-nél is lehet (az összes diszket ki kell cserélni egyesével nagyobbra, és ha megvan, rendelkezésre fog állni a növelt terült; fordítva nem működik), de a VDEV struktúráját nem lehet átalakítani (lemez darabszámot vagy szervezést változtatni).
Igen lehet, két hete csináltam pont egy Synology-n 10 lemez-ből lett 12. 52 órán keresztül futott. Ezt meg szokták jegyezni, hogy sokáig tart az átszervezés, és közben egy hiba elég és boríthatja a bilit. Ettől függetlenül szerintem nagyon hasznos funkció, egy OpenZFS screencast-ban az egyik fejlesztő mondta, hogy a ZFS-ben a leginkább igényelt funció "evör" :)
Azt tudtam, hogy egy VG-hez lehet PV-ket adni (sőt, ez a lényege általában az LVM használatnak), de a kérdés itt az, hogy RAID tömböt át lehet-e konfigurálni. Tehát egy 3 lemezes RAID5-höz lehet plusz egy lemezt adni, vagy egy 5 lemezes RAID5-öt lehet RAID6-ra alakítani, stb.?
Lehet. --grow az mdmadmnak.