ZFS Fan Club

Sziasztok.

Lehetséges (send/receive nélkül) egy nem zfs fájlrendszerre átmásolni a snapshot állapotát mindenféle zfs függőség nélkül?
Az működhet esetleg, hogy  a `.zfs/snapshot/1111_daily_2019-12-15_23:00:00` konyvtárat rsync-el átmásolom?
Vagy olyankor bekavarhat az esetleges következő snapshot?

Tudom, hogy sokak szerint ördögtől való dolog, de érdekel, hogy megvalósítható-e vagy csinált-e valaki hasonlót.
 

Sziasztok!

Most, hogy az Ubuntu belerakta a ZFS támogatást a desktop telepítőbe gondoltam kipróbálom a saját notimon. A gép egy Dell Latitude E7450, 8GB RAM, Samsung PM851 SSD.

A telepítés nagyon egyszerű, a particionálásnál kirakja a telepítő a ZFS-t, amin semmit sem lehet állítani, kiválasztod és mehet is. Next-next-finish kész. A végeredmény valahogy így néz ki:

sda 8:0 0 238,5G 0 disk

├─sda1 8:1 0 50M 0 part /boot/grub
├─sda2 8:2 0 1K 0 part
├─sda5 8:5 0 2G 0 part [SWAP]
├─sda6 8:6 0 2G 0 part
└─sda7 8:7 0 234,4G 0 part

NAME USED AVAIL REFER MOUNTPOINT

bpool 133M 1,62G 176K /boot
bpool/BOOT 132M 1,62G 176K none
bpool/BOOT/ubuntu_rxmhgy 132M 1,62G 132M /boot
rpool 106G 121G 96K /
rpool/ROOT 49,8G 121G 96K none
rpool/ROOT/ubuntu_rxmhgy 49,8G 121G 4,16G /
rpool/ROOT/ubuntu_rxmhgy/srv 96K 121G 96K /srv
rpool/ROOT/ubuntu_rxmhgy/usr 200K 121G 96K /usr
rpool/ROOT/ubuntu_rxmhgy/usr/local 104K 121G 104K /usr/local
rpool/ROOT/ubuntu_rxmhgy/var 45,6G 121G 96K /var
rpool/ROOT/ubuntu_rxmhgy/var/games 96K 121G 96K /var/games
rpool/ROOT/ubuntu_rxmhgy/var/lib 45,6G 121G 867M /var/lib
rpool/ROOT/ubuntu_rxmhgy/var/lib/AccountServices 96K 121G 96K /var/lib/AccountServices
rpool/ROOT/ubuntu_rxmhgy/var/lib/NetworkManager 160K 121G 160K /var/lib/NetworkManager
rpool/ROOT/ubuntu_rxmhgy/var/lib/apt 73,4M 121G 73,4M /var/lib/apt
rpool/ROOT/ubuntu_rxmhgy/var/lib/dpkg 42,7M 121G 42,7M /var/lib/dpkg
rpool/ROOT/ubuntu_rxmhgy/var/log 7,12M 121G 7,12M /var/log
rpool/ROOT/ubuntu_rxmhgy/var/mail 96K 121G 96K /var/mail
rpool/ROOT/ubuntu_rxmhgy/var/snap 128K 121G 128K /var/snap
rpool/ROOT/ubuntu_rxmhgy/var/spool 192K 121G 192K /var/spool
rpool/ROOT/ubuntu_rxmhgy/var/www 96K 121G 96K /var/www
rpool/USERDATA 56,2G 121G 96K /
rpool/USERDATA/user_vaedoy 56,2G 121G 23,8G /home/user
rpool/USERDATA/root_vaedoy 212K 121G 212K /root

Érdekes, hogy a boot-nak külön partíciót csinált és nem reservation-al oldotta meg. A dataset nevekbe meg belerakott random karaktereket, gondolom azért ha valamiért egy másik gépen kell importálni, ne akadjon össze.

Ezeket a progikat muszáj használnom munka közben: terminal, openVPN, Firefox, Thunderbird, Chromium, Remmina, AnyDesk, NoMachine, LibreOffice, Seafile client, KeepassXC, VeraCrypt, VirtMAnager (kvm,qemu), Gimp, Inkscape.

Kezdem a rossz hírrel, a Seafile kliens nem működik jól. Amikor egy mappát helybe kéne szinkronizálnia „segfault” hibával leáll. Szerencsémre ez nekem nem kritikus, az amit szinkronizálnom kell, megoldom a kliensben kézi feltöltögetéssel, nem kényelmes, de ez legalább megy. Nem tudom, hogy a 19.10 az oka vagy a ZFS, most jelentem a Seafile fórumra. Már jártam így régebben, ott nem a ZFS volt az ok, hanem a túl új Ubuntu, ráadásul a 19.10 jelenleg nem is támogatott a Seafile részéről. Meglátom mit mondanak.

