Dotaz: Nedostatok diskoveho priestoru

[Hrome]

Zdravim Vas... asi jednoducha vec ktora tu isto zaznela ale nedopatral som sa k nej - po starte mi Mint vypisuje "nedostatok diskoveho priestoru na koren suboroveho systemu" .... akymi prikazmi sa dopracujem k tomu aby som ten "cache"vymazal nech mam pokoj?? budem vdacny za rady

Odpovědi

[Want]

Začni tím, že poštveš truncate na nejvíce zbytnělý log ve /var/log

[Peter Golis]

Aby neodmazal ten gigantický /var/log/wtmp, to mu nepomôže.

[Want]

Ty máš křišťálovou kouli, že víš co mu zabírá nejvíc místa? Každopádně truncate nic nemaže. Je to použitelné řešení v situaci, kdy máš zaprásknutý disk až do mrtě.

[Peter Golis]

Keby si mal aspoň raz v živote v rukách Linux, tak vieš že to wtmp vyzerá ako gigantický súbor na ktorý vždy narazia začiatočníci a naľakajú sa ako keby ich pohladila smrtka. Keby si ale aspoň trošku poznal Linux, tak vieš že je to sparse súbor ktorý aj napriek veľkosti zaberá len máličko.

A keby si aspoň trošku poznal IT, tak vieš že truncate maže obsah súboru. Ten sa ale uvoľní až keď ten súbor nebude otvorený akýmkoľvek procesom.

Ale kľudne poraď ešte niečo, rád sa zabavím.

[Want]

Golis, kdybys alespoň raz v životě netáral kokotiny, to by bylo slávy. Ten soubor má, alespoň tedy na stroji postel.felk.cvut.cz trapných 526K a to má uptime 107 dní. A ten truncate by sis měl otestovat.

[Peter Golis]

A koľko mu po inštalácii hlásilo ls =l ? Ak tie rôzne čísla porovnáš, tak sa dostaneme ku sparse súborom, a na čo som narážal pri reakcii "nejvíce zbytnělý log ve /var/log". Medzi také súbory ktoré sa začiatočníkovi javia ako moc veľké patria vo /var/log aj [last,fail]log.

Ale s tým truncate, tak mi prezraď ako uvoľní miesto na disku ak sú inody skracovaného súboru obsadené bežiacim procesom. Skús to vysvetliť tvojím začiatočníckym spôsobom.

Toľko ku tým tvojím žvástom akými sa chváli lamička ktorú na MDD nikto nechce.

[Want]

Ty lamičko, moje infrastruktura obsluhuje několik desítek strojů a obsah adresáře /var/log má smysl jen když něco řešíš. U lamy tedy většinou žádný. Truncate používám jen v případě, že potřebuji uvolnit alespoň tolik místa, aby zafungoval journalctl. Zkrátím velikost na 0 bajtů, ty stávající data se zahodí a ten proces začne zapisovat nová. Si to vyzkoušej mameluku.

[Peter Golis]

Ak by tvoje slová mali v sebe aspoň zrnko pravdy, tak sa na desktopoch vypína zápis do logov na disku. A vôbec by sa ani neinštaloval kadejajký syslog alebo journal daemon.

No a inštaluje sa, takže na tom záleží.

Ohľadne tej infraštruktúry ktorú akože spravuješ, tak by som poprosil sieťový rozsah. Rád si ho preventívne zablokujem.

[Aleš Kapica]

Ohľadne tej infraštruktúry ktorú akože spravuješ, tak by som poprosil sieťový rozsah. Rád si ho preventívne zablokujem.

Beze všeho: 192.168.x.y – za x a y si dosaď libovolné číslo od 0 do 255

[Peter Golis]

Ahoj Wantáčik, zabudol si sa odhlásiť.

[Want]

Jo, a našel jsi tam i moje nahé fotky, že?

[Aleš Kapica]

Mimochodem, ten tvůj /var/log/wtmp obsahuje data, která jsou úplně k hovnu. Viz /var/log/wtmp

Je to jen zbytečný bordel zabírající místo, který se při restartu může s klidnou duší zahodit, protože (u mne) jsou klíčové informace uložené jinde, ve výrazně srozumitelnější formě. Soubor, ve kterém jsou veškeré informace za posledních 334 dní má všeho všudy 65MB

A největší log /var/log/lastlog má u mne trapných 100MB

[Peter Golis]

Ty si dokázal nahodiť logrotate? Tak to gratulujem, si šikuľka.

[..]

ty jsi ale toxicky hovno to z tebe teda zbyla troska

[Want]

Zalez kokůtku do své anonymní díry a lízej si řiť, když nemáš páru o čem se mluví.

[Andrej]

Je rok 2025. Na co systmd-journald poštve nějaké zkracování, to je věcí jeho konfigurace. A ne, podstatná část diskového prostoru se opravdu (ale opravdu (ale opravdu)) neuvolní zkrácením (binárních, komprimovaných) logů.

[Aleš Kapica]

Budeš se divit, ale jo. Speciálně u zaplácnutého Btrfs. A příkaz journalctl --vacuum-time=1d sem tam také použiju.

[Andrej]

Nevím, no. Když mám podezření, že je něco špatně, podívám se na journalctl -f. Pokud se něco objevuje častěji než jednou za (se)kundu, obvykle je potřeba řešit příčinu toho problému, ne až následek. Dokonce mám na některých stojích alert odvozený od „produktivity“ journalctl -f.

[Want]

Přečti si prosím ještě jednou, od samého počátku tuhle diskuzi prosím.

[Andrej]

Pořádné sračky. Až to bolí číst. Hlavně tedy ten truncate.

[Aleš Kapica]

Mysli si o tom co chceš, pro mne je důležité, že to funguje.

[Andrej]

Mysli si o tom co chceš, pro mne je důležité, že to funguje⁰.

(⁰) Před 15+ lety by to možná fungovalo [pozn. red.].

Pohled do kalendáře mě utvrzuje v jistotě, že nezáleží na tom, co si kdo myslí. Věci v té strohé realitě prostě už nějak jsou.

[Jendа]

zkrácením (binárních, komprimovaných) logů

Možná mám journald špatně nastavený, ale zabírá mi mnohem víc prostoru, než ekvivalentní textová reprezentace. Konkrétní experimenty:

journalctl | wc -c ukáže 1325903166 (1.3 giga), ale /var/log/journal má 4.3 GB. Člověk by čekal, že tam ještě budou efektivně uložené timestampy a další metadata.

Textový /var/log/syslog, do kterého podle mě přeposílám veškeré zprávy co jsou v journalu, má od neděle 327 MB. journalctl --since "6 days ago"| wc -c ukáže 267377143 (267 mega), čili řádově by to odpovídalo. Následně jsem spustil journalctl --vacuum-time=6d a /var/log/journal se zmenšilo na 782 MB, stále je tedy 2-3x větší než hloupý textový syslog.

Obsah adresáře /var/log/journal jsem zkopíroval a zkusil zkomprimovat defaultním gzipem. Zmenšil se na 175 MB (4.5x). To znamená, že původní data vůbec nejsou komprimována, naopak.

Též jsem gzipem zkomprimoval textový /var/log/syslog. Ten se zkomprimoval na 22.5 MB (skoro 8x lépe než komprimovaný binární journal). Tedy ani například transparentně komprimující souborový systém by s journalem tolik nepomohl.

Naposledy jako zpětná kontrola: teď když jsem udělal vacuum za 6 dní, tak mám

• journalctl | wc -c: 245 mega
• journalctl | gzip | wc -c: 12.5 mega
• du -sh --si /var/log/journal/: 782 mega

Co dělám špatně?

[Andrej]

Jo, to netuším, co je špatně. Přičiním jenom několik „stating the obvious“ poznámek:

• Zazipovaný textový soubor nemá ani náznak indexování nebo jiné podpory rozumně rychlého přístupu k logům podle -u nebo podle času, takže se nedá srovnat 1:1 s tím, co ukládá journald.
• Pokud mě man journald.conf neklame, implicitně se komprimují jen záznamy (== jednotlivé „zprávy“ v logu, velikostí něco mezi „řádkou“ a „backtrace“ ), pokud přesáhnou 512 B. Tohle se sice dá nastavit (snížit), ale pokud má každý záznam svůj oddělený kontext/slovník pro kompresi, bude taková komprese velmi neúčinná.
• Pokud je uschopněný Seal= (FSS), což v některých distrech může být implicitně nastavené při instalaci, bez vědomého přičinění uživatele, můžou data logů ještě víc nabobtnat.
• Čtení všeho z /var/log/journal není příliš fair srovnání, protože tam je uložené všechno z journalctl + všechno z journalctl --user + všechno z journalctl --user pro všechny ostatní uživatele.
• Dokonce i bez FSS budou mít soubory s logy nějaké svoje extra checksumy. (Nevím, jak časté a s jakým overheadem.)

Ještě pro upřesnění, co jsem myslel tímto:

A ne, podstatná část diskového prostoru se opravdu (ale opravdu (ale opravdu)) neuvolní zkrácením (binárních, komprimovaných) logů.

Výše zmíněné checksumy zajistí, že poškození (náhodné zkrácení) binárních logů od journald učiní tyto soubory nečitelnými. Tudíž místo předvídatelného zkrácení dojde ke ztrátě dat z podstatné části příslušného souboru (výrazně větší než uříznutá část), popřípadě z celého souboru, který může journalctl odmítnout číst. A při každém přístupu přes journalctl se bude ukazovat chybová hláška o poškozeném souboru.

Proto↑ jsem příslušnou „radu“ považoval za kolosální nesmysl. Měl jsem se vyjádřit přesněji.

[mikrom]

Pozri Timeshift, mozno ti miesto zaberaju snapshoty.

[MarV]

Pro začátek bych se podíval, jak je disk rozdělený a zaplněný pomocí df -h, protože může být nějak hloupě rozdělený. Dál lze pátrat po velikosti jednotlivých adresářů příkazem du viz příklady třeba zde.

[Peter Golis]

Začiatočníkovi bude lepší príkaz "baobab", ten to oskenuje a ukáže v klikacej forme.

Škoda že to nenapadla Aleša pri založení otázky, a ani keď si na ňu odpovedal. No ale keby ho to napadlo, tak sa nemusí pýtať.

[Hrome]

"baobab" mi to teda zprehladnil - vdaka - synator ma na domovskom disku 8GB hru - rad by som ju preložil na bezny disk - ale po každom spustení si aplikacia vytvori v domovskom adresari opať adresar a zahlti disk

[MarV]

Baobab jsem neznal - dík. Bohužel nevím, co je myšleno pod "běžný disk". Pořád by se hodil ten výpis "df -h" pro pochopení situace. Možná by šel použít nějaký ohejbák (např. symbolický link na jiný oddíl/fyzický disk).

[Peter Golis]

Ešte je srandovný program zvaný czkawka, ten bleskovo nájde duplikáty súborov (nielen podľa názvu, ale aj podľa obsahu a to dokonca aj rovnaké/podobné obrázky rôznych rozlíšení). Jeden by neveril čo za pitomosti a v koľkátych kópiách má človek naťahané. Ideál keď si človek hala-bala zálohuje selfíčkové a filmíkové fotečky z mobilu v ktorom mu zaberajú rádovo gigabajty.

[Hrome]

"bežny disk" nazyvam disk kde mam uložené všetky moje dokumenty- subory fotky videa..atd.. cize nie domovsky disk linuxu

[Want]

Vlákno bylo přesunuto do samostatné diskuse.

[Want]

Tohle vlákno vám názorně ukáže, jak otevřený je pan Golis, když dojde na lámání chleba.

[Peter Golis]

V tom vlákne si chcel nejaký zázrak, a volal si to notbook. Tomu som naozaj neni otvorený.

Asi si ťa bloknem s tvojími rôznymi alter egami, opakuješ sa.

[Fluttershy, yay!]

Jděte pryč. Oba. Máte e-mail aj.

[alfisko]

V terminale :

sudo bash cd / du -sh * |sort -h zoradi podla velkosti

[Fluttershy, yay!]

Na mazání dočasných souborů je BleachBit, dokonce klikací. Mint ho má v repozitářích. Pro mazání na systémovém oddíle spustit „BleachBit (as root)“.

[karkar]

Zkus vymazat (staré) stažené balíčky:
sudo apt-get autoremove
sudo apt-get autoclean
sudo apt-get clean

[Michal]

Možná stačí smazat i starší jádra pokud je aktualizujete a nemažete.