Sziasztok, használ valaki Dell S130 kontrollert ZFS-el? Igazából tapasztalatokra lennék kíváncsi, neten nem sok dolgot találtam róla, dokumentáció alapán úgy sejtem használható gond nélkül vele, de fixme. Dell R630-al szemezgetek, SATA SSD-vel használnám RAID1-ben.
Van itt egy cikk a HUP-on (2020 április 15-i lent balra )a WD red-ekről. Idáig azt sem tudtam hogy létezik ilyen, hogy SMR hdd.
Ha igaz amit írnak, akkor az új WD RED (WDx0EFAX sorozat) nem jó RAID-be, pedig idáig kifejezetten ajánlott volt.
Többen is arről számolnak be, hogy raid újraépítés közben kidobja a lemezeket, annyira lelassúl. Ha jól értem ezekben a lemezekben
van hagyományos és SMR-es terület, pihenő időben átpakol a hagyományosról az SMR -területre. Terhelésnél erre nincs ideje, nagyon belassul,
rebuild megszakad.
Van erről valami tapasztalat ?
A Proxmox alatt egy ZFS van, ami RAID0-be van (kísérleti cuccnak jó és kell a hely).
Az egész sztori a múlt héten kezdődött, amikor volt egy linux frissítés. Másnap ez a mail fogadott a szervertől:
The number of I/O errors associated with a ZFS device exceeded
acceptable levels. ZFS has marked the device as faulted.
impact: Fault tolerance of the pool may be compromised.
eid: 21
class: statechange
state: FAULTED
host: pve
time: 2020-02-07 16:18:12+0100
vpath: /dev/sdc1
vphys: pci-0000:00:1f.2-ata-4
vguid: 0x51FA9E4D76A3E72E
devid: ata-WDC_WD20EARX-00PASB0_WD-WCAZAC153095-part1
pool: 0xC8E728B9CD2A9090A merevlemez eltűnt a linux alól, még a blkid se látta. restart után ismét megjelent, és egy resilver után, minden ment tovább, minden hiba és adatvesztés nélkül.
ZFS has finished a resilver:
eid: 11
class: resilver_finish
host: pve
time: 2020-02-07 17:10:56+0100
pool: omv_data
state: ONLINE
scan: resilvered 16.4G in 0 days 00:05:21 with 0 errors on Fri Feb 7 17:10:56 2020
config:
NAME STATE READ WRITE CKSUM
omv_data ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sdc ONLINE 0 0 0
sdb ONLINE 0 0 0
errors: No known data errors
A S.M.A.R.T. semmilyen hibát nem talál, látszólag minden rendben.
Ma délelőtt ismét eltűnt a merevlemez. A múlt héthez képest annyi a különbség, hogy most kicseréltem az adatkábelt, majd ismét resilver és minden megy tovább.
Mivel a Raid 0 nem hibatűrő, viszont az adatok, a mentések szerint intaktak, továbbá a S.M.A.R.T. nem dob hibát, én úgy gondolom, nem a merevlemez a ludas, de érdekelne, kinek, mi a véleménye!
Nem éles, kísérleti/home rendszer, tehát némi, max. 1 napos kiesés simán elfogadható, ennyi idő alatt a mentésből pótolhatóak az adatok, ezért marad a RAID 0, továbbá a gép se bír el több merevlemezt. Amíg a Proxmox alatti tűzfal megy, senki se panaszkodik.
https://www.realworldtech.com/forum/?threadid=189711&curpostid=189841
Nekem alajában semmi bajom nem volt soha Linus Torvaldssal, de nem igazán kedveltem sose valamiért. De ez alapján a vélemény alapján értem, miért nem szeretik (finoman fogalmazva) oly sokan.
A téma arról szól, hogy valami friss kernel változás töri a ZFS on Linux-ot. Erre Linus reakciója:
Hát, én nem tudom. Az Oracle dolgot megértem, jogos. De az, hogy sok-sok fejlesztővel rendelkező, élő, működő, fejlődő, tömegek által használt szoftver megáll, és ennyire nem érdekli, és semennyire sem konstruktív...
Az ilyen írások miatt érzem olykor azt, hogy hiába a sok milliós fejlesztői és felhasználói bázis, hiába open source jóformán az egész Linux világ, egyetlen idióta kezében van mégis minden, és rajta áll vagy bukik... Ez akkor is gáz, ha történetesen az Ő találmánya/munkája az alap rendszer.
Nem flame-et szeretnék nyitni, nagyon nincs rálátásom az ilyen témákra, csak ez megragadta a figyemem, mert én speciel szeretem és használom a ZFS-t (FreeBSD és Linux alatt egyaránt).
Sziasztok!
Adott egy otthoni szerver, amin proxmox fut. Az adatokat ZFS-en tárolom. A ZFS alatt két 1,5 TB-os merevlemez van RAID0-ban.
A szerverben 14 GB RAM van jelenleg, ebből a ZFS elvisz ~8 GB-ot. A szerverre maximum 10 felhasználó csatlakozik.
Arra gondoltam, teszek a merevlemezek mellé egy 240GB-os SSD-t, az SLOG, ZIL és/vagy az l2arc számára.
Szerintetek, hogyan lenne érdemes méretezni a cache-t?
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