Jó hí, hogy az összes többi program simán megy, úgy hogy a programok egy része snap telepítős.

Titkosítás:

A Xubuntu előtt egy VeraCrypt konténerben voltak a munkával kapcsolatos bizalmas dolgaim. Mivel a ZFS tud natív titkosítást gondoltam átállok arra. Még nem volt szükségem rá, most használom először. Nem csalódtam a ZFS fejlesztőkben, a titkosítás kezelése ennél nem is lehetne egyszerűbb. Így kell létrehozni titkosított dataset-et:

zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt -o mountpoint=/home/user/titkosmappa rpool/USERDATA/user_vaedoy/titok

Ezután bekér egy jelszót és ennyi. Restart után természetesen nem csatolódik fel a dataset, ez látszik a zfs listában:

NAME   MOUNTPOINT   MOUNTED  ENCRYPTION   KEYSTATUS   KEYLOCATION
rpool/USERDATA/user_vaedoy/titok   /home/user/enc   no    aes-256-ccm    unavailable    prompt

A használatba vétele ZFS-esen bonyolult :)

zfs mount -l rpool/USERDATA/user_vaedoy/titok

Jelszóbekérés és kész. Persze lehetne kulcsfájlt is használni, de nekem ez így teljesen jó.

Ha megnézzük látszik, hogy felcsatolódott, meg persze a tartalom is előkerül:

NAME   MOUNTPOINT   MOUNTED   ENCRYPTION    KEYSTATUS    KEYLOCATION
rpool/USERDATA/user_vaedoy/titok    /home/user/enc   yes   aes-256-ccm    available prompt

Ezen fellelkesedve a Remmina egész snap mappáját titkosítottam és nem kell küzdenem linkelésekkel. Működik.

Teljesítmény:

A szubjektív érzet az, hogy gyors. Azt nem írtam eddig, hogy az előző OS amit használtam Ubuntu 18.04 volt Gnome-al. Tudom, tudom, de nekem bejött, kivéve a 4 GB memória használatot nulla program elindításánál, de volt elég RAM a gépemben. Mivel a ZFS is szereti a memóriát ezért lett Xubuntu az Xfce-vel, hogy amit ott spórolok memóriával az mehet a ZFS-nek.

Hát röviden annyi, hogy már nem annyira szerem a Gnome-ot. Az Xfce ZFS-el érzetre sokkal gyorsabb, mint a Gnome ext4-el. De nem kicsit. A kezelése meg hihetetlenül hatékony és egyszerű, nem is értem miért nem használtam. A gép az elindulás után szűk 1GB RAM-ot használ. A ZFS arc beállítása alapértelmezett 50% így nagyjából 4-5 GB között áll meg erős lemez terheléssel. Mint a Gnome egymaga…

Csináltam pár fio írás tesztet. Kíváncsiságból összehasonlítottam a ZFS titkosítását a VeraCrypt konténerrel. Hozta amit vártam tőle.

Normál mappa:

WRITE: bw=557MiB/s (584MB/s), io=1024MiB (1074MB), run=1839-1839msec
WRITE: bw=268MiB/s (281MB/s), io=5120MiB (5369MB), run=19108-19108msec

ZFS encrypted mappa:

WRITE: bw=327MiB/s (343MB/s), io=1024MiB (1074MB), run=3132-3132msec
WRITE: bw=138MiB/s (144MB/s), io=5120MiB (5369MB), run=37160-37160msec

VeraCrypt konténer normál mappában:

WRITE: bw=123MiB/s (128MB/s), io=1024MiB (1074MB), run=8358-8358msec
WRITE: bw=60.7MiB/s (63.7MB/s), io=5120MiB (5369MB), run=84313-84313msec

A munka miatt van egy kvm virtualizált Win 10 a gépemen, aminek 2GB ramot adtam és a qcow2 lemez fájlt async módban használom. A teljes memória használat így belefért a 8 GB-ba. A Win 10 alatt egy helyben 5 GB fájlmásolás sebessége elérte a 80 MB/s-t ami nagyon jó. A futtatott Windows sebessége kifejezetten gyors.

A memória fogyasztás elfogadható, annál kisebb mint amit vártam. Itt éppen hétféle program fut a gépemen (a Win10 nem), több nyitott Libre doski, Firefox 10+ tab-al stb:

total used free shared buff/cache available

Mem: 7,6Gi 4,5Gi 2,6Gi 219Mi 587Mi 2,7Gi

Összegzés:

Annak ellenére, hogy sok helyen használok szerveren ZFS-t a kliens gépemen nem volt az. Most, hogy az Ubuntu szerint életképes a dolog rászántam magam a kipróbálására. Az első benyomásom az, hogy teljesen jól használható. Szűk egy hete dolgozom a notival és semmilyen gondom nem volt, a sebessége érzetre kiváló, a 8GB RAM pedig elég, ebben nyilván szerepe van az Xfce-nak is. A ZFS használata extrém könnyű, rengeteg variálásra ad módot a titkosítás, az akár mappánkénti syn-async beállítás, stb.

Ha ez egy magazin lenne akkor kapna egy „Ajánlott” plecsnit.

Sziasztok!

Szolgálati közlemény, már van zfsfanclub.hu

Jó lenne egy adatbázis amiben hardver mérési eredmények lennének. Ha valaki lesz olyan kedves, hogy mér annak kéne valami "standard", hogy össze tudjuk hasonlítani az eredményeket.

Nekem a fio jön be írási tesztre, de tőlem lehet más is, ha van ötlet. Viszont az olvasás tesztelésnél nagyon nagy szórást mértem a fio-val, oda vagy más kéne, vagy hangolni kell a beállítását.

Ha összerakjuk írhatnánk esetleg egy script-et ami magától összerakja.

Alapból ezek az infók kellenek: alaplap típusa, kontroller típusa, lemezek fajtája.

Egy pool status.

zpool status poolname

Dataset rekordméret és sync beállítás.

zfs get compression,recordsize,sync poolname/datasetname

Írási teszt:

fio --name=test --filename=testfile --size=[$size] --direct=[$mode] --bs=[$bs] --iodepth=16 --rw=randwrite

bs=4K, 64K, 128K, 1M
mode= sync, async
size=500M, 1G, 5G, 10G, 30G

Az eredmény valami ilyen:

--- bs=4K ---
sync size=100M-> write: IOPS=19.1k, BW=74.7MiB/s (78.3MB/s)(100MiB/1339msec)
async size=100M-> write: IOPS=125k, BW=490MiB/s (514MB/s) (100MiB/204msec)
sync size=200M-> write: IOPS=19.3k, BW=75.4MiB/s (79.1MB/s)(200MiB/2652msec)
async size=200M-> write: IOPS=158k, BW=615MiB/s (645MB/s) (200MiB/325msec)
sync size=500M-> write: IOPS=19.0k, BW=74.2MiB/s (77.8MB/s)(500MiB/6736msec)
async size=500M-> write: IOPS=161k, BW=627MiB/s (658MB/s) (500MiB/797msec)
sync size=1G -> write: IOPS=18.7k, BW=73.1MiB/s (76.6MB/s)(1024MiB/14016msec)
async size=1G -> write: IOPS=174k, BW=680MiB/s (713MB/s) (1024MiB/1505msec)
sync size=5G -> write: IOPS=947, BW=3790KiB/s (3881kB/s)(2097MiB/566539msec)
async size=5G -> write: IOPS=114k, BW=446MiB/s (468MB/s) (5120MiB/11478msec)

--- bs=64K ---
sync size=100M-> write: IOPS=8839, BW=552MiB/s (579MB/s) (100MiB/181msec)
async size=100M-> write: IOPS=12.9k, BW=806MiB/s (846MB/s) (100MiB/124msec)
sync size=200M-> write: IOPS=10.7k, BW=669MiB/s (701MB/s) (200MiB/299msec)
async size=200M-> write: IOPS=10.7k, BW=669MiB/s (701MB/s) (200MiB/299msec)
sync size=500M-> write: IOPS=12.4k, BW=775MiB/s (813MB/s) (500MiB/645msec)
async size=500M-> write: IOPS=11.1k, BW=694MiB/s (728MB/s) (500MiB/720msec)
sync size=1G -> write: IOPS=12.4k, BW=775MiB/s (812MB/s) (1024MiB/1322msec)
async size=1G -> write: IOPS=13.5k, BW=841MiB/s (882MB/s) (1024MiB/1217msec)
sync size=5G -> write: IOPS=1155, BW=72.2MiB/s (75.7MB/s)(5120MiB/70910msec)
async size=5G -> write: IOPS=8479, BW=530MiB/s (556MB/s) (5120MiB/9661msec)
sync size=10G -> write: IOPS=736, BW=46.1MiB/s (48.3MB/s)(10.0GiB/222351msec)
async size=10G -> write: IOPS=7292, BW=456MiB/s (478MB/s) (10.0GiB/22466msec)

