Dotaz: Plný "súborový systém"

[pohan]

Zdravím Vás

Otázka od amatára - používam Linux Mint - a po štarte mi Linux vypisuje "plný súborový systém", ked pozriem na disky cez "Nemo" disk "súborový systém" mi ukazuje disk ako takmer plný - čiže - ako ho vyčistič - vyprázdniť - tento disk???

Vďaka za radu !!!

---

---

Odpovědi

[z_sk]

Začni výstupmi:

df -h
df -i

[pohan]

moc tomu nerozumiem :

perun@perun-ESPRIMO-P720:~$ df -h
Súborový systém Veľk Použ Dost Pou% Pripojený na
udev 3,8G 0 3,8G 0% /dev
tmpfs 785M 1,4M 783M 1% /run
/dev/sda6 37G 34G 1,1G 98% /
tmpfs 3,9G 102M 3,8G 3% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup
tmpfs 785M 160K 784M 1% /run/user/1000
/dev/sda5 389G 280G 109G 72% /media/perun/400
/dev/sdb1 466G 211G 255G 46% /media/perun/500gb

perun@perun-ESPRIMO-P720:~$ df -i
Súborový systém I-uzly IPouž IVoľ IPou% Pripojený na
udev 994011 570 993441 1% /dev
tmpfs 1003684 887 1002797 1% /run
/dev/sda6 2441216 1298458 1142758 54% /
tmpfs 1003684 160 1003524 1% /dev/shm
tmpfs 1003684 4 1003680 1% /run/lock
tmpfs 1003684 18 1003666 1% /sys/fs/cgroup
tmpfs 1003684 78 1003606 1% /run/user/1000
/dev/sda5 114156992 35012 114121980 1% /media/perun/400
/dev/sdb1 267363772 32167 267331605 1% /media/perun/500gb 

[z_sk]

Takže, hlavný odiel máš plný:

/dev/sda6 37G 34G 1,1G 98% /

Daj nasledovný príkaz ako root (su alebo sudo bash a potom vložíš môj príkaz). Niečo to bude trvať, nakoľko zisťuje, kt. priečinok je najviac plný (vynechá priečinok dev, tj. externé média):

clear; cd /; du -sh `ls |grep -v dev` 2> /dev/null | sort -rh |head 

[z_sk]

Ah, vynechať ma priečinok media:

clear; cd /; du -sh `ls |grep -v media` 2> /dev/null | sort -rh |head 

[pohan]

som na tom istom.... disky je plny

[pohan]

vypisalo mi

/usr/bin/clear: /usr/bin/clear: nie je možné vykonať binárny súbor

[LTE]

Tak potom:

cd /; du -sh `ls |grep -v media` 2> /dev/null | sort -rh |head 

[Jendа]

ncdu -x / (ideálně pod rootem) a proklikat si co zabírá nejvíc místa a pak podle uvážení smazat.

[ewew]

Zameral by som sa na adresáre /var/log, /var/lib/apt. Predpokladám, že nerobíš pravidelne vymazanie stiahnutích aktualizácii po každej aktualizácii či inštalácii. Určite by som skontroloval logy či tam niečo nehlási problém alebo nemal systém vhodný čas na rotáciu logov.

Možné riešenie uložených balíčkov na debiane je apt clean a riešenie logov logrotate -v -f /etc/logrotate.conf/. Neviem ako to má Mint.

[Andrej]

Ty rady z minula nepomohly?

[pohan]

Dakujem vsetkym za rady... pomohlo ncdu... a zrejme sa predosle instalacne balicky ukladaju-nevymazavaju, precistene : "sudo apt autoremove"

ale zaujimalo by ma preco si Mint uklada akoby nahodne screeny do adresara : "/home/perun/.cache/thumbnails/"

zle zadany prikaz v minulosti?

[Jendа]

Protože generování náhledů je pomalé a když otevřeš adresář v grafickém správci souborů znovu, tak chceš, aby se ti to zobrazilo hned.

[Andrej]

Nesmyslně sis rozdělil disk na zbytečné oddíly a tohle jsou důsledky.

Disk se dnes zásadně nedělí; není k tomu důvod.

Bráno pozitivně, jistě jde o cenné ponaučení pro příští instalaci.

[Pepe]

Tak to si nemyslím, protože i instalátor rozdělí disk (UEFI) případně swap, ale pokud budu chtít zálohovat systémový oddíl např. pomocí fsarchiver, nebo clonezilla proč bych měl zároveň ukládat ohromný domovský adresář?? Osobně dávám zvlášť oddíl /home

