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
- 651 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
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