--- bs=128K ---
sync size=500M-> write: IOPS=9389, BW=1174MiB/s (1231MB/s)(500MiB/426msec)
async size=500M-> write: IOPS=8350, BW=1044MiB/s (1095MB/s)(500MiB/479msec)
sync size=1G -> write: IOPS=9102, BW=1138MiB/s (1193MB/s)(1024MiB/900msec)
async size=1G -> write: IOPS=6330, BW=791MiB/s (830MB/s) (1024MiB/1294msec)
sync size=5G -> write: IOPS=789, BW=98.7MiB/s (103MB/s) (5120MiB/51887msec)
async size=5G -> write: IOPS=4345, BW=543MiB/s (570MB/s) (5120MiB/9426msec)
sync size=10G -> write: IOPS=572, BW=71.6MiB/s (75.1MB/s)(10.0GiB/143066msec)
async size=10G -> write: IOPS=3894, BW=487MiB/s (510MB/s) (10.0GiB/21036msec)
sync size=20G -> write: IOPS=490, BW=61.3MiB/s (64.3MB/s)(9293MiB/151556msec)
async size=20G -> write: IOPS=3272, BW=409MiB/s (429MB/s) (20.0GiB/50073msec)
sync size=30G -> write: IOPS=789, BW=98.7MiB/s (103MB/s) (2742MiB/27789msec)
async size=30G -> write: IOPS=2228, BW=279MiB/s (292MB/s) (30.0GiB/110283msec)

--- bs=1M ---
sync size=500M-> write: IOPS=2083, BW=2083MiB/s (2185MB/s) (500MiB/240msec)
async size=500M-> write: IOPS=988, BW=988MiB/s (1036MB/s) (500MiB/506msec)
sync size=1G -> write: IOPS=1906, BW=1907MiB/s (2000MB/s) (1024MiB/537msec)
async size=1G -> write: IOPS=843, BW=843MiB/s (884MB/s) (1024MiB/1214msec)
sync size=5G -> write: IOPS=412, BW=412MiB/s (432MB/s) (5120MiB/12416msec)
async size=5G -> write: IOPS=547, BW=548MiB/s (574MB/s) (5120MiB/9348msec)
sync size=10G -> write: IOPS=253, BW=254MiB/s (266MB/s) (10.0GiB/40362msec)
async size=10G -> write: IOPS=747, BW=748MiB/s (784MB/s) (10.0GiB/13695msec)
sync size=20G -> write: IOPS=206, BW=207MiB/s (217MB/s) (11.2GiB/55602msec)
async size=20G -> write: IOPS=782, BW=783MiB/s (821MB/s) (20.0GiB/26163msec)
sync size=30G -> write: IOPS=231, BW=232MiB/s (243MB/s) (5858MiB/25300msec)
async size=30G -> write: IOPS=639, BW=640MiB/s (671MB/s) (30.0GiB/48015msec)

kene nekem siman backup tarolasra valami tarolo. a feltetelek:

- legalabb 1PB hasznalhato hely
- 100Gbit/s-et tudjuk koppantani par (10-20) streammel

kerestem friss infokat, de sehol nem talaltam sebesseget ekkora tombokre. meg lehet ezt ZoL-lal csinalni?

Sziasztok!

Ha valaki tudja a megoldást, kérem írja meg!

Át kellett méreteznek az egyik ZFS subvolume-ot. Az eredeti méret 1800G volt.

zfs set volsize=1000G omv_data/subvol-107-disk-0

Az SSH-n mindenhol jó méretet ír az összes ZFS lekérdezés, az lxc konténerben is 1000G a méret, de a proxmox GUI-ban továbbra is az 1800G van a Storage->Content táblázatban.

A jelenlegi álláspont szerint az 1800G-s köteten most a GUI szerint van egy 1800 és egy 600G-s subvolume.

A zfs, viszont, list ezt íja:
NAME USED AVAIL REFER MOUNTPOINT
omv_data 822G 976G 96K /omv_data
omv_data/subvol-100-disk-0 108G 492G 108G /omv_data/subvol-100-disk-0
omv_data/subvol-107-disk-0 715G 285G 715G /omv_data/subvol-107-disk-0

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

Sziasztok!

