Střípky z IT - (6) : ext4 : Uhádnete, kde byl problém? (diskuse)

[Milan]

Dosli ti tam inody?

[Max]

No jasně, a řešení? :).
Zdar Max

[disorder]

destruktivne ci nedestruktivne? :)

Note: If you use OverlayFS, use the overlay2 driver rather than the overlay driver, because it is more efficient in terms of inode utilization.

[Max]

Nedestruktivní řešení není. Řešením je takový svazek přeformátovat tak, aby bylo přiděleno více inode k poměru k datům. Tj. zazálohujeme data, přeformátujeme a pak data nakopírujeme zpět:

# default je:
mkfs.ext4 -i 16384 /dev/neco

# jak to vypadá:
tune2fs -l /dev/neco |grep Inode
Inode count:              655360
Inodes per group:         8192
Inode blocks per group:   512
Inode size:               256


# zdvojnásobíme počet inode takto
mkfs.ext4 -i 8192 /dev/neco

# jak to pak vypadá
tune2fs -l /dev/neco |grep Inode
Inode count:              1310720
Inodes per group:         16384
Inode blocks per group:   1024
Inode size:               256

S tím, že když se kontroluje volné místo, tak je třeba kontrolovat nejen pomocí "df -h", ale i "df -i", které právě ukáže zaplnění inode.

Zdar Max

[Max]

Ještě doplním, že toto samozřejmě platí pro případ, kdy tam máme regulérní data a né nějakou chybu, která nám ty inody sežrala. V případě regulérního nasazení jsem se s tímto problémem setkal u ElasticSearch a u Dockeru. Obě řešení generují velký počet souborů, který vysaturuje inody.
Zdar Max

[MP]

Nestaci zvetsit disk a resiznout? Ja se s vycerpanymi inody snad nikdy nesetkal, tak nevim, zda to lze.

[Max]

To samozřejmě nějaké inody přihodí, ale je ti to celkem k prdu. Z příkladu vidíš, že je tam reálně volných 50GB dat a inody došly. Resize je možná jen dočasný workaround, který ti umožní si naplánovat odstávku na přeformátování. Pokud nepřeformátuješ, dojdou ti inody zachvíli znovu, protože máš evidentně nasazenou nějakou app, co generuje hafec malých souborů.
Lepší workaround je možná něco rychle vymáznout.
Zdar Max

[j]

Mnohem jednodussi a efektivnejsi reseni bude neco naladovat do archivu (a netreba to ani komprimovat, pokud jde o vykon). Ten muzes navic nekam mountnout, takze ty soubory ani nikde nezmizej.

Jinak i ty inody bys byl schopnej pridat (bez formatovani) jen by to bylo takovy manualni pitvani fs (=musel bys laborovat primo s jeho blokama, nektery presunovat ...). Takze casove pomerne neefektivni.

---

Dete s tim guuglem dopice!

[xsubway]

V tom příkladu nastavuješ polovinu z původní hodnoty - to není dvojnásobek.

[Max]

To se pleteš. Nastavuje se tam dvojnásobek počtu inode tím, že se mění poměr bajtů k inode. Pokud chceš mít víc inode, musíš počet bajtů snížit. Viz "-i bytes-per-inode".
Nebo mi chceš tvrdit, že 1310720 není dvojnásobek hodnoty 655360?
Zdar Max

[xsubway]

Ok. Dik za vysvětlení.

[Xerces]

BTRFS?

[⧠ A = 0]

ReiserFS

[⧠ A = 0]

Jinak osobně jsem to posledně řešil rm -r na složku, kde mi kvůli chybě vytvořil program miliony souborů po dvaceti slabikách („prázdné“ gzip soubory).

„Užitečná“ data bych asi spojil do tar archivu nebo něčeho podobného. Nebo ještě úplně na začátku v aplikaci nevytvářet příliš mnoho malých souborů.

[⧠ A = 0]

(Což možná úplně nebude fungovat u dockeru. Nevím, proč zrovna docker žere tolik i-uzlů, ale pokud s tím nic jiného nenadělám, tak buď vytvořit ext4 s větším množstvím uzlů (mke2fs -i), nebo použít jiný souborový systém.)

[Migi]

jednorazově:

docker system prune -a --volumes

a do cronu pravidelně

docker system prune -a -f

[Max]

Tak třeba to v příkladu byl gitlab-runner, kde prune probíhá celkem pravidelně. Ale s postupným navyšováním zátěže to pak stejně nedopadne dobře. Takže jako workaround na uvolnění místa ok, ale trvalé řešení opravdu přeformátovat na jiný poměr inode, nebo změnit filesystem.
Zdar Max

[plostenka]

Trvale reseni je nepouivat bastlsw, ktery mala data uklada do souboru misto do DB, ktery po sobe nemaze vlastni bordel, pripadne ktery nema specificke naroky na FS v dokumentaci.

[Max]

ktery mala data uklada do souboru misto do DB

Hloupost, to by jsi vyřadil hafec super aplikací (dovecot, docker, elk, minio a další) a to jen kvůli prapodivnému argumentu.

ktery po sobe nemaze vlastni bordel

Prune je zdokumentovaná věc a každý si tak může nastavit cykl promazávání jak chce. Nevidím v tom problém.
Zdar Max

[plostenka]

Hloupost, to by jsi vyřadil hafec super aplikací (dovecot, docker, elk, minio a další) a to jen kvůli prapodivnému argumentu.

Kdy naposledy ti DB vyzrala inody? I minimalisticky sqlite3 te od tohohle problemu odstini, nehlede na pomalost prochazeni adresaru s mnohatisici inodami uvnitr.

To je treba duvod proc si pisu sqlite3 patch pro mutt, aby misto maildiru byly maily ulozene v DB. Mailbox je krehky a snadno rozbitelny, to neni reseni.

Prune je zdokumentovaná věc a každý si tak může nastavit cykl promazávání jak chce. Nevidím v tom problém.

To by si mel hlavne hlidat docker sam od sebe, primarne bordel vubec nedelat aby nebylo co mazat.

[Max]

U DB jsem řešil zase milion jiných věcí. Problém s inody je specifický pro ext4, řešení je pak jednoduché, použít jiný fs.
Zdar Max

[Semo]

Vyborny chytak je (nechat si) odobrat pravo "x" z korenoveho adresara (chmod -x /). Zakernost je v tom, ze rootovi vsetko funguje a zaroven dnesne filemanagery obvykle nezobrazuju polozku "." v roote, takze si to clovek nevsimne.

[Jendа]

Já jsem zase nějak kopíroval a obnovoval systém a /tmp přišlo o právo t. A pak se začaly rozbíjet náhodné věci.

[Jendа]

Když už jsme u toho, všimli jste si (řešilo se to na Rootu), že když naformátujete device na ext4 vs. třeba na XFS, tak na ext4 je výrazně (cca. 5%) méně volného místa (a ne, nejedná se o rezervované místo pro roota)? Trochu pomůže mkfs.ext4 -T largefile, ale stejně to vypadá, jako kdyby mělo ext4 mnohem vyšší režii než konkurence. Nebo to jenom takhle reportuje, a konkurence to místo spotřebuje až během používání FS?

[Max]

Zajímavý námět, zkusím si s tím pohrát, až bude chvilka času. Podle mě to možné je.
Zdar Max

[marbu]

Nemůže to být třeba právě tím rozdílem v alokaci inodů (dynamicky u XFS vs staticky u ext4)? Ale to jenom hádám.

[Heron]

Všimli.

Na rozdíl od XFS si ext vytváří vše staticky.

[petr_p]

A všimli jste si, že XFS do pár megabajtového blokového souboru neuděláte? Na rozdíl od ext FS? Jestli to nebude tím, každý z těch systémů vznikl v jiné době za jiným účelem, takže jejich datové struktury a jejich efektivita vzhledem k velikosti zařízení tomu odpovídají.

[Petr]

Kde byl problém? Neschopný admin - píčus.

[Max]

Zato lidé, co mají pusu plnou vulgarit od lopaty, ty jsou výkvětem inteligence, co? :D
Zdar Max

[_]

říká někdo, kdo má vulgární i přezdívku

[alkoholik]

Jo, tohle jsem potkal uz 3x.
V prastarem monitorovacim systemu kombinovanem s mail serverem, na Oracle AVDF (ten nikomu nepreju ani za trest) kvuli nemazanym audit files z ASM a na pohovoru.

[Max]

Hmm, Oracle AVDF, to asi musí být další pecka cena :)

Jinak já se s tím setkal asi 4x. Jednou nějaký webhosting (asi wp, co vygeneroval moc souborů + maily k tomu). Pak u dockeru, kde je opravdu hafec malých souborů a to samé pak i u ElasticSearch, který taktéž generuje hafec malých souborů.
Stále si říkám, zda se toho ext4 ve VM stále držet, nebo zda už na to nehodit bobek :).
Zdar Max

[Dirka]

Pred lety sem to na jedne VPS resil takto, byly to statisice malych souboru (vsechny repozitare gentoo vcetne overlayu)

dd if=/dev/zero of=/virtualfs bs=1024 count=3307200
losetup /dev/loop0 /virtualfs
mkfs -t ext3 -b 1024 -N 1000000 /dev/loop0
mount -t ext3 /dev/loop0 /var/www/xxx/gentoo/portage/

a VPS zila nekolik dalsich let :)

[⧠ A = 0]

V čem je to lepší než normální oddíl stejné velikosti?

[Dirka]

Nemusis delat resize stavajici partisny (byla to VPS bez fyzickyho pristupu a root fs).

[luky]

Pri 4kB blocich by byla sance tak 1% ze by musel rodicovsky adresar vyrust aby pojmul nove jmeno. Logicke mi prijde kontrolovat rovnou inody. Casto mi prijde, ze lide moc nepremysli nad tim, co vlastne provadena operace delala.