- f0xhu blogja
- A hozzászóláshoz be kell jelentkezni
- 358 megtekintés
Hozzászólások
ext4-ben is van egy bug, hogy noveles utan nem frissit be egy checksum mezot, igy kov mount mar nem mukodik, es nem lehet kezdeni vele semmit. egy touch vagy hasonlo muvelet ujra frissiti a mezot, utana jo lesz. azzal a deb 11 volt erintett...
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
ez ahogy nézzük... bug/feature... Egyik részről tudja már az igénylő, hogy hány KiB, MiB, vagy TiB igénye lesz, másrészről meg jó lenne, ha lenne valami online FS reorg fícsör XFS szinten, ami a fentit is tudja, vagy legalább a tool-ok figyelmeztetnének előre... :P
A gyors gondolat többet ér, mint a gyors mozdulat.
- A hozzászóláshoz be kell jelentkezni
Tehát baromi kicsiről baromi nagyra lett növelve az FS, és e miatt a kicsihez (valószínűleg automatában választott) allocation group méret extrém kicsinek minősült, és baromi sok lett belőle. Ami egy határig nyilván javítja a teljesítményt, de egy méret fölött extrém mennyiségű adminisztrációt igényel az FS-től. Hát, az szops. És maga után vonja azt, hogy a továbbiakban az mkfs.xfs-nek tessen *értelmesen nagy* agsize-ot választani
Engem amúgy az érdekel, hogy ez a mountolásra adott időkeretet nem lehet valahogy tuningolni, hogy boot közben ne 90 sec legyen, hanem mondjuk 900? Ha jól olvasom, ebbe a "rövid timeout-ba" a boot belehal, de ha kézzel felbootolom, akkor már kézzel fel tudom mountolni (gondolom mert akkor már hosszabb a timeout).
- A hozzászóláshoz be kell jelentkezni
https://www.freedesktop.org/software/systemd/man/systemd.mount.html
x-systemd.mount-timeout=-
Configure how long systemd should wait for the mount command to finish before giving up on an entry from
/etc/fstab. Specify a time in seconds or explicitly append a unit such as "s", "min", "h", "ms".Note that this option can only be used in
/etc/fstab, and will be ignored when part of theOptions=setting in a unit file.See
TimeoutSec=below for detailss
- A hozzászóláshoz be kell jelentkezni
Köszi, éjszaka ez közben nekem is feljött valami ubuntus keresésre adott válaszként, bár az rémlik, hogy valahol decisecond-ot írtak, mint alap mértékegység. Tulajdonképp már csak az a kérdés, hogy ez mennyire megbízhatóan működik, illetve mi a helyzet systemd-mentes disztrókban :-)
- A hozzászóláshoz be kell jelentkezni
"Ha túl kicsi a kardod (FS-ed), akkor toldd meg egy (két) lépéssel (de, leginkább gondolkodj előre...)"
Ha RÖVID a kardod...
Ami kicsi, az egy másik szerszám :)
"Normális ember már nem kommentel sehol." (c) Poli
- A hozzászóláshoz be kell jelentkezni
+1 valóban, de most nem arra értettem! ;) :D
A gyors gondolat többet ér, mint a gyors mozdulat.
- A hozzászóláshoz be kell jelentkezni
128 MEGÁról hogy a francba merül fel h. növelni kell 6 TERA-ra?? Az a 128 mega lehetett valószínűleg félreértés az elején. Vagy vmi virtualizációs környezetben fixen lefoglalt 128MB-os diszkek ezrei voltak (thin provisioning hello?), és 1 db VM-nek meg ugyanebből a template-ből kellett hirtelen megnövelni 6 TB-ra?
- A hozzászóláshoz be kell jelentkezni
Tippem szerint: Több lépésben történhetett a növelés. 128 MB -> 512 MB -> 2 GB.... -> 6 TB. Ráadásul nagy valószínűséggel ezek a change-k "no reboot"-osak voltak. Akár éveken keresztül is. Most meg egy reboot alatt előbújt a "nyuszi".
- A hozzászóláshoz be kell jelentkezni
Vannak ún. "általános" és "speciális" célú HA (Pacemaker+Corosync) NFS cluster-eink. A cluster kialakításakor még nem tudjuk előre, hogy pontosan hány rendszernek és mekkora NFS területe(ke)t fog kiosztani, de mivel online nem tapasztaltuk célszerűnek a cluster-be új LV-k és FS-ek + exportfs-ek felvételét (borult miatta a cluster, leginkább az LV kreálás + új resource felvétele során), ezért úgy alakítottuk ki őket, hogy "van bennük tartalék", "dummy" LV-k formájában. Szóval, ha jön egy új NFS share igény, akkor egy ilyen "dummy" LV resource-ot bővítünk fel a kívánt méretre, az FS és az export már eleve ott van, a cluster nem borul meg és mindenki örül. Egyébként évente 2 alkalommal ezeket is karban tartjuk/patch-eljük és akkor a szükséges adminisztrációkat is megcsináljuk, pl. lvrename, új "dummy" kötetek kiajánlása, stb... Remélem ez válasz a kérdésedre! ;)
A gyors gondolat többet ér, mint a gyors mozdulat.
- A hozzászóláshoz be kell jelentkezni
He jól értem a leírást, akkor a Data Block Sharing miatt van a baj, nem lett volna elég csak azt letiltani, hogy ne használja?
- A hozzászóláshoz be kell jelentkezni
RHEL note szerint nem kikapcsolható. :/
- A hozzászóláshoz be kell jelentkezni
És tényleg, mert formázáskor kerül rá, hogy van e reflinks vagy sem. Tanulság: reflinks=0-val kell formázni.
- A hozzászóláshoz be kell jelentkezni
A leírás szerint amiatt, a házon belüli tesztek szerint pedig nem feltétlenül.
Házi, tesztkörnyezetben egy 50MiB LV-t bővítve 100GiB-re!, minden kapcsolót kipróbálva arra jutottam, hogy *csak* az AG méret és az AG-k száma van összefüggésben. Szóval, egy kis agsize-zal létrehozott, de NAGY FS csatolása *MINDIG* lassú lesz, míg egy kellően nagyra méretezett kezdő FS méret (és/vagy agsize) esetén (pl. 100GB esetében 4AG) a teljesítmény (és a boot idő) az elfogadható tartományban marad. Teszem hozzá, hogy ha van egy pl. 128MB LV, amiről tudjuk előre, hogy legalább 100GB méretű lesz, akkor így lenne egy ?optimális? FS létrehozás: mkfs.xfs -d agsize=50g, vagy akár 100g (man szerint kicsivel kevesebb, mint 1TiB a max méret, egzakt érték nincs megadva), viszont erre meg egy kövér hibaüzenet lesz a válasz, t.i. az LV "csak" 128MB, így nyilván nem lehet rá 50 vagy 100GB méretű AG-t létrehozni.
Szóval, ahogy a post-ban is írtam, ilyen esetekben *mindig* előre kell gondolkodni és nem feltétlenül nekünk, mérnököknek, hanem mondjuk a projektvezetésnek...
A gyors gondolat többet ér, mint a gyors mozdulat.
- A hozzászóláshoz be kell jelentkezni
OK, de mit mutattak a tesztek, mekkora az agsize gyárilag egy ilyen 128MB-os FS-nél? Illetve mi az agcount gyárilag? És mi történik, ha agcount=1-et próbálsz beállítani - ez az én értelmezésem szerint egyetlen AG-t fog eredményezni, ami mindig akkora, amekkora az éppen létrehozott FS. (És tippem szerint amikor növeled az FS-t, akkor az így beállított agsize-ot fogja használni - ami persze még mindig lehet hogy nagyon, de lehet hogy már nem baromi sok.)
Szerk: kipróbálva, nekem azt mutatja, hogy egy 128MB-os diszkre gyárilag agcount=4 -gyel hoz létre FS-t. Nem mondom, hogy sokat nyersz, de azért logikusan csak negyed annyi AG-d lenne így ...
- A hozzászóláshoz be kell jelentkezni