Egy ilyen nekem az elején rengeteget segített volna. A célja elsősorban a ZFS-el ismerkedők eligazítása, illetve a kezdeti lépések segítése. Én írtam a saját tapasztalatimból, illetve a fórumon tárgyaltakból. Ha van még ötlet jöhet, illetve a meglevő pontokra is mehet kritika. Ha hozzáírtok vegyétek figyelembe, hogy olyanoknak íródik akik nem ismerik a ZFS-t. Ez majd kimegy a mediawiki-re.

1. A ZFS nem az n+1-ik fájlrendszer, sokkal több annál, ezért ne is úgy gondolj rá!
A ZFS egy ultramodern rendszer, ami nagyon más mint amit eddig megszoktál. Sajnos egy pár dogot újra kell tanulni miatta, de cserébe itt egy lista, hogy egymaga miket cserél le, ha elkezded használni: hw raid szoftverek, md, lvm, fájlrendszerek (ext3, ext4, xfs, stb.), mkfs, fsck, fstab, dd...

2. Soha de soha ne használj hardver RAID-et ZFS-hez, se bármilyen más szoftver RAID rendszer
Tilos a ZFS alá bármilyen RAID rendszert tenni! A ZFS egy teljes önálló rendszer a disk-re írástól a RAID-en át a fájlrendszerig, nincs szükség alá semmilyen egyéb rendszerre, hardver raid-re meg pláne.

3. A ZFS gyors működéséhez három dolog kell, RAM, RAM és még több RAM
A leggyakoribb probléma a ZFS-el az elégtelen memória méret. Vagy nézz utána mire és mennyi memória kell a ZFS-nek, vagy használd ezt, 4GB éppen elég, 8GB szódával elmegy, 16GB-tól alakul. Ez persze a többi (rendszer, alkalmazások, stb.) memóriafogyasztás felett számítandó!

4. A deduplikáció memóriaigénye, tuti nem hitted volna, de nagy. 4-5GB RAM / 1 TB disk (blocks * 320 bytes) A disk olcsó(bb) ha nem muszáj ne küzdj vele.
A deduplikáció memóriaigénye a többi (pl. ARC) memórián felül számolandó, ezen kívül CPU is kell neki. Nem biztos, hogy megéri az extra teljesítmény és memória ráfordítást, ha megoldható helyette több disk-el, számolj utána.

5. Használj SSD (S)LOG disk-et
Az SLOG lemez használata ez egyik módszer amivel gyorsítani lehet a ZFS írási sebességét. Vagy mégsem, mert csak a sync írást gyorsítja. Járj utána mikor, mire jó és mire nem. Ha nem tudod mi a különbség a ZIL, SLOG, sync és async írás között, ne csodálkozz, ha nem az lesz az eredmény mint amire számítottál.

6. Ha tudsz, inkább használj az CACHE (L2ARC) disk helyett RAM-ot.
A CACHE disk használata nem csodaszer és lehet, hogy semmit nem fog gyorsulni a rendszered tőle, viszont van amikor igen. Értsd meg, számolj, tesztelj.

7. Sok kicsi sokra megy 3 x 10 != 12 x 1
Amivel jelentősen növelhető a teljesítmény az a sok lemez. Ha akarsz például 10TB területet 2 paritás lemezzel akkor sokkal-sokkal jobb a 3x10TB helyett a 7x2TB lemez és még annál is jobb a 12x1TB.

8. Egy POOL kihasználtsága legyen 70% (80%-90%) alatt.
Ez nem csak a ZFS-re igaz, hanem minden fájlrendszerre. Több mindentől függ mikor kezd lassulni, de 70%-kal nem lősz mellé.

Hali!

A ZFS Fan Club dolgait (tutoriualok, mérési eredmények, stb.) tarthatnák egy mediawiki-ben. A hup-on au meg fog szűnni ezért néztem az ingyeneseket, de még egyet sem használtam. Van valakinek jó (vagy rossz) tapasztalata valamelyik szolgáltatóval?

Üdv mindenkinek!

Felmerült ggallo kollégával, hogy a ZFS kedvelőknek szerveznénk egy csoportot/közösséget. Ha van érdeklődés majd kitaláljuk hogyan. Lehetne benne szerver tapasztaltok, ajánlott lemezek, beállítások, tuning trükkök, "tankönyv", tutorial írások, stb. Még angolul is nehéz normális infókat szerezni, nem, hogy magyarul.
Jó lenne pl. egy egyszerű "adatbázis" valahogy, akár egy megosztott excel, ahol gyűjthetnénk az elért legjobb teljesítményt a gépeken amiket használunk, adott beállításokkal. Mindjárt első téma lehet a teljesítmény mérés, hogy ugyan azzal a programmal, módszerrel mérjünk. Ilyesmi. Szóval ha valakit érdekel jelezze itt.