[Peter Golis]

Rozumné zálohovacie systémy vedia aj tak zvané "excludes".

[Ruža Becelin]

Tak to si nemyslím, protože i instalátor rozdělí disk (UEFI)…

Dobře, ale UEFI oddíl, obvykle o velikosti asi tak jednoho GB nebo méně, bych neoznačoval za „dělení disku“. To je prostě jakási nutnost, kterou (pouze) bootovací disk bohužel musí obsahovat.

…případně swap…

Raději ne. Máme rok 2022 a z toho plyne:

1. Skoro nikdy neexistuje důvod mít swap.
2. Když už jo (třeba kvůli „uspání“), swap je soubor, ne oddíl.

…pokud budu chtít zálohovat systémový oddíl např. pomocí fsarchiver…

Systémový subvolume, ne systémový oddíl.

Když chci zálohovat systémový subvolume, vytvořím si z něj atomický snapshot, ten atomický snapshot pak někam odešlu a následně ho zase odstraním. (Nebo si případně ponechám pár předchozích snapshotů na zdroji i cíli zaloh, proč ne; jejich velikost je prakticky nulová, když se toho mezi nimi málo změní.)

Mimochodem, jak by mi nesmysl typu fsarchiver zaručil atomicitu a konzistentnost záloh, pokud zálohuju z běžícího a namountovaného systému? (Což je celkem klíčový požadavek — nechci přece mít kvůli zálohám žádný downtime. A chci snapshotovat automaticky a libovolně často — klidně každou hodinu nebo každý den, když na to přijde.)

…proč bych měl zároveň ukládat ohromný domovský adresář??

To taky nechápu, proč bys měl. Právě sis vymyslel problém, který ve skutečnosti vůbec neexistuje. Domovský adresář bude jednoduše jiný subvolume, jak jinak. Zazálohuješ si ho tedy zvlášť, odděleně, jindy, podle potřeby — a samozřejmě taky atomicky, byť přímo z namountovaného systému.

Tohle^^^ je dnes samozřejmost. Neexistuje proto důvod dělit disk na oddíly (kromě UEFI oddílu u bootovacího disku).

Osobně dávám zvlášť oddíl /home…

Což je naprostý nesmysl. A pokaždé se tím spolehlivě střelíš do nohy, že jo, jakmile zjistíš, že nevyužitá kapacita v / by se zrovna dočasně hodila v /home nebo že nevyužitá kapacita v /home by se zrovna dočasně hodila v /. Přesně jako původní tazatel; přesně tohle je celý problém.

Znova proto zopakuju: K dělení disku neexistuje důvod. Každý podadresář v /home má být jednoduše subvolume, jak jinak — takovým způsobem domovské adresáře spravuje například také systemd-homed, který vřele doporučuji.

[Xhv111]

Souhlasil bych se swapem/uefi. Ale rozdělení disku je potřebné např. v případě bitových kopií oddílů. Já mám např. Virualbox s Win na zvlášním oddílu. Nebudu dělat bitovou kopii 50giga souboru nějakých Win. Pokud máš např. 50GB / a čistíš systém tak ho nelze ani zdaleka zaplnit a argument že by se dočasně hodila kapacita z /home je lichý a nikdy jsem to nepotřeboval. Samoshřejmě jde o velikost ssd disku.

[Ruža Becelin]

Ale rozdělení disku je potřebné např. v případě bitových kopií oddílů.

1. Není.
2. A především: Proč takový neefektivní nesmysl dělat?

Já mám např. Virualbox s Win na zvlášním oddílu.

Proč? K čemu je dobrý takový „anti-flexibilní“ nápad? Vždyť všechno nevyužité místo na tom oddílu je ztracené a nemůže ho využít zbytek systému ani jiný virtuální stroj. (To taky asi bude ten důvod, proč je ten oddíl tak nesmyslně malý…)

Soubor ve formátu qcow2 je nesrovnatelně lepším řešením:

