- Magga: PLEX: multimédia az egész lakásban
- Wiz Khalifa: Grand Theft Auto VI - Érdekességek, látványosságok, képek, infók egy helyen.
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Gurulunk, WAZE?!
- gban: Ingyen kellene, de tegnapra
- eBay-es kütyük kis pénzért
- Ismerkedés a Zyxel NSA325 v2-vel
Új hozzászólás Aktív témák
-
Dißnäëß
nagyúr
Nnnna, jön a kánaán OpenZFS-re a 2.3-as szériával: RAIDZ expansion.
-
-
Betoltam az új lemezt.
Pillanatnyilag ezt látom:
A nem használt lemezeknél megjelent az új, eddig egy volt ott, ami szerintem a lehalt diszk.
Innen hogyan tovább?A kezdő hozzászólásnál az egyik képen van replace, a vörössel jelzett lemeznél, de nekem ott az a problémám, hogy ugyan az a lemez alatta is szerepel mégegyszer.
-
-
stopperos
senior tag
Szia, kb ennyi mint amit írsz.
Buktató annyi lehet hogy a Toshiba mérete kisebb és nem tudod becsatolni. (Ha van swap a lemezeken, akkor ok).
Ha van szabad sata port, akkor le sem kell állítani a gépet. Amikor rádugod felismeri, és mehet is a zpool replace.Ha van még kérdésed, akkor tedd fel. Holnap jobban tudok reagálni napközben.
-
Tanácsot, segítséget szeretnék kérni.
A helyzet az, hogy a pool-om egyik meghajtója meghalt.
Ha jól látom, akkor a sda meghajtó esett ki.
A lemezek sas csatolos 3 TB-s Seageteek, nagyjából egy koruak, szoval elkezdhetem a lemezek cseréjét.
Az elképzelésem a következő:
A jelenleg kiesett lemez helyére be tudok rakni e Toshiba P300 3 TB sata lemezt. Ez nem lesz gond, legalábbis remélem.
A folyamatot így képzeltem el.
A gépet leállítom, a hibás lemezt kicserélem a jóra, újra idítom és a TrueNAs grafikus felületén hozzáadom az új lemezt a pool-hoz.
Ennyi lenne az egész, vagy lehet valami buktató a történetbe?
Gondolkodtam a mentésen is, pont van annyi tárhely, de akkor fel kéne használnom a csere lemezt is....
Ha van javaslat, azt megköszönném. -
válasz
stopperos
#135
üzenetére
Találtam egy megoldást. Nem hiszem, hogy veszélytelen lett volna, de úgy néz ki sikerült:
You need to stop all the services on the box that could be writing to the directories affected.
Then you need to move the directories out of the way. mv /var /var.old
Now force zfs to mount the directories: zfs mount -a For each directory affected, copy the old files over the new rsync -avz --delete /var.old/* /var/
Cross your fingers (press your thumbs, or whatever culturally appropriate gesture fits)
RebootNem állítottam le egyetlen service-t sem. Kimentettem a tartalmakat. Kitöröltem mindent a 3 mappából. Rögtön kiadtam a mount parancsot. Ez akkor rendben lefutott. Aztán jött az upgrade. Lefutott hiba nélkül. Visszamásoltam a tartalmakat. Reboot.
Most megy.
Az eredeti megoldás azért nem ment, mert az apt rögtön teleírta a cache-t és a log-ot. -
-
-
-
A lekérdezésnél ez volt:
arcstat
time read ddread ddh% dmread dmh% pread ph% size c avail
17:39:42 0 0 0 0 0 0 0 24G 24G 631M
1 x RAIDZ1 | 6 wide | 2.73 TiBÉn egy kicsit túlzásnak tarom a 24 G-t. Volt egy ZFS fríssítés, addig a lemezmérettel egyező foglalása volt.
És van egy ilyen szabály:
Szerintem itt van a kutyus elásva.
-
xabolcs
őstag
OpenZFS alatt van arcstat meg zfs_arc_max.
TrueNAS SCALE alatt mi a helyzet?Most latom, ok is OpenZFS-sel dolgoznak.
Az elobbivel lekerdezni szoktam, az utobbival meg beallitom kenyemre-kedvemre az ARC meretet.
# arcstattime read ddread ddh% dmread dmh% pread ph% size c avail20:53:08 0 0 0 0 0 0 0 321M 320M 1005Msystemd.service reszlet:
[Service]ExecStart=/bin/bash -c 'echo $(( 320*1024*1024 )) | tee /sys/module/zfs/parameters/zfs_arc_max' -
Na adok egy kis lendületet a topiknak, hátha tud valaki segíteni.
Truenas scale alatt a zfs cashe a poll méretének kétszeresére hízott, és tartja magát.
A gond az, hogy bizinyos app-ok szeretnének RAM-ot a futáshoz, de nincs elég szabad memória, így nem működnek megfelelően.
Van valami beállítási lehetőség, hogy a ZFS cashe ne egyen többett mint a pool valós mérete? -
Nálam transmission van telepítve jailben, nekem simán /mnt/Seagate pool1/iocage/jails/Transmission/root/mnt utvonalra van mountolva, és a Transmission settings.json fájljában adtam meg letöltési helynek.
Így a letöltés a jail-en kívűl van és gond nélkül elérem a wines gépekről.
Egyszer kipróbáltam a qbittorrentet is és gond nélkül migráltam a két rendszer között, ott is ezeket a beállításokat használtam, de visszatértem a transmission-hoz, azt már megszoktam. -
bigrob
őstag
Újrahúztam a torrentet is.
Sikerült kiszedni a jailből:
Source:
/mnt/HDD/media/DownloadsDestination:
/mnt/HDD/iocage/jails/qbittorrent/root/mediatorrent ui-n a Default save path:
/mediaEddig is így volt amúgy, de nem működött...
Most SMB alól tudok cut-pastelni, de ftp alól nem, esetleg erre tipp?
-
-
bigrob
őstag
válasz
stopperos
#116
üzenetére
Időközben a Plexet újraraktam, úgyhogy az legalább ismét életre kelt...
Van egy novemberi snapshotom, abban nem vagyok biztos hogy az a jogokat is visszaállítja-e, illetve ha visszaállítom akkor törli az esetlegesen azóta letöltött dolgaimat?
Holnap megnézem ezt a külön datasetet a qbittorrentnek, nekem sem tetszik hogy a saját iocagebe menti, de hogy őszinte legyek segghülye vagyok ehhez..
Addig is köszönöm szépen a segítséget!
-
stopperos
senior tag
Ebben a konkrét dologban én nem tudok segíteni. Amelyik FreeNAS/TrueNAS rendszert én raktam össze és működtettem, ahhoz már nincs hozzáférésem. Illetve jail kezelésben nem merültem el olyan mélyen. Csak mezei freebsd jail-eket futtattam wordpress-nek és nextcloud-nak, nem konkrét telepíthető alkalmazás jail-eket. De azért van pár gondolatom:
0) A helyes megoldás esetedre az lett volna, ha csinálsz egy külön dataset-et, pl datapool/shares/Downloads. Jail esetén van lehetőség mount point-ot megadni, és akkor ezt a mappát (Source) be lehet csatolni az adott jail megfelelő mappájába (Destination). A samba share jogosultságokat pedig csak erre az új datapool/shares/Downloads dataset-re állítod be a Windows Shares oldalon.
Ez a mappát ugyancsak fel tudod csatolni a Plex jail megfelelő elérési útjába hasonló módon.
Igazából az a cél, hogy külön kell választani az alkalmazást és az adatokat. Az alkalmazásra, ami a datapool/iocage/qbittorrent dataset-en van pedig beállítani egy snapshot task-ot, hogy ha gáz van, akkor vissza tudj állni egy korábbi állapotra.1) Mivel nincs pillanatképed (snapshot), ha jól értettem, az iocage-es datasetről, ezért kézzel kellene javítani a dolgokat. De ezt nem javaslom, illetve nem szokás belepiszkálni a docker/iocage belsejébe ha az egy csomag. Ez egy jószág, nem házi kedvenc. Ha a gond van vele, akkor le kell lőni. Jobban jársz, ha törlöd az egyes alkalmazásokat és a hozzájuk tartozó dataset-et, és előröl kezded.
2) Ha már ennyire romokban van az iocage/jail rendszer, akkor szerintem még jobban jársz, ha áttérsz TrueNAS Scale-re (linux) és docker alapon felteszed újra az alkalmazásokat. A megfelelő csatolássa. Megpróbálsz tiszta lappal indítani. Frissítésnél ki tudod választani, hogy át akarsz menni másik TrueNAS ágra. A régi rendszer is megmarad, ha mégsem válna be, a Boot menüben vissza tudsz állni.
-
bigrob
őstag
Sziasztok!
Nem tudom mennyire járok jó helyen, de egy kis segítséget szeretnék kérni Truenas-sal kapcsolatban.
Rászántam magam, hogy SMB-t bekapcsoljam és sima windows intéző alól is el tudjam érni a kis drágát.
Minden sikerült, annyi nem ment hogy kivágás-beillesztésre hibát dobott, elkezdtem turkálni a pool permissionök közt és addig jutottam amíg már nem látom a torrent letöltések mappámat...
Ha megpróbálom beírni ami eddig működött akkor az alábbi hibát kapom diagnosztizálás után:
A felhasználói fiók nem rendelkezik hozzáfrési engedéllyet a következő fájhoz... \\IP\HDD\iocage\jails\qbittorrent\root\Downloads\
Valami ötlet, hogy mit sikerült elnyomkodnom, illetve hogyan tudnám diagnosztizálni?
Magát a root mappát látom, de benne nem látom a Downloads mappát...Illetve ha az alap problémámra is tudtok megoldást azt is szívesen fogadom, FTP-n sem tudok kivág-beilleszteni, mindig a saját gépemen keresztül tudtam másolni a letöltések mappából a Plex média mappájába.
Köszönöm szépen!
Update: sikerült a Plexet is megölni, nem érem el belső IP-ről és app.plex.tv-ről sem.......
Valahogy tudok korábbi biztonsági mentést visszarakni ha nem mentettem?
-
compression=lz4
zfs csatolja
A /etc/logrotate.conf:cat /etc/logrotate.conf# see "man logrotate" for details# rotate log files weeklyweekly# use the adm group by default, since this is the owning group# of /var/log/syslog.su root adm# keep 4 weeks worth of backlogsrotate 4# create new (empty) log files after rotating old onescreate# use date as a suffix of the rotated file#dateext# uncomment this if you want your log files compressed#compress# packages drop log rotation information into this directoryinclude /etc/logrotate.dA konkrét konfig az /etc/logrotate.d/-ben:
/var/log/mosquitto/mosquitto.log {rotate 7dailycompresssize 100knocreatemissingokpostrotateif invoke-rc.d mosquitto status > /dev/null 2>&1; then \invoke-rc.d mosquitto reload > /dev/null 2>&1; \fi;endscript}Utánaolvastam, de semmi furát sem találok bennük. -
stopperos
senior tag
Szia, ez szerintem nem zfs probléma elsősorban. Ha a fájl ki van írva, akkor az ki van írva a lemezre. Melyik és milyen a tömörítés a logfájlos dataset-en? fstab vagy zfs csatolja fel az adott mappát?
Én a /etc/logrotate.conf fájlban és /etc/logrotate.d/ mappában nézném meg az adott logfájlra vonatkozó beállításokat. Egy delaycompress és missingok sort adnék hozzá az adott logfájlra vonatkozó konfigurációs fájlhoz. Az rsyslog-hoz tartozóban látni fogod a megfelelő sorokat. -
Még egy kérdésem lenne:
Szabályos leállítás után már 3-szor volt, hogy egy-egy automatikusan indított program nem indult el. Nyomozás után kiderült, hogy a log vagy a temp-ben nem talál egy fájlt. (pl. mosquitto) És tényleg megvolt a két tömörített régi logfájl, de az "élő" az hiányzott. (mosquitto.log.1.gz megvolt, de a mosquitto.log nem)
Olyan mintha a zfs "eltüntetné" újraindítás esetén.
A zpool status 0b javítást ír.
Merre induljak el a hibakereséssel?
A mainpool két SSD mirror-0-ban. -
Otthoni szerver; Ubuntu 20.04.5 LTS (Focal Fossa); 8GB RAM; zfs; pár felhasználó.
MiB Mem : 7844.8 total, 146.1 free, 3654.1 used, 4044.6 buff/cache
MiB Swap: 4096.0 total, 3328.5 free, 767.5 used. 3891.2 avail MemMiért használ swap-et? A 16GB segítene, vagy ez normál működés és akárhány GB-ből használna swap-et?
-
KRM
csendes tag
válasz
stopperos
#103
üzenetére
Szia!
Kipróbáltam, nem ez lesz a megoldás. Annak a value számnak szerintem köze van a snapshot méretéhez, mert amikor elkészült a pillanatkép még 0 b volt a mérete és akkor még az értéke is 0 volt, de pár másodperc múlva felugrott valamennyire, általában ugyanakkora volt a mérete. 4 percre állítottam az automata kép készítést és pár pillanatkép után volt, hogy a mérete 0 volt, utána annyi mint általában és utána megnőtt valamennyivel megint, ha töröltem fájlokat, maradt az "általános" méretén.
Virtuális gépben próbálkozom még vele, megcsináltam egymás után háromszor, hogy töröltem a poolt és újra megcsináltam mindent és smb-vel megosztottam, először és másodszor 3 lemezes z1 poollal, utána 5 lemezes z1 poollal teszteltem, az utolsó két próbálkozásnál ugyanazokat a fájlokat másoltam rá, hogy lássam, milyen értékek lesznek, de mindegyik felállásnál más volt az alap mérete a snapshotnak.Lehet érdemes lenne a Qnap-os fórumban érdeklődni, hátha, aki Hero-t használ elő tudja valahogy kotorni, hogy működik ez? Igazából nincs szükségem rá, mert ha áttérek zfs-re nem fogok pl óránként pilanatképezni, de így már zavar, hogy nem jövök rá
mert hátha jó lesz még egyszer. -
stopperos
senior tag
Szia,
A te keresett zfs dataset tulajdonságod a "written". Ez azt mondja meg, hogy az utolsó pillanatkép óta mennyi adat lett írva. Szerintem szinte minden ezt használja, ha meg kell nézni, hogy van-e változás.Nálam ezt adja az openwrt build mappámra
$ sudo zfs get -p -r written vd-BlackKite/openwrt/22.03
NAME PROPERTY VALUE SOURCE
vd-BlackKite/openwrt/22.03 written 8192 -
vd-BlackKite/openwrt/22.03@init written 252956672 -
vd-BlackKite/openwrt/22.03@cloned written 9764864 -
vd-BlackKite/openwrt/22.03@feedsinstalled written 292626432 -
vd-BlackKite/openwrt/22.03@prebuild written 15548416 -
vd-BlackKite/openwrt/22.03@prebuild3 written 6184960 -A "p" flag a teljes értéket kiíratja, az "r" a rekurzió miatt kell. Ha egy "-o value" részt is adsz hozzá, akkor pedig csak azt az egy oszlopot írja ki.
Én egy bash script-et csinálnék, ami ezt az értéket ellenőrzi a fő dataset-en (nem az utolsó snapshot-on). Ha az érték nagyobb, mint 0, akkor pedig készít egy időbélyeggel ellátott pillanatképet. Ezt pedig crontab-ba tenném, hogy percenként fusson.
-
KRM
csendes tag
Sziasztok!
Én egy Openmediavaultot (és docker konténereket) használok a régi pc-men (újrahasznosítás céljából, amíg megy) 5*1TB Hdd-vel és egy ssd-n van a rendszer, egy sata bővítőre van egy 2TB-os lemez még dugva backup céllal és usb-n egy 2TB laptop vinyó szintén backup célból... Abszolut hobby projekt.Annyi lenne a kérdésem, hogy azt hogyan lehetne megoldani zfs-nél csak akkor és arról készüljön snapshot, amikor módosítva volt valami, vagy új fájl került rá?
Qts Hero-ban működik ez az opció, ami szintén valami linuxra épült, de sehol nem találtam róla semmi infót, hogy más rendszereken ez miként lenne megoldva. Pedig hasznos lehet, ha valahol sűrűn kell snapshotolni. -
stopperos
senior tag
A 128K és az 1M között alap esetben nincs nagy különbség nagy fájloknál. Az sebesség növekedés a nagyobb recordsize miatti tömörítési arány növekedéséből fakad, ha a fájlok jól tömöríthetőek lz4-gyel. A merevlemezekről kevesebbet kell olvasni, és memóriában zajlik a kitömörítés.
-
stopperos
senior tag
Nálam egy esetben Dell Perc i/6 raid vezérlő van a szerverben. Gyárilag nincs benne olyan mód, hogy csak a lemezeket adja át az OS-nek. Itt azt csináltam hogy lemezenként létrehoztam 1-1 raid0 meghajtót. Ezt a 6 darab raid0 meghajtót adtam oda a TrueNAS rendszernek.
Annyi probléma volt egyedül, hogy amikor az egyik lemez haldoklott, akkor csak annyit vettem észre hogy kb tizedére esett a raidz2 pool írási és olvasási sebessége, mert a háttérben küzdött a raid kártya, hogy kiolvassa a hibás szektorokat. Azpool statusviszont nem mutatott hibát. Csak a raid kártyából tudtam kiolvasni, hogy gond van, illetve a smartctl-ben látszódott valami.
A raid kártya elrejti a lemez réteget, és csak a read cache-t (nálam adaptive read-ahead) szabad engedélyezni. Semmilyen write cache-t. (Azt write-through -ra kell állítani).
Amúgy a poén, hogy azóta látom a /dev/pass0-5 néven az egyes lemezeket, mert a FreeBSD raid kártya drivere változhatott és hozzáfér direktbe a lemezekhez megkerülve a raid kártyát.tl;dr; Ha nincs write cache, akkor 1 lemez 1 raid0 tömb felállásban nem lesz semmi baj raid kártya esetén.
-
stopperos
senior tag
Pontosan, jól érted.
Két út van a te esetedben a bővítésre:
1) 5. lemeznek berakod az újat, és megmondod hogy zpool replace 'poolnév' 'régi-hdd' 'új-hdd'.Ha megvagy, akkor a régit kiveszed, és folytatod a következővel.
2) 4 lemezzel is meg lehet csinálni, csak akkor feszengenék, hogy biztos ne halljon meg közben lemez. Ennél is ugyanaz a parancs, csak a régi-hdd már nincs benne a rendszerben.* Ha igazán ügyes vagy, akkor leállítás nélkül meg tudod csinálni. Linux esetén van lehetőség a sata lemezeket leállítani és újra felismertetni (ha kell leírom ezt is). FreeBSD (TrueNAS) esetén nem tudom mi a helyzet általánosan, nekem a raid kártyás szerverben megvolt hozzá a parancslista.
* Amikor az utolsó 3 TB lemez is kikerül, akkor magától megnöveli a méretet. Ha nem akarná, akkor egyzpool onlinemég kellhet.
* Egy jótanács: tárhely bővítésnél a 2x-re kell menni legalább. Tehát 8TB-os lemezekre cseréld. -
-
válasz
stopperos
#83
üzenetére
Valami kisebb használt szerver gépben gondolkodom, ezekben jellemzően 4 lemez hely van, azért gondolkodtam raidz1-ben. 4x3 TB lemezből így lesz 9 TB használható területem, ez egy otthoni projekt, jelenleg 2 db 2 TB és egy 3 TB hdd-n szétszórva 6 TB adattal rendelkezem, ami ide kerülne.
-
stopperos
senior tag
A háttér gondolatmenet az amúgy, hogy raidz1-2-3 felállást egyszer raksz össze, mondjuk 5-10 merevlemezzel és utána már bővítésnek és változtatásnak helye nincs. Csak akkor lehet bővíteni, ha az összes lemezt kicseréled nagyobbra. Ezt illik azonos méretű lemezekből összerakni.
Ha rugalmasabb rendszert szeretnél akkor páronként mirror-be rakod a lemezeket és az egyes mirror párokat fűzöd össze amolyan raid10-nek megfelelő felállásba. Ebben az esetben páronként kell csak az azonos lemezméretre figyelni és páronként végezhető el a bővítés. Illetve a újabban van lehetőség mirror párt eltávolítani.
Az írási sebesség amúgy raid10 esetén gyorsabb, mint raidz1-2-3 esetén. Az olvasásnál nehéz megmondani hogy melyik a jobb választás. Létrehozáskor ashift=12 kell minden esetben. -
Remélem lesz, aki válaszol....
TrueNas telepítés elött állok.
Az lenne a kérdésem, hogy jól gondolom, hogyha a RaidZ1-be vegyes lemezeket rakok (pl. 2x2 TB és 2x3 TB), akkor a kisebb lemezek mérete fog számítani. Tehát ez esetben ez olyan lenne, mintha 4x2 TB lemez lenne összerakva. -
stopperos
senior tag
Szia, még nincs kész a raidZ1-2-3 bővítés funkció. 3 lehetőséged van:
1) Ahogy Dißnäëß is írta, veszel 4 új, nagyobb méretű hdd-t és kicseréled egyesével.
2) Lemásolsz mindent róla, és újra létrehozod 5 merevlemezzel. Majd mindent visszamásolsz.
3) 2 lemezt raksz a rendszerbe, de egy új mirror pool-t hozol létre.Nálam az egyetemen amikor bővíteni kellett, akkor az utóbbi lett: 6*2TB RaidZ2 és 2*8TB mirror 2 külön poolban.
-
Dißnäëß
nagyúr
Szia, raidz1 esetén nem lehet.
A VDEV-ek száma (eltekintve a cache, log, stb-ktől) fix raidz1-2 esetén.Itt csak úgy tudsz nőni, ha egyesével cseréled őket nagyobbra, és mikor az utolsó nagyobb eszköz is bekerült, akkor felnöveli a ZFS a pool méretét (legalábbis default beállításban, de szerintem Freenas ezt így hagyta).
Mirror-nál megy csak.
-
Dißnäëß
nagyúr
válasz
stopperos
#71
üzenetére
Igen, de az új pool-t már 2-esen hoztam létre és simán rsync-el húztam át mindent a régirôl.
Volt olyan, hogy a HDD-k eladogatása miatt a fontosabb adatokat tartalmazó régi mirror-om egylábas volt a migráció alatt, a kevésbé fontos (de azért fàjt volna) raidz1-em pedig 2 meghajtós degraded.
Mindenféle trükköt összevissza kipróbáltam és makulátlanul túléltek az adatok, nagyon jó volt kicsit belemélyedni.
Az új pool v2-es, a régieket upgrade-elte pár mp. alatt, de végül úgyis destroy-oltam ôket, amint a 3. 8T-s hdd is befutott és e diszkessé vált, a régi diszkek meg kaptak bizt. kedvéért egy telibe dd-t.
-
Dißnäëß
nagyúr
válasz
stopperos
#69
üzenetére
Szerintem ketten vagyunk összesen. Te utat törtél, én haladok a nyomdokaidban.
Gyakorlatilag a rendszeren (ext4) kívül mindenem zfs, most a 6db 4T-s HDD-m két pool-ját tettem egyetlen raidz1-esbe 3db 8T-sre (NAS jelleg, de desktop használat, Debian Testing).
Többször is nagyon merész dolgokat tettem, amit senkinek nem ajánlok, nekem kényszer volt kicsit, mint pl. egyesével kicserélni a korábbi raidz1 pool hdd-it egyesével, önmaga titkosított mására (offline-oltam, luks-al letitkositott verziojat a /dev/mapper-bol visszaadtam a pool-ba replace-el, resilvering lement es oke, utana ugyanez a masodikkal es vegul a harmadikkal is). Masodik korben mar a 8T-s luks titkositott NAS diszkekkel replace-elgettem egyenkent a meglevoket, az egeszet pedig crypttab-bol feloldja a rendszer, a root particio ker indulaskor kezi jelszot, minden mast boot folyamat soran elintez (luks2 4096 byte kulcs, header fajlok is az ssd-n a root konyvtarban, a hdd-ken nincs header).
Tudom, nem a legoptimalisabbnak tartott dolog a zfs ala barmit is tenni, de igazsag szerint volt mar pici hibam egy Purple-el, scrub alatt, ott is a titkositott layeren volt a zfs. Nyilvan ha bithiba van fizikai szinten feluleten, akkor a felette levo titkositasi blokk szinten hibas lesz, amit zfs ugyanugy erzekel es kijavit, ez is tortent.
A zfs encryption meg annyira nem jar ott, mint egy teljes diszk encryption header nelkul, de majd beerik ez is.
A Debian Testinget frissitve raneztem a zfs verziora es a 2.0-asat mutatja mar, mig a pool-ok meg 0.83-asok voltak (fejbol, ha jol emlekszem). Egyelore stabil a 2-es verzio, azt latom, minden ok.
Megelegedessel hasznalom a zfs-t, erdekes volt a slog-rol es az l2arc mukodeserol olvasni, meg finomhangolni a poolt itt-ott aprosagokkal, most a sebessege is mar elfogadhato.
Szeretem ezt az egyszeru kezelest, egyszeru (nalam default-automatikus) atmeretezest, ha minden vdev-je nagyobb mereture cserelodik es az alapkoncepciot az egesz mogott.
-
-
Dißnäëß
nagyúr
Kedves stopperos. Ismét Hozzád fordulok, hátha csináltál már ilyet.
(Jól el-privizünk itt, ennyire senki sem ZFS-ezik ? ) Van két pool-om, egy mirror (2x4TB) és egy raidz1 (4x4TB).
Kérdéseim lennének:
1. Át tudom őket valahogy alakítani további külső eszköz igénybevétele nélkül titkosított pool-okká ? Akár kockáztatva is a redundanciát (szóval diszkenként lépkedve).
2. ZFS titkosítás: elég erős, vagy látszanak még dolgok, meta, header, ilyesmik, mondjuk egy LUKS2-höz képest ? (Ahol a header-t ki lehet vinni külön eszközre, pl. usb-re és azzal feloldani mindent, ha pedig nincs header kéznél, random adat az egész egy ismeretlen számára).
Úgy döntöttem, az egész gépem titkosítanám, lopás ellen/miatt. Nem vagyok vmi jó környéken és mindig ettől "rettegek". Nem az eneszéjt kellene megállítanom, csak szimplán ha neadjisten elviszik a hónuk alatt a gépházat, ne tudjanak hozzáérni semmihez (max törölni, de külső backup van a legfontosabbakról).
Te hogy csinálnád ? (Látom, sokan LUKS2 dm-crypto eszközökkel alkotnak pool-okat, nem tudom, ez hogyan viselkedik adatintegritás szempontból a felsőbb ZFS szinten, vagy ha fizikai hiba van egy hordozón).
-
Dißnäëß
nagyúr
válasz
stopperos
#58
üzenetére
Értem. Arról van infód, mennyire stabil enterprise/vállalati környezetben a zfs ? Biztosan hülye kérdés, de lehet ezzel egy komoly, akár 50-100 diszkes storage farm-ot is építeni ? (Hardver adott). Gondolom, ha Solaris gyökerei vannak, kifejezetten jól zenél ilyen célra is, főleg adatbázis, analitika, ilyesmire lenne használva.. ezt már csak úgy féloff-ban kérdem.
-
Dißnäëß
nagyúr
Arrol mi a velemenyed, hogy a zfs titkositassal az adat ugyan vedve van, de a hdd-rol kiderithetik meg, hogy zfs titkositott adat van rajta, mig LUKS titkositott, header-t NEM tartalmazo HDD totalrandom adathalmaz... Igy emiatt LUKS kotetet szoktak tolni a paranoidok a zfs ala, es a zpool-ba a fizikai eszkoz helyett mar a logikai eszkozt adjak be.
Csak mert ezzel a megoldassal en is szemezek, a kerdes csak az, hogy a zfs oriasi elonye, az integritas ilyenkor hogyan valosul meg.
Pelda:
Tegyuk fel, mirrort szeretnek zfs-el. Titkositott hdd-kkel, legyen 2db. Mivel paranoid vagyok, usb-rol boot-olok (amit utana kiveszek a gepbol, ha mar fut, /boot-ot at-mount-olom elotte a feloldott HDD-re). Az usb-n van a detached header is, azaz a LUKS2 header, kulcs meg vagy a fejemben, vagy fajlban az is az usb-n, ez mar reszletkerdes.A HDD-ket tehat LUKS2-vel titkositom.
Lesz ket dm-encrypt akarmilyen nevu eszkozom (mapper talan, ha jol remlik korabbrol). Ez mar logikai szint.
Ha ezekkel hozom letre a zfs mirrort, fasza vagyok, mukodik a dolog.
Nade itt jon a kerdesem: ha a fizikai lemezen tortenik egy bit hiba, es nincs az korrigalva, a felette levo LUKS titkositasban kepes bizonyos szintig ezt kikorrigalni a rendszer ? Mert a fizikai bithiba a titkositas miatt azt az adott LUKS blokkot megoli ugy, ahogy van. Ez ki tudja, hany kilobyte, de a LUKS szint is azt fogja mondani, hogy az a blokk szar, titkositas nem oldja fel a beolvasott adatot, ergo nincs mit a mapper eszkoznek tovabbadnia.
Beall vmi hibaval a rendszer, vagy tovabbadja mint hibas szektort a mappernek a LUKS ?
Utobbi jo lenne, mert zfs lekezelne ezt a mirroros felallasban nativan. Mint hibas szektort, nem mint bit flip-et. Sima bit flip nem jutna el a zfs-ig bit flip-kent, hiszen az az 1 atfordult bit a titkositas miatt egy x kb-os titkositott blokk resze es miatta az egesz blokk feloldhatatlan elvileg, tehat zfs szamara mar egy egesz blokk hibaja latszil, ha LUKS tovabbadja ezt a fentebbi retegnek.
(Ha nem, lehet a LUKS is elhasal hibaval es cseszhetunk mindent).
Na ezekrol semmi infom, mert tok jo lenne am kombinalni az integritast a LUKS-al.
Van erre lehetoseg, a dm-integrity erre valo, es ha LUKS2 alatt ugy formazom a ket hdd-t, hogy --integrity, akkor tartalmazni fog ellenorzo adatot minden egyes LUKS2 titkositott blokk is. Az mas (es ez a baj!), hogy nem annyira szofisztikaltan tobb peldanyban, mint a zfs. Ergo, bithiba ellen ved egy dm-integrity alapu megoldas, de ha ott tobb szektor is szar, vele egyutt - mivel ugyanott a hiba teruleten van az ellenorzo is - az ellenorzo is eluszik, hibasodik, tehat cseszhetjuk.
A zfs ha tudna ugy titkositani, mint a LUKS2, nativan, hogy ember meg nem mondja, ott titkositott adat van (header kulon meghajton), az lenne az igazi, de ilyenre nem kepes meg.
A sima integrity-s linuxos megoldasok meg azt a fajta kreativ es okos logikat mellozik, ami a zfs alapmukodesere jellemzo.
Szoval ... szivas, jol latom ? (Ha bebizonyithatatlanul titkositani akarnek ket HDD-t, zfs mirrorkent).
-
stopperos
senior tag
Szia, ha nincs másolat nem tudja az adatot visszakalkulálni. Nem lehet tudni, hogy a sok közül melyik bit fordult át.
Az adathoz a metablokkban van az ellenőrző, egy metablokkról 2-3 másolat van. A metablokk ellenőrző is egy magasabb szintű metablokkban van, amit ugyanúgy 2-3 másolatban megvan, és így felfelé. Tehát az adat sérülést ha nincs másolat nem oldod meg, ha az ellenőrző a rossz, akkor azt tudja ellenőrizni és kijavítani. -
Dißnäëß
nagyúr
A zfs 1 lemez esetén is biztosít némi integrity-t, kis hiba esetén ?
Tud olyat, hogy akárcsak a cache-t, SSD-re tenni mondjuk az ellenőrző kódokat ?
Példa:
4T HDD: adat + ellenőrzők
512G SSD: cache (vagy sem) + ellenőrzőkA két ellenőrző garancia lehetne arra, hogy egy kis HDD silent bit rot esetén egyértelműen tudja a rendszer, az adat szar-e, vagy az ellenőrzője. Kérdés, hogy ha erre (mivel két ellenőrzőnk lenne) rájön, tehát ellenőrzők jók és adat szar, vissza tudja-e kalkulálni az adatot matekból, vagy ahhoz minimum 2 fizikai diszk kell (mirror).
-
Dißnäëß
nagyúr
Szóval ha két új meghajtót hozok, hogy azokon kevésbé fontos dolgokat tároljak és ez a mirror megmarad, akkor:
1. semmiképpen sem a meglévő poolba tenném őket "add"-al (sem "attach"-el nyilván), hanem
új pool kreálás és oda "add" mindkettőt. Mivel csupaszok lesznek még, valszeg egyenlően fogja elosztani rajtuk az adatokat (raid0-szerű működés). Mount-olva logikailag kb:
- mirror (hdd1, hdd2)
- stripe (hdd3, hdd4)2. ha pedig érintetlenül szeretném hagyni őket, egymástól függetlenül, akkor 2 új pool és mindegyikbe "add" 1-1 HDD, így lesz végül 3 pool-om, amiknek fel-mount-olt könyvtárai:
- mirror (hdd1, hdd2)
- standalone (hdd3)
- standalone (hdd4)Stimm ?
-
Dißnäëß
nagyúr
válasz
stopperos
#47
üzenetére
És ha jól tudom, automatikusan megtörténik a balanszozása is az adatoknak, tehát a meglévő mirror-0 -mon lévő 4T adatomat elteríti úgy, hogy fizikailag a végén 2T marad a mirror-0-n, 2T pedig az új 4T-s különálló HDD-n, ha egy olyat tolok be hozzá "add"-al.
Legalábbis ezt olvastam. (És ilyenkor raid0 szerű működést kapok). De elvileg ez automatikusan végbemegy a háttérben, nem ?
(Kipróbálom ma este egy virtuális gép alá betolt kisméretű virtuális HDD-kkel).
-
stopperos
senior tag
-
Dißnäëß
nagyúr
Azt jól vettem ki a doksiból és innen-onnan, hogy ha a sima "add" paranccsal hozzáadok fizikai tárolót a meglévő pool-omhoz, amiben immár van egy mirror, akkor a rendszer egy "raid0" (stripe) dolgot hoz össze a mirror-al és az új diszkkel ?
Szóval
- ha a mirrorba akarnék harmadikat: zpool attach
- ha a mirror mellé akarnék még egy két diszkes mirrort: zfs add mirror dev3 dev4 ?(És így kapok a két mirrorból egy raid0-t, összesen a raid10-et lényegében).
-
Dißnäëß
nagyúr
válasz
stopperos
#44
üzenetére
Úgy lesz, megpróbálom.
Érdekes, hogy attach-kor az ashift=12-t meg kellett adnom neki, de egyéb paramétereket nem (pl. xattr=sa, atime=off -ot nem tudta az attach értelmezni, de mivel a meglévő dataset így ezekkel lett létrehozva, azt gondolom, attach-kor az új csatlakozó fizikai tároló is megkapja ezeket a jellemzőket, ahogy mirror-á konvertálódik az egyedülálló dataset és már ketten vannak). Compression-t sem fogadta el az attach... igazából elég leszűkített opciókat fogad, ahogy olvastam man pages-ben és neten is, de valszeg ez okkal, mert hát meglévő dolgokhoz csatlakozik és akkor azok property-jeit felveszi, gondolom, ami nagyon okos működési logika lenne).
Mindenesetre gyönyörűen elindult a resilver, tényleg csak ashift=12 volt az attach parancsban a plussz.
4 tera (3.4 használt), most jár 70% körül.
(Kikapcsoltam este, reggel boot, szépen folytatja a resilveringet azóta is). -
stopperos
senior tag
-
Dißnäëß
nagyúr
Ja és brahiból compression=gzip-9
Az első telemásoláskor tekert elég jól mind a 12 proci szál, de így is kimaxolta a HDD fizikai átviteli sebességét lazán. Vegyes motyók vannak-lesznek rajta, kíváncsi leszek, hogyan viselkedik hosszabb távon ez a megoldás, sokat nem nyerek rajta, de direkt ezt húztam be most. Arra is kiv. leszek, olvasáskor mennyi CPU terhelést kapok, 1 lemezzel, illetve 2-vel majd. Lemérem majd.
-
Dißnäëß
nagyúr
Szóval végül megfogadtam a tanácsod és belevágtam. Jópár sikeres teszt és az ECC RAM-jaim érkezésével el is indult nemrég a móka.
![;]](//cdn.rios.hu/dl/s/v1.gif)
A neten azt olvasom mindenhol, hogy - nyilván - nem ajánlott, de egyébként bármikor nyugodtan reboot-olhatok, vagy gép kikapcs és reggel bekapcs, folytatja tovább, nincs adatvesztés (lényegében a zfs zseniális alapelveinek és működésének köszönhetően lehet ez így igaz állítás). Stimm ?
-
Dißnäëß
nagyúr
válasz
stopperos
#37
üzenetére
root@DESKTOP:~# zpool status -v
pool: zfsmirror1
state: ONLINE
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Wed Feb 26 19:52:30 2020
907G scanned at 668M/s, 146G issued at 107M/s, 3.32T total
146G resilvered, 4.28% done, 0 days 08:38:26 to go
config:
NAME STATE READ WRITE CKSUM
zfsmirror1 ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-ST4000VN000-1H4168_Z503T7M2 ONLINE 0 0 0
ata-WDC_WD40PURX-64GVNY0_WD-WCE6E3MS78Z9 ONLINE 0 0 0 (resilvering)
errors: No known data errors -
Dißnäëß
nagyúr
válasz
stopperos
#39
üzenetére
É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.
-
stopperos
senior tag
-
Dißnäëß
nagyúr
válasz
stopperos
#37
üzenetére
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.
-
stopperos
senior tag
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.
-
Dißnäëß
nagyúr
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.
-
Dißnäëß
nagyúr
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). -
#32
stopperos
senior tag
MasterMark
#31
stopperos
senior tag
válasz
MasterMark
#31
üzenetére
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. -
#31
MasterMark
titán
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.
-
stopperos
senior tag
Ezek alapján
fletcher4az on jelentése.Illetve pl itt tudsz kicsit utána olvasni.
-
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. -
stopperos
senior tag
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.
-
dchard
veterán
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
-
Jó lett, színvonalas, és érthető
-
-
stopperos
senior tag
A cikkben ezt állítom:
"Szinte minden fontos környezetben elvárás az ECC RAM, hogy ott is meglegyen a hibaellenőrzés. A ZFS is nyugodtabb ilyen körülmények között. Jó lenne az ECC, de sima DDR[1-4] modulokkal is használható."
Annyi csak a lényeg hogy attól, hogy ZFS-re váltunk egy szerveren, azért nem kell ECC RAM-ra váltani. Az adatbiztonság miatt viszont akkor is ECC RAM-ot használjunk, ha más fájlrendszert használunk.
De akkor ezt pontosítom. -
kikinda2
tag
Szerintem félreérthettél. Nem szeretnék arról vitatkozni, hogy hol, milyen drága konfiguráció működik addig míg egy teljes, vagy részleges összeomlás be nem következik és, hogy ez miért érte meg az illető cégnek. Megjegyzésem javító szándékú volt, hiszen a cikk tévesen állítja, hogy a nem ECC RAM megfelelő. A ZFS fájlrendszer éppen a hibák kiküszöbölése, kizárása érdekében készült. Ha a teljes láncolatba, ahol az adatok megfordulnak gyenge láncszemeket rakunk, akkor az egész lánc olyan erős lesz mint a leggyengébb része. Tehát megismétlem a nem általam, hanem komoly szakemberek által is vallottakat: Lehet nem ECC RAM-ot használni, de ez órási hiba és ne kövessük el, ha az adataink érnek valamit. Ezt kellene a cikkben pontosítani.
-
kikinda2
tag
Nagyon jó, tömör írás.
A ZFS tévhitek és problémák résznél a #2 tévhithez szeretném megjegyezni, hogy valóban lehet nem ECC RAM-ot használni, de ez hasonló jelentőségű hiba, mintha a háttértár redundancia nem megfelelően lenne megtervezve. Ahogy a merevlemezeken is képesek a bitek "átfordulni" ugyan úgy a RAM-ban is előfordulhat ilyen. Ezért használjuk a háttértárakon a ZFS-t és a memóriára az ECC-t.
A nem olyan gyors, mint lehetne: részhez érdemes megjegyezni, hogy nagyon nem mindegy mire fogjuk a rendszert használni és ehhez a PORONIX áprilisi tesztjét elolvasni itt:Köszönöm a cikket.
-
NLZ
tag
Azt még érdemes megemlíteni (nem láttam a cikkben), hogy bővíteni csak vdev szinten lehet, szóval egyszerre több diskkel (amiből egy legalább paritás lesz).
Szóval emiatt nem ajánlanám mindenhova, pl házibarkács NASba néhány vinyó mellé a SnapRAID+Mergerfs kombó rugalmasabb, simán hozzá lehet csapni vagy kivenni egy disket.
Mondjuk azt még nem vizsgáltam, hogy milyen a SnapRAID alatti ZFS raidz nélkül, bár elég öszvérnek hangzik. -
stopperos
senior tag
Nem vagyok én sem jogász, de tömören én úgy hámoztam ki, hogy a CDDL csak annyit köt meg, hogy a forráskódnak kell mindig CDDL-nek és nyíltnak kell lennie, míg a lefordított bináris kb tetszőleges license alatt kiadható. A linux GPL-jéhez ha hozzáadunk valamit forráskód szintjén, akkor az GPL-nek kell lennie, vagy legalább át lehessen váltani GPL-re. Ez a kettő ütközik, ezért csak modulként érhető el.
A fent leírtakban nem vagyok teljesen biztos, ha valaki jobban tudja, akkor javítson ki.
-
stopperos
senior tag
Nekem még nem volt napi szinten szükségem erre, de lehet kvótát beállítani (majd a napokban hozzáírom. Többféle létezik:
1) A teljes fájlrendszerre vonatkozók:$ sudo zfs set quota=10G vd-Rocinante/backup
és$ sudo zfs set refquota=10G vd-Rocinante/backup
A második csak annyiban különbözik, hogy abba nem számítódnak bele a pillanatképek.2) De lehet felhasználóra és csoportra is létrehozni:
$ sudo zfs set userquota@ubuntu10G vd-Rocinante/backup$ sudo zfs set groupquota@wheel=20G vd-Rocinante/backup3) Fenntartani szabad helyet, mint az ext3-4 fájlrendszernél
$ sudo zfs set refreservation=2G vd-Rocinante/backupAmire vigyázni kell, hogy amikor a kvóta határát elkezdi elérni a felhasználó vagy a fájlrendszer, akkor az IO műveletek belassulnak, ugyanis a ZFS szeretne mindent kiírni, de pont csak annyit amennyit lehet. Mostanság az a törekvés, hogy egy lustább ellenőrzés legyen benne, ami megengedi a túlcsordulást, és akkor nem fog ez a lassulás jelentkezni. (hivatkozást most nem tudok a problémára)
-
Valóban figyelmetlen voltam, oda is írtad hogy már használatban, és látni is hogy "csak"151GB szabad.
Esetleg ezen tulajdonságát jobban is kiemelhetnéd, hiszen nincs szükség az adott partíció méretének megbecslésére.
Ugyanakkor be lehet állítani limitet, hogy az egyik ne nőjön a másik fejére? Pl. egy elszabadult program/felhasználó teleszemeteli, és a többieknek nem marad üres hely. -
Vesa
veterán
Na, végre egy szakmai cikk a Logouton! Egyre ritkább sajnos...
Köszönjük, kiváló lett, jól felépített igényes írás!Otthon én is már jó sok éve használok FreeNAS-t, maximális megelégedéssel. Egyszer húztam újra az egész rendszert, éppen az ZFS miatt, mert -ha jól emlékszem talán a v9.0/9.1 környékén vezették be, vagy akkor vezették ki az UFS-t, már nem tudom-. Korábban UFS-t használtam, mondjuk nekem azzal sem volt adatvesztésem. Bár eleinte én is sokkot kaptam a RAM igénytől, a gyakorlatban tesztelve 16GB-al simán elmegy otthoni környezetben (nálam 6db HDD-vel, összesen 10TB a kapacitás jelenelg, de tervezem lecserélni kevesebb, de nagyobb tárakra).
Az ECC RAM egyébként nem csak adatbiztonság miatt jobb, hanem a sokkal jobb minőség ellenére még olcsóbbak is a használtpiacon! -
Nagy jó cikk lett, gratula!
Én voltam figyelmetlen, vagy nem emelted ki, hogy a partíciók létrehozásakor nincs megadva méret. Miért lettek egységesen 151GB-osak?
1 x RAIDZ1 | 6 wide | 2.73 TiB
mert hátha jó lesz még egyszer.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
lo Az otthon tárolt adatmennyiség növekedése miatt szükségessé válhat saját NAS, melyhez kiváló a ZFS fájlrendszer.
- Robot fűnyírók
- Magga: PLEX: multimédia az egész lakásban
- iPhone topik
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Amlogic S905, S912 processzoros készülékek
- Le Mans Ultimate
- Azonnali alaplapos kérdések órája
- Asztalos klub
- Milyen TV-t vegyek?
- Székesfehérvár és környéke adok-veszek-beszélgetek
- További aktív témák...
- Gombászkönyvek egyben
- LG 48C4 - 48" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - A9 Gen7 CPU
- Azonnali készpénzes nVidia RTX 2000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- www.LicencAruhaz.hu OLCSÓ & LEGÁLIS SZOFTVEREK 0-24 KÉZBESÍTÉSSEL - Windows - Office - ÖRÖK GARANCIA
- AKCIÓ! AMD Ryzen 9 3900X 12 mag 24 szál processzor garanciával hibátlan működéssel
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest