Sziasztok,
RHEL 8.7 alatt szükségem lenne compressed volume-ra (konkréten egy könyvtár esetén, rekurzivan).
- BTRFS kiesik mert ki lett vezetve
- VDO gyári csomagja használhatatlan:
ERROR - modprobe: FATAL: Module kvdo not found in directory /lib/modules/4.18.0-425.19.2.el8_7.x86_64
- ZFS-ről nem sokat találtam RHEL alatt és az is experimental-al tűnik
Van esetleg más opció rá?
Köszönöm, Tassadar
- 654 megtekintés
 
Hozzászólások
Ez rendes RHEL (nem a klónjai)? A kmod-kvdo és a vdo csomagok fent vannak rendben?
A hivatalos út a VDO, a többi nem supportált.
- A hozzászóláshoz be kell jelentkezni
 
Igen, ez rendes RHEL.
A csomagok fent vannak:
Package vdo-6.2.7.17-14.el8.x86_64 is already installed.
Package kmod-kvdo-6.2.8.7-88.el8.x86_64 is already installed.
kernel:
2.6.78-425.19.2.el8_7.x86_64
- A hozzászóláshoz be kell jelentkezni
 
rpm -ql kmod-kvdo mit ad vissza?
Valszeg rossz konyvtarba telepult...
- A hozzászóláshoz be kell jelentkezni
 
/etc/depmod.d/kvdo.conf
/lib/modules/4.18.0-458.el8.x86_64
/lib/modules/4.18.0-458.el8.x86_64/extra
/lib/modules/4.18.0-458.el8.x86_64/extra/kmod-kvdo
/lib/modules/4.18.0-458.el8.x86_64/extra/kmod-kvdo/uds
/lib/modules/4.18.0-458.el8.x86_64/extra/kmod-kvdo/uds/uds.ko
/lib/modules/4.18.0-458.el8.x86_64/extra/kmod-kvdo/vdo
/lib/modules/4.18.0-458.el8.x86_64/extra/kmod-kvdo/vdo/kvdo.ko
Kernel verziója más
kernel="/boot/vmlinuz-4.18.0-477.13.1.el8_8.x86_64"
de symlinkelve van
lrwxrwxrwx 1 root root 62 Jun 29 13:03 kvdo.ko -> /lib/modules/4.18.0-458.el8.x86_64/extra/kmod-kvdo/vdo/kvdo.ko
- A hozzászóláshoz be kell jelentkezni
 
en a /etc/depmod.d/kvdo.conf fajlba felvennem a mostani kernelverzio path-okat is: /lib/modules/4.18.0-477.el8.x86_64/....
esetleg egy depmod -a ?
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
 
Ez jó tippnek tűnik, köszönöm, úgy tűnik müködik. :)
"esetleg egy depmod -a ?"
Nincs kimenete.
- A hozzászóláshoz be kell jelentkezni
 
Jövök egy sörrel, tényleg müködik.
Kiváncsi vagyok hogy milyen kihatása lesz a sebességre..
- A hozzászóláshoz be kell jelentkezni
 
Azt kellene még kideríteni, hogy egy kernel upgrade szétveri-e újra az egészet...
- A hozzászóláshoz be kell jelentkezni
 
2.6 azosztigen
- A hozzászóláshoz be kell jelentkezni
 
Rossz volt a copypaste:
4.18.0-477
- A hozzászóláshoz be kell jelentkezni
 
Sub
- A hozzászóláshoz be kell jelentkezni
 
Egy dologba belefutottam, a df kevesebb szabad helyet mutat mint a vdostats (talán utobbi már a deduplikált értéket).
Ezzel lehet valamit kezedni?
vdostats --hu
Device                                                                     Size         Used      Available  Use%   Space saving%
/dev/mapper/informatica_agent                                128.0G     21.2G    106.8G     16%     84%
df -h 
Filesystem                                                                Size    Used  Avail  Use%  Mounted on
/dev/mapper/informatica_agent-informatica_agent01  125G  119G  128M 100% /informatica_agent
- A hozzászóláshoz be kell jelentkezni
 
Igen, azt mutatja. Hozd létre nagyobb logikai mérettel (vdoLogicalSize).
Bővebben itt:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/…
Fstrim mindenképpen legyen bekapcsolva (ezt lejjebb találod hogyan kell)
- A hozzászóláshoz be kell jelentkezni
 
VG-t nagyobb csináltam kibővitettem a LV-ot:
Filesystem                                                                Size    Used  Avail Use% Mounted on
/dev/mapper/informatica_agent-informatica_agent01  295G   27G  255G  10% /informatica_agent
vdostats --hu
Device                                         Size      Used Available Use% Space saving%
/dev/mapper/informatica_agent    128.0G     19.2G    108.8G  14%           53%
Azt nem teljesen értem hogy ez hogyan lesz összhangban a fizikai mérettel. :)
- A hozzászóláshoz be kell jelentkezni
 
A fizikai méret az a méret, amire a VDO-t létrehoztad. Ha jól látom, akkor 128.0GB-s. Ebből a fizikai foglaltság 19.2 GB, a logikai pedig kb a duplája (53% saving).
- A hozzászóláshoz be kell jelentkezni
 
Igen, eddig baromi hatékonynak tűnik.
Filesystem                                                                 Size  Used Avail Use% Mounted on
/dev/mapper/informatica_agent-informatica_agent01  295G  125G  157G  45% /informatica_agent
Device                                          Size        Used    Available Use%            Space saving%
/dev/mapper/informatica_agent    128.0G     21.4G    106.6G    16%           86%
Arra céloztam hogy nehéz így kalkulálni, Windows esetén (ehhez értek) a compressed drive mérete nem változik,
viszont a tárolt adat mérete igen.
Itt pont fordítva van, a tárolt adatok valós méretét látod a logikai lemezen, viszont a lemez mérete nem a fizikai lemezét mutatja.
- A hozzászóláshoz be kell jelentkezni
 
Sejtem mire gondolsz. Itt a VDO réteg a blokkeszközt tömöríti, függetlenül a rajta lévő filesystemtől. Emiatt látod fs-en belül a logikai méretet. Ennek az a hátránya, hogy neked kell megbecsülni a logikai méretet.
- A hozzászóláshoz be kell jelentkezni
 
Most beleestem abba (teszt környezet) hogy a blokkeszköz tárhelyfoglaltságát nem figyeltem, hiába a 85 százalék körüli tömöritési arány, egyszer az is kifogy. :)
Amikor ez megtörténik, akkor viszont már csak read-only vagyok képes mountolni a fájlrendszert (ext4), tehát nem tudok törölni róla hogy felszabaduljon hely.
- A hozzászóláshoz be kell jelentkezni
 
Hiába törölsz, az önmagában nem segít, mert a törlés még nem szabadítja fel a foglalt blokkokat.
Fstrim-et kellene futtatni, vagy discard mount opciót használni. Viszont ez kétséges, hogy mennyire működik, ha már read-only-ban van mountolva az fs.
- A hozzászóláshoz be kell jelentkezni