• Je kompaktní, díky kombinaci řídkých (sparse) souborů a chytrého formátu. Nezabírá tedy místo, které zabírat nemusí. TRIM / discard ve virtuálním stroji díky tomu uvolní místo ve filesystému hostitele.
• Z výše uvedeného plyne: Můžu například vzít virtuálku s diskem o velikost 10 TB, na kterém je právě zabraný(*) pouze 1 TB, a tuhle virtuálku zazálohovat na fyzický stroj (či dokonce spustit na fyzickém stroji) s pouhými 2 TB úložiště. Flexibilita je fajn.
• Jedná se o běžný soubor, který se dá ve zlomku sekundy atomicky replikovat, bez ohledu na velikost (cp --reflink), nebo snapshotovat společně se subvolume, ve kterém se nachází. S oddílem cp --reflink nikdy nevykouzlíš.

Nebudu dělat bitovou kopii 50giga souboru nějakých Win.

Ne, to opravdu ne. Podobně jako předřečník o pár příspěvků výše vymýšlíš problém, který neexistuje.

Zaprvé, pokud nechci zálohovat virtuálky společně s jinými daty, dám je prostě na jiný subvolume — což už píšu asi tak potřetí a nechápu, co je na tom k nepochopení.

Zadruhé, pokud budu mít virtuální qcow2 disk o kapacitě 50 GB a na tom disku zabraných(*) 10 GB, kopie takového disku bude obsahovat přibližně 10 GB dat, nikoliv 50 GB.

(*) Klíčová technická poznámka: Od dob TRIMu / discardu už je jasně definované, bez ohledu na použitý filesystém, šifrování nebo obecně strukturu dat na virtuálním disku, které bloky jsou a nejsou využité. V dobách, kdy TRIM / discard neexistoval, tohle jasně definované nebylo; virtuální disk se zkrátka postupně beznadějně plnil až do 100% přidělené kapacity a bez znalosti jeho vnitřní struktury ho nebylo možné „zkompaktnit“. Jenže dnes máme rok 2022, pročež se nemusíme zaobírat problémy z dávné minulosti.

Pokud máš např. 50GB / a čistíš systém tak ho nelze ani zdaleka zaplnit a argument že by se dočasně hodila kapacita z /home je lichý a nikdy jsem to nepotřeboval.

Ty potřebuješ nějak „čistit systém“? Jak to? Proč? Neříkal jsi náhodou, že argument s nevyužitým místem je lichý? Tohle nějak nesedí. (A nepleteš si to s Windows?)

Mimochodem, proč má mít oddíl tak zoufale žebráckou velikost jako 50 GB? Já mám například na jednom stroji pouze 2 TB SSD. Na tom stroji mám cca 15 virtuálek. Každá virtuálka má disk o velikosti minimálně 1 TB. Jakpak to asi funguje? Inu, velmi dobře. Mnohem lépe, než kdybych musel fyzickou diskovou kapacitu rozdělit předem na titěrné kousky a marně bych zkoušel uhádnout, která virtuálka bude v bližší či vzdálenější budoucnosti potřebovat víc prostoru.

Znovu opakuji a podtrhuji:

Nedělit.

Nedělit.

Nedělit.

[P.]

to je sice řešení, ale pouze v případě btrfs. Osobně ho nepoužívám ze strachu o ztátu dat!

[kolega]

Hele, chapu, ze v pripadu v nekterych konfiguraci je to mozna minimalne problematicke. Ale Fedora a OpenSuse ho pouziva jako vychozi... Takze data-loss by uz snad tohle mnozstvi uzivatele reportovali.

[Andrej]

Fedora nabrala s (nezbytným a nevyhnutelným) zavedením implicitního Btrfs trapné 10-leté zpoždění proti původnímu plánu, částečně kvůli FUDistům všeho druhu, tedy kvůli žvanilům typu „Btrfs sice nepoužívám a vůbec nechápu, o co se jedná, ale samozřejmě jsem vehementně proti němu“.

Mnohem důležitější je obrovské nasazení Btrfs ve Facebooku a jiných firmách, které funguje už dobrých 10 let. Kdyby bylo něco v nepořádku, ono by se to na těch milionech strojů poznalo.

[Andrej]

Tohle ovšem nemyslíš vážně a jenom zbytečně a hloupě trolluješ, což?

Kdybys měl opravdu strach o svá data, používal bys výhradně Btrfs nebo ZFS. Protože u čehokoliv jiného je riziko ztráty dat mnohem vyšší.

Kdybys podobně trolloval třeba před 10 lety, bylo by to možná i vtipné, ale v roce 2022 už jsou takové výroky všeho všudy trapné.

Samozřejmě, že mé rady předpokládají Btrfs nebo ZFS — protože nic jiného dnes nemá smysl používat (s výjimkou toho EFI oddílu).

[P.]

Trollování je určitě tvrzení že mimo ZFS a Btrfs nemá smysl nic jiného používat. Každý máme své zkušenosti se stabilitou např. doma na PC bez UPS-ky. Zajímalo mě to a několikrát i s velkým časovým odstupem testoval. ZFS nevím, ale pro Btrfs je to katastrofa. To je ale na jiné vlákno. Jestliže tobě riziko ztráty dat nevadí je to tvoje věc. Proto si nech poznámky o hloupém trollování pro někoho jiného!

[Andrej]

Každý máme své zkušenosti se stabilitou např. doma na PC bez UPS-ky.

UPS dnes nehraje téměř žádnou roli. Pokud si myslíš, že potřebuješ UPS, může to být právě špatnou volbou filesystému.

…ale pro Btrfs je to katastrofa.

Bla, bla, bla. Nepodložený FUD. Klasika.

Podobných nesmyslných žvástů se na webu povaluje spousta. Některé jsou z roku 2010. Jiné zase popisují experiment na starém rozbitém hardwaru, na který někdo dá „na zkoušku“ Btrfs. (Proč ne na nový?!) Další pocházejí z marných snah o úložiště, ovšem bez ECC (!) a bez podrobností o stavu RAM a hardwaru celkově. A pokaždé se objeví zhruba tentýž problém:

1. Pseudoargumentace anekdotou. Povídačky jednoho FUDisty těžko vyváží dekádu nasazení na milionech strojů ve velkých firmách. Jedině tak se dají získat fakta, čísla a data, nikoliv z jednoho blíže neurčeného pokusu na jednom blíže neurčeném (a obvykle dosti rozbitém) domácím systému. Pověry (naštěstí) nic nemění na informovaných rozhodnutích velkých distribucí (openSUSE, Fedora) doporučovat Btrfs jako implicitní filesystém.
2. Chybí jakákoliv definice katastrofy v tom smyslu, s čím srovnáváme. Btrfs je prý katastrofa — ve srovnání s čím? Kdybych měl použít tuhle podivnou katastrofální rétoriku: Ext4 je mnohem horší katastrofa. XFS je mnohem horší katastrofa. JFS je mnohem horší katastrofa. A tak dále. (Vše zmíněné jsou totiž filesystémy bez checksumů dat, bez copy-on-write jako základního principu, bez vestavěného RAIDu a dalších typů redundance atd. Každý z nich je proto mnohem horší katastrofa než Btrfs.) Takže: Co je ten vzor pro srovnání? Kde je ten zázračný filesystém?

Jestliže tobě riziko ztráty dat nevadí je to tvoje věc.

Vadí. Proto používám výhradně Btrfs a/nebo ZFS.

Proto si nech poznámky o hloupém trollování pro někoho jiného!

Nenechám. Hloupě trolluješ a šíříš FUD.

[Jendа]

Povídačky jednoho FUDisty těžko vyváží dekádu nasazení na milionech strojů ve velkých firmách.

Souhlasím, miliony firem používají ext4, přesto tu pořád šíříš FUD jaká je to katastrofa.

[Hovno]

Že miliony firem údajně samy sobě škodí — a co má být? Tak po zásluze neuspějí v konkurenci, diplomaticky řečeno.

Miliony lidí kouří. No a? Mám si taky šluknout?

Firmy (velké, nikoliv JZD Prdelice) používají Ext4 nejčastěji jako primitivní name/value store, nad kterým je postavená nějaká abstrakce — s vlastní redundancí, s vlastními checksumy, s vlastními samoopravnými kódy, s vlastní globální replikací atd.

Jednotlivec někde doma má prostě používat implicitní Btrfs a nespekulovat nad nesmrtelností chroustů.

[xxxs]

otvorene. vacsina domacich uzivatelov nema ups, nezalohuje. mala cast zalohuje a len uplne minimum ma poriesene raidy a automaticke zalohy. pre tu vacsinu vypadok prudu pri zapise znamena, ze na btrfs si musia niekoho zavolat, aby im to presypal inde. to na exte, alebo ntfs neriesia a pridu o data iba vtedy ked zdochne zelezo. ticha korupcia dat, ktoru si nikdy nevsimnu vs taketo atrakcie? no hadaj.

[Hovno]

…pre tu vacsinu vypadok prudu pri zapise znamena, ze na btrfs si musia niekoho zavolat…

Co je tohle za pičovinu??? Pro Dionýsa, to se snad nevidí, takhle blbý žvást!

