(Open)SUSE ala VDO? - Sikerült már valakinek?

Linux-haladó

Sziasztok!

 

CentOS alatt nagy megelegedettseggel hasznaltam a VDO-t, de most szeretnem migralni az egyik serverem OpenSUSE ala. csomag nincs sajna OpenSuse hoz, forrasbol sem sikerult meg leforgatom eddig sem a kernel modult sem a userspace toolt OpenSuse alatt... Van valakinek ezzel sikere? ha igen meg tudna osztani a metodust? Vagy ha van VDO alternativa SUSE ala, az is erdekelne... (BTRFS/ZFS nem jatszik jelen esetben)

  • 779 megtekintés

( Tassadar v | 2024. 03. 05., k – 14:43 )

Irsz egy kicsit a use-case-ről (amiért BTRFS nem működhet)? 
Én kifejezetten utálom a VDO-t, szerintem használhatatlan.

( Vamp | 2024. 03. 05., k – 22:55 )

csomo jegyzokonyv (txt fileok, tehat jol tomoritheto) mentese. Jelenleg 500 Gigas disk bol foglal 250-et , virtualisan 900 Gb korul. (1 Tb a VDO layer) Szepen allithato ha kezd "betelni", dobok meg ra par szaz gigat. Tobb eve megy gond nelkul, en szeretem, jol atlathato. 

dobok meg ra par szaz gigat

Engem pont az zavar benne hogy nem az adatok tömöritett méretét látom mint egy FS-alapú deduplikációban,
hanem a logikai lemeznek kell nagyobbnak lennie mint az aktuálisan rajta tárolt nyers adatok mérete.

Ha a tömörítés a fő elvárás, akkor miért nem jó a ZFS? LZ4 és Zstd is elérhető, rászánt CPU teljesítménytől függően akár nagyon jó tömörítési hatásfokok elérhetőek. Az sem igaz, hogy ZFS-t csak csillió giga memóriával lehet használni, ahogyan az sem igaz, hogy csak sok natív diszkkel. Használhatod sima FS-nek egy szem lemezen/partíción, ilyenkor nem kapod meg a plus resiliency-t (mivel nincs redundancia*, amiből helyreállhatna), de a tömörítés, a checksum-os hiba-felderítés, a snapshot, stb. mind használható gond nélkül. Kvótázással szépen tudod szabályozni/korlátozni a dataset-ek helyfoglalását is.

*szerk: valójában ilyenkor is lehet kérni az adatblokkokból több másolatot, akár dataset-enként külön-külön beállítva, így ha nem egyszerre veszik el az egész (pl. HDD szektor olvasási hiba lép fel), akkor a hiba felismerésén túl bizonyos mértékig helyre is tud állni akár egy partíción használva is (persze tárhely feláldozásával és nem 100% biztonsággal).

Akkor a ZFS-től csak az extra szolgáltatásokat várod, a redundanciát megoldja az alsóbb réteg.

A ZFS doksiba és a hozzáértők írásaiban mindig az szerepel, hogy amit várunk a ZFS-től, az ahhoz szükséges, általa evárt feltételeket biztosítsuk. Nem az, hogy bármit várunk a ZFS-től, akkor is az összes ajánlást és kötelezvényt biztosítani kell. Sajnos ezt nagyon sokan úgy szajkózzák tovább fórumokon ismételgetve, hogy csak natív diszkek, csak ECC memória, csak sok memória, csak NVMe SLOG, stb. Ez mind nem igaz a valóságban, így, ebben a formában.

Szerintem tegyél vele egy próbát, úgy gondolom kellemesen fogsz csalódni ilyen felhasználás mellett is. Annyit ajánlok csak, hogy legyen 2 GB memória, amit a ZFS használhat (ha nem extrén nagy, több TB-os helyet kell kezelnie, mert akkor TB-onként +1 GB kelleni fog). Más nagy elvárás nincs igazából ilyen esetben.

Írtam egy csomó nem releváns dolgot, mire ténylegesen megértettem a kérdést. :-D

Szóval ZFS-en "ls"-re a fájlok valódi méretét látod, nem a tömörített helyfoglalást. "du" esetén alapból a tömörített helyfoglalást látod, -A vagy --apparent-size kapcsolóval viszont a fájl tényleges mérete alapján számolja ki (mennyi lenne tömörítés nélkül).

Kozben vegul tenyleg a ZFS lett  befuto, eloszor TrueNAS Core , majd TrueNAS Scale megvalositasaval. Vegul azt is inkabb elengedtem és egy "Csupasz" OpenSUSE lett a gyoztes, kezzel, konzolbol/TUI-bol beallitva. 

Amugy kozben meglett hogy a 

zfs get logicalused,used,compressratio zpool_name

parancsal szepen meg lehet nezni, hogy merrol hany meter is a valos/logikai helyfoglalas es a tomoritesi rata.

( Vamp | 2024. 03. 26., k – 15:34 )

Kis info meg:

 

Bar hivatalosan az (Open)ZFS "nem baratja" az (Open)SUSE-nak, ahhoz kepest szepen dolgozik vele! Ami kulon tetszik, hogy a ZFS snapshotok hasznalhatoak Samba alatt shadow copy-nak! ACL-ek posix-al vannak kezelve (eleg lett vegul, nem kellett az NFSv4 amit meg nem tud a ZFS linux alatt)

1.69 TB (zömében) jegyzokonyvbol csinalt 178 Gigat, zstd+Dedup al! derék...!

Dedup-nál arra figyelj, hogy nem kell pool szinten aktiválni, elég dataset szinten amikor szükséges, valamint dedup használatánál be kell tartani a doksi szerinti _plusz_ memória igényt (általában +1 GB minden 1 TB dedup tartalomra), mert memóriában tárolja a szükséges hash táblákat.

Van egy erdekes hibam meg, te talalkoztal mar ilyennel? 

 

Restart utan, teljesen random, az alabbi hibauzenetet kapom:

 

failed to start import zfs pool by cache file

reszletesebben:

Mar 27 11:05:49 hun25-28v systemd[1]: Starting Import ZFS pools by cache file...
Mar 27 11:05:49 hun25-28v zpool[676]: internal error: cannot import 'storage_01': Value too large for defined data type
Mar 27 11:05:49 hun25-28v systemd[1]: zfs-import-cache.service: Main process exited, code=dumped, status=6/ABRT
Mar 27 11:05:49 hun25-28v systemd[1]: zfs-import-cache.service: Failed with result 'core-dump'.
Mar 27 11:05:49 hun25-28v systemd[1]: Failed to start Import ZFS pools by cache file.

 

10 restartbol kb 2-3 szor jon elő, a tobbi esetben minden ok.

Proxmox-on olykor jelentkezik ez a boot korai szakaszában, de igazából nem kezeltem soha, mert a Proxmox első használtnál beimportálja azon pool-okat, amik még nincsenek importálva bármi okból. Amikor cache file-ból megy az import, akkor csak a cache-ban szereplő pool-okat importálja a rendszer, és ha sérült a cache file, akkor azokat se mindet.

De a legtöbbször a cache állomány sérülése okozza ezt a hibát. Megteheted, hogy letörlöd, és egy export/import végrehajtásával újra generálódik. Vagy le is tilthatod a cache file használatát, és akkor minden boot során normál scan által importál be minden pool-t amit csak talál.