Na Ext4 nebo XFS mají mnohem větší riziko, že jim to chcípne! Btrfs chrání jejich data mnohem lépe, při výpadku proudu nebo bez něj.

…to na exte, alebo ntfs neriesia a pridu o data iba vtedy ked zdochne zelezo…

Ale hovno. Jediné, co fakt neřeší, je silent data corruption. Prostě mají data průběžně posraná a sežraná, průběžně se jim ta data kazí, ale jasně, oni to neřeší. Bezva.

[xxxs]

si nejaky nervozny.

[k3dAR]

v nejakem minulem vlakne o btrfs, nekdo psal prakticke zkusenosti z testovani na stejnem HW ext4 a btrfs, byl v lokaci kde je castej vypadej proudu, s ext4 problem nemel, btrfs se skoro hned rozsypalo... "bojovnikama za btrfs je to jedine spravne" byl vyfuckovan, ze preci s btrfs ma pouzivat UPS

[rastos]

Si hlboko presvedčený o svojej pravde. Dobre. A možno je to aj objektívna pravda. A možno to vieš lepšie, ako ktokoľvek z prítomných. Ale spôsob, akým to komunikuješ, je nahovno.

[k3dAR]

ad posledni cast souhlas, mit to slusnou presentaci mozna bych zas btrfs potreti zkusil, jestli tentokrat o data s nim neprijdu :)

[lertimir]

A kdy si o ně přišel a za jaké situace. Používám už tak 8 let btrfs všude (pracovní stanice, notebooky včetně manželčiného a dcery), a nikdy žádný problém, naopak pravidelný scrub mě už informoval už o několika HDD které má vyměnit díky tomu, že něco nesedělo. A přežil zcela v klidu i výpadky proudu a i výjimečné pády systému.

[k3dAR]

uz sem to psal nekolikrat a nechce se mi to dohledavat (naposledy to rozebiral dost a nikdo s nicim kloudnym myslim neprisel), tak jen strucne:
1. prevod z ext4 na btrfs - po par dnech se to cele rozsypalo, nepomohl zadnej z nekolika postupu oprav, cerpal sem z Arch wiki i jinde

2. cistej format, vytvoreni nekolika subvol, nasypani dat, ty nasledne zmizeli, resp. po mountu byl obsah prazdnej, opravou se to objevilo, ale duvera nic moc... prejmenovaval sem subvol, jinak nic a i to nemelo udajne mit zadnej vliv

problem s HW nebyl...

Zas až taková trága, jak to popisuješ, btrfs není. To spíš vypadá, že vyzařuješ nějaké zvláštní fluidum, které btrfs nemá rádo. Ale možná bys ho zase po letech mohl na něčem vyzkoušet, třeba to teď bude lepší.

[k3dAR]

2. bylo vloni

[lertimir]

No myslím, že chyba byla, že vývojáři převod vůbec povolili. Vždy jsem si tím pracoval, jako bych převáděl na jakýkoli jiný fs (tedy zazálohovat, naformátovat a restaurovat data ze zálohy). A druhá věc, netuším, jak jsi přejmenování dělal, ale vzhledem k tomu, že všude píší že subvol je fakticky adresář se zvláštními extendy, tak mv v kořeni volumu mi vždy pracovalo správně.

[k3dAR]

prejmenovaval sem jako dir, uz nevim bud mv, nebo v mc... a dalsi vec, subvol sem nemel v korenu ale v /.subvols a mozna i prejmenovaval tohle z /.subvolumes
ad prevod - po nem uz sem take nachazel same info ze to neni doporucovane a souhlas ze to tedy ani ze ta moznost nemela byt radeji vubec dostupna

[lertimir]

Já se subvolumes pracoval vždy podle doporučení. Tj. v kořeni mít @, @home, @var, @snapshots .... s tím, že kořen se nemountuje nikdy, (s výjimkou práce přímo na subvolumes, pak se mounte znovu na jiné místo) a mountují se @>/, @home>/home, @var>/var, @snapshots>/.snapshots ... A nikdy jsem problém neměl. A nyní mám pouze a jedině btrfs už tak 8 let na všech zařízeních.

[trekker.dk]

Soubor ve formátu qcow2 je nesrovnatelně lepším řešením

... teda až do chvíle, než srovnáme výkon

[Andrej]

Který bude u qcow2 občas horší, ale občas taky lepší, že jo.

Kdyby mi šlo o nějaké jednotky procent, můžu použít obyčejný (raw) (a samozřejmě taky sparse) soubor bez qcow2 metadat. Qemu už dávno umí soubory „naředit“ podle TRIMu, i když nejsou v qcow2 formátu, takže žádný problém.

Moje pointa byla: soubor, ne oddíl. Úvahy, kdy bude lepší raw a kdy qcow2, bych nechal stranou.

[trekker.dk]

Který bude u qcow2 občas horší, ale občas taky lepší, že jo.

Ne, s qcow2 bude vždycky horší nebo přinejlepším stejný. Jakýkoliv soubor bude s výkonem vždycky horší nebo přinejlepším stejný než použití oddílu přímo na blokovém zařízení. To je holt matematika a tu neoblafnete, nezáporná režie na obsluhu toho souborového systému, na který ten soubor ukládáte, vám lepší výsledek dát nemůže.

[Hovno]

Co někteří nazývají matematikou, nad tím i Dionýsos žasne.

Tak snad to s tou matematikou nebylo míněno vážně, což?

[lertimir]

Zas bych to tak nehrotil. Jestli odřízneš oddíl o velikosti operační paměti, tak při velikostech disků to je malé procento kapacity a stejně si normálně potřebuješ nechávat mnohem více volného místa. Navíc swap pro hibernaci z důvodu rychlosti má význam pomalu jen pro nvme, jinak systém najede dříve z bootu než se spánku. Důvod pro zachování stavu sice trvá, ale normální notebook spotřebuje ve spánku tak 15-20% baterek za den, takže i tady hibernovat mi připadá nesmysl. Ale nějaký menší provozní swap (na nvme nebo ssd) pořád dobrý.

[Peter Golis]

Hibernácia už dávno neslúži na zrýchlenie štartu. Hibernácia slúži na to, aby človek v kľude pokračoval v "rozrobenej práci", a nemusel si po víkende znovu spomínať čo má všetko otvárať.

[lertimir]

Ano, ale pro uchování stavu nemusím hibernovat a stačí spát. Notebook mi usíná pořád a z plných baterek ve spánku vydrží týden, a v podstatě jej vypínám jen tehdy, když na konci práce (chci a) provedu aktualizace jejichž výsledkem je požadavek rebootu. Pak notebook vypnu.

[k3dAR]

pri spanku ti ale zustava odemcenej LUKS, dat 16GB na swap v dobe 120GB SSD mozna trosku mrzelo, ale u 512GB ci ted 2TB je mi to uz opravdu ukradene

[lertimir]

No asi pracovat na datech s vysokou bezpečnostní prověrkou, tak to řeším, ale myslím, že cold boot attack na zapájenou paměť v MB, jakou má většina lehkých notebooků je těžší, než najít záznam bezpečnostní kamery na němž je zachyceno, jak buším heslo.

[k3dAR]

nejde jen o cold boot attack (btw: pameti mam ve slotech pod 1 sroubkem ale i to ze s NB v sleepu, pri otevreni vika, muze byt prolomenej napr. pripadnou chybou screensaveru/lockscreenu...

[vandrovnik]

Pokud nebude disk rozdělen, dá se nějak snadno docílit toho, aby /home nevyčerpal volné místo, které by mělo být k dispozici např. pro / ?

[Peter Golis]

Pokiaľ bude /home len na to na čo má byť, teda na užívateľské priečinky, tak to predsa rieši už spomenutá quota. Teda nastavenie maximálnej diskovej kapacity ktorú môže využiť jeden užívateľ. Odporučil by som vytvoriť aj druhého užívateľa ktorý by mal mať možnosť spravovať počítač, nech to vie človek pohodlne prečistiť ak si zaplní svoj prídel diskovej kapacity.

[lertimir]

Také doporučuji mít dalšího uživatele, i z toho důvodu, že mám s ním čisté nové prostředí a porovnat, jestli při chybě je to chyba globální, nebo se pod uživatelem pokazila konfigurace.

[pavele]

XFS umí kvótu na adresář - třeba na ten /home.

[jiwopene]

btrfs a ZFS také.

[lertimir]

Tady bych dal jednu výjimku. A to, že uživatel ještě není zcela stabilizován s volbou distribuce. Mít samostatný /home je mnohem jednodušší, když měníš distro, třeba Fedora>Suse>Ubuntu. Uživatelský prostor necháš a systém přeformátuješ.

[Peter Golis]

Tu by som podotkol že užívateľova konfigurácia z jednej distribúcie si nemusí s inou distribúciou rozumieť. Občas sú z toho zaujímavé otázky prečo náhodná vec nefunguje. Najčastejšie je to keď jedna distribúcia používa novší formát konfigov, a tá iná (ktorú chce vyskúšať neskôr) používa novší formát konfigov.

No a zmazať celú konfiguráciu aj s napr. bookmarkami alebo heslami do webových služieb, to môže byť mierny problém bez odovzdania súkromia a identity do cloudu.

[Andrej]

Kdepak.

Notnou dobu jsem měl Fedoru, openSUSE a Arch na jednom filesystému. Při bootování se každému dal ten jeho subvolume pro /boot v kombinaci se subvolume pro / a vše fungovalo, jak mělo.

Jedině /home byl jaksi „společný“, tedy subvolume pro každého uživatele, nikoliv pro každé distro. Sdílené domovské adresáře jsou někdy fajn, pokud verze všeho důležitého (třeba KDE) v různých distrech sedí, a někdy voser, pokud má nějaké distro starší nebo jinak zkompilovanou verzi (například s jiným pojmenováním adresářů s konfigurací).

Společný filesystém měl jinak samé výhody:

• Žádné dělení prostoru předem; každé distro mohlo (dočasně) využít tolik prostoru, kolik bylo k dispozici.
• Stejným postupem se dala přidat další distra, klidně 10 dalších, kdybych chtěl a kdybych k tomu měl důvod / čas / trpělivost.
• Data všech distribucí byla samozřejmě přístupná z kterékoliv, stačilo si někam do /mnt namountovat příslušný subvolume (nebo třeba kořenový subvolume a z něj vidět všechno).

Po čase mě sice údržba toho systému přestala bavit a nechal jsem si tam jen Arch, nicméně ať tak nebo tak, pokud jde o zkoušení několika distribucí se společným /home, jako vždy platí:

Nedělit.

Nedělit.

Nedělit.

[luk]

tiez som nazoru ze nedelit niekedy som bol ovlyvneny openbsd tak som delil a ano ma to zmysel dat osobitne /var root a swap ale popravde prisli do mody SSD disky a odvtedy nedelim dam celu particiu na root a maly EFI a staci a robim pravidelne zalohy veci co stiahnem a aj konfigov na externy disk a ak si clovek zadovazi notebook tak delenie particii je hriech jedno SSD a externy na zalohy lebo malo to zmysel delit ked mal clovek len jeden disk a bal sa o data pri reinstalacii ach ten nestastny okeny system, a nepouzivm btrfs ani ZFS pouzivam klasicky Ext4 a na zalohy ntfs pred tym som pouzival na zalohy ext2 teda bez journalu koli bsdckam ale ntfs je z dlhodobeho hladicka unosnejsi inac mac os tusim da ntfs len read only neviem ci to este plati

[rosťa]

no každý preferuje něco jiného. Já např. linuxovou turistiku :) Virtualbox nepoužívám a tak mám ssd disk rozdělený. Mám bitový kopie aktualizovaných několika dister a během 3 minut mám změněné distro včetně posledních dat. Zvlášť mám např. profil Thunderbirdu skoro 5G dat kterej přece nebudu dávat do bitových kopií každého distra. Prostě mi to tak vyhovuje a nehodlám nic měnit. Jinak samoshřejmě btrfs taky nepoužívám páč nejsem sebevrah. Není nad klasiku.

[Hovno]

Jinak samoshřejmě btrfs taky nepoužívám páč nejsem sebevrah. Není nad klasiku.

Jasně, používáš riskantní a zastaralé technologie a hraješ ruskou ruletu s vlastními daty, protože … jsi nepochopil Btrfs a/nebo „1066 and all that“.

Tak jo. Tak ses pochlubil. Fajn.

profil Thunderbirdu skoro 5G

Profil k Thundebirdu má řádově MB, ne GB. Poslední 2 desetiletí máme IMAP atd.

Mám bitový kopie aktualizovaných několika dister a během 3 minut mám změněné distro včetně posledních dat.

Za jakou cenu zbytečného opotřebení SSD?

Například moje SSD po 38% „záručních“ zápisů četlo rychlostí 170 MB/s místo původních 4,9 GB/s… Už odpočívá na skládce.

Tak hodně štěstí s tou změnou distra za 3 minuty. Brzy to budou 3 hodiny.

[k3dAR]

to bylo asi nejake shit ssd ktere ti ladilo k nicku ne?

[Hovno]

J.e.ž.i.š.h.o.v.n.o.m.a.r.j.a.

Tahleta naivita.

Tady snad někdo věří v životnost SSD, garantovanou bohem Dionýsem?

SSD na 50% záručních zápisů: Kdo z vás to má??? [Jirka Paroubek]

Kdo z vás to má???

Nikdo? No nehlaste se všíchni!!!

Na SSD se dá spolehnout asi tak do 10% záruky, tj. pokud je záruka 2 PB, do 200 TB je to víceméně skoro fajn. Na 20% začínají první zásadní problémy, zpomalení je asi tak na 50% při čtení. (O zápisu raději vůbec nemluvím; ten už bude v prdeli.) Přes 30% nemá smysl jít; tam je potřeba nové SSD. Protože čtení bude pod 5% slibů a zápis se nedoplazí na 1% slibů.

Vyzkoušeno se Samsungem, Seagate, Hovnem, Cruzerem, ADATA, BDATA, CDATA a několika dalšími. Nemá to smysl.

Jasně, možná kdybych si koupil takový ten Intel, který stojí dvacet litrů Kč za každý TB, dostal bych se potom na 32% místo 30%, že jo! Pěkně děkuju.

Co chci říct: SSD jsou bezva, je to rychlé atd., ale je to spotřební materiál. Když smartctl ukáže 30%, je čas to hned vyměnit. (Samozřejmě postupně, pomocí btrfs-replace, jak jinak.)

[k3dAR]

ssd tak nesmazim, takze nez by doslo na 50% zivotnosti, tak uz sem davno menil za vyssi kapacitu, nicmene narazel sem spis na tu skladku, kdyz jiste bylo jeste v zaruce, pokud to prave nebyl nejakej shit btw: u lekare si uz byl? pusobis velmi nevyrovnane

[BrainLess]

Jenom pro rozsireni obzoru, v linuxu existuje mnoho souborovych systemu. Kdyz vytvaris nejaky souborovy system, existuje prepinac kterym ovlivnis kolik mista ma byt reservovano pro 'roota'. Je to krom jineho kvuli tomu aby system jako takovy fungoval i v pripade ze "uzivatel" vyplaca vsechno volne misto na fs ( o quotach nekdy priste ). Obvykle je to 5% velikosti disku. Taky je si treba uvedomit ze existuje neco jako i-node ( a i kdyz je to nepravdepodobne ) muzes se dostat do situace ze volne misto na disku bude ale system nebude mit volne i-nodes a tim padem na nej nezapises. Jinak pro bezny mgmt "disk-space" nastudovat prikazdy df/du a napriklad find / -size +1G apod.

[QWERTY]

Nainstaluj si BleachBit, pravděpodobně ho máš v repozitáři.

[Terrry344]

Uz som to zazil na Linux Mint. Teraz - riesenie problemov z nekontrolovatelnym narastom logov v Linux Mint 19 a vyssi. Nastartovat do Live DVD distribucie na instalacnom DVD (alebo USB kluci). Po nastartovani Live DVD v terminali zadat prikaz: "sudo passwd root". Dva krat po sebe zadat heslo pre ucet root. System vypise, ze heslo bolo zmenene. Nasledne sa prihlasit v konzole do uctu root cez: "su". Po uspesnom prihlaseni ako "root" zadat "caja". Susti sa prehliadac suborov z opravnenim root. Preklikat sa strukturou suborov do: /var/log. Tam pohladat subory "kern1.log" a "syslog", pripaden "syslog.1" a podobne logy. Prieskumnik Caja vypise za zakliknuty subor aj jeho aktualnu velkost. Vsetky abnormalne velke logy zmazat. Znovu po normalnom nastartovani vzniknu nanovo subory "kern.log" a "syslog". Ale tieto nove logy sa uz nenafukuju a tak nevycerpaju volne miesto na / az na doraz. Linux Mint sa da po tomto normalne nastartovat, pretoze ma volne miesto na /.

[Peter Golis]

Tým že mažeš logy len odďaluješ následok, ale neriešiš príčinu. Kedysi som mal som podobný problém, logy sa mi plnili kvôli web kamere ktorá mala zapnutý debug. Denne vyprodukovala cez 1GB logov. Vypol som debug, a o zvyšok sa postaral logrotate.

Mimochodom, keď ti išlo sudo passwd root, tak si nepotreboval zmenu hesla a potom spustiť su ale stačilo ti rovno spustiť sudo -i .