Dotaz: Došlo volné místo na ROOTu

[Jan Dzít]

Instaloval jsem si distribuci (s 3 těžkotonážními prostředími až po instalaci) na 1TB SSD. Instalátor mi ještě před vyhradil pro / 10GB. Má otázka zní kolik místa mám poskytnout / aby se jen tak nezaplnil? S tím souvisí i podotázka, kolik místa stačí vám, pokud máte dlouhodobě (min. 1/2roku) instalováno alespoň 1 velké desktopové prostředí se spoustou aplikací typu Gimp, LibreOffice, apod.? Nepoužil jsem LV, což by jistě problém řešilo, rád bych se ale bez LV obešel.

---

---

Odpovědi

[Filip Jirsák]

Máte nějaký důvod rozdělovat disk víc, než na /, /boot a případně swap?

[ewew]

bez komentára

selinux všetko vyrieši.

[Andrej]

Sice možná všechno vyřeší, ale nějak nesouvisí s původním dotazem, že ano.

Měl-li to být náznak, že oddělené filesystémy nějak zlepšují izolaci, odpověď je, že nezlepšují. Oddělené filesystémy nenabízí bezpečnostní výhody ve srovnání s jedním jediným. Kdyby měl kernel tak zásadní bug, že by se dalo například utéct z LXC nebo z chrootu nebo jinak eskalovat oprávnění, dostat se k datům z ostatních filesystémů by byla všeho všudy otázka času. Leda že by ty filesystémy byly zašifrované a nebyly by namountované. Jenže … k čemu by vlastně potom byly? Jednou by je někdo namountovat musel. A pak je ten problém stále stejný.

[lertimir]

O izolaci primárně nejde. Z mého pohledu oddělený /home mi dává možnost bez závažných operací přeinstalovat systém, bez toho abych musel zvláště pracovat z uživatelskými daty. Tedy zazálohovat /home a pak jej restaurovat do nového systému. Pokud se rozhodnu, v konfiguraci s odděleným /home, vyměnit distribuci nebo k nové verzi (verzové distribuce) přistoupit tak, že systém reinstaluji, a ne aktualizuji verzi, systém jednoduše přeinstaluji s tím že formátuji oddíly pro / a /boot a /home nechám nedotčený a je to akce na pár minut. Reinstalace systému se společnám prostorem se zachováním uživatelských dat je mnohem náročnější akce. Mit samostatný prostor pro systém a pro uživatele se mi mnohokrát osvědčilo. Jak v případě Win, když už v čase XP jsem použiva C: jen na systém a data měl na D: a dalších oddílech. A stejně tak v linuxovém prostředí.

[Jendа]

Reinstalace systému se společnám prostorem se zachováním uživatelských dat je mnohem náročnější akce.

Moje distribuce třeba tento problém nemá, prostě rozbalím rootfs na souborový systém, kde už třeba /home, /root, /opt a /usr/local jsou a nikomu to nevadí.

[lertimir]

A jak dosáhneš toho, když bys přecházel z jiné distribuce a měl některé věci pojmenované jinak, (třeba v /etc má Centos, Debian, openSUSE konfigurace sítě na jiných místech, webový server někde apache2 jinde httpd, atd.) nebo toho, že tu jinou distribuci potřebuješ nakonfigurovat (mounty v fstab na UUID, třeba). Chápu, že když jseš po letech na Archu nebo podobném distru, máš to odladěné a neuvažuješ ani potenciálně o přechodu, tak asi ti to takto vyhovuje a je to jednoduché. Ale pro kohokoliv kdo potenciálně uvažuje, že by distro změnil v průběhu HW života stroje, je oddělení root a home jednoduchá cesta, jak si takovou změnu do budoucna z jednodušil za cenu pár volných GB. (které už i v případě SSD stojí přibližně 10 Kč za 1G). Takže v případě ssd když si udělá samostatný root, dá mu cca 15GB navíc proti tomu, co potřebuje, stojí ho to cca 150 Kč za rozumnou jistotu pohodlí při změně distra. Podle mne je to dobrý kompromis.

[Jendа]

Žádné /etc nezůstane, vždyť píšu, že smažu všechno kromě /home.

[kyknos]

Naprosty souhlas.

Ja teda navic mam rad svuj home na fyzicky oddelenem disku, proste ho vyndam z pocitace a trada, muzu zvednout kotvy a odplachtit treba do Argentiny. A navic treba v soucasnosti mam root na SSD ale home na pevnem disku, navic v raidu.

[tux]

* Protoze chci mit nektere oddily "nosuid", "noexec", ... apod ? * Protoze chci mit nektere oddily s jinym poctem inode na kb ... ? * Protoze chci mit moznost nektere oddily v pripade potreby jednoduse odmigrovat jinam (na ssh apod) ... ?

Duvodu je hafo.

[Jendа]

* Protoze chci mit nektere oddily "nosuid", "noexec", ... apod ?

nosuid i noexec mi fungují per subvolume.

* Protoze chci mit nektere oddily s jinym poctem inode na kb ... ?

S dnešními FS, které packují malé soubory k sobě?

* Protoze chci mit moznost nektere oddily v pripade potreby jednoduse odmigrovat jinam (na ssh apod) ... ?

Tak tady vůbec nechápu, jak to souvisí s tím, jestli je to samostatný FS.

[Andrej]

Dělení disku na oddíly je zlozvyk z minulého desetiletí. Doporučuji disk nedělit a pak bude prostor vždy k dispozici tam, kde je potřeba. Opravdu je to takhle jednoduché.

Nemá-li člověk swap, stačí jeden jediný oddíl v případě BIOSu, dva oddíly v případě UEFI. (Oddíly to v obou případech musí být a nemůže to být filesystém přímo na disku, protože jinak by z toho firmware nenabootoval. Ale není-li to bootovací disk, pak tam ani oddíly být nemusí.)

Má-li člověk swap, například kvůli uspání do RAM, pak je samozřejmě potřeba mít „oddíl“ na swap. Ale to je lepší zařídit pomocí LVM (proto ty uvozovky) a MBR oddíl nebo GPT oddíl jiný než /boot/efi nechat jen jeden (případně s LUKS uvnitř, aby i swap byl šifrovaný, atp.).

Kdysi ještě platilo, že chce-li uživatel šifrovaný root (/), pak musí mít oddělený /boot, který je nešifrovaný. To už ale dnes dávno neplatí, protože GRUB podporuje LUKS. Jen to může být (naneštěstí stále ještě) trochu nepohodlné, takže si umím představit, že by třeba někdo i dnes upřednostnil nešifrovaný /boot.

Jako filesystém je nejlepší nasadit Btrfs a v něm mít subvolume pro /, /etc, /var, /home (nebo případně pro každý domovský adresář zvlášť, opravdu podle gusta). Pak se dá bez problému

• atomicky snapshotovat a zálohovat každý subvolume zvlášť.
• mít víc distribucí na jednom jediném filesystému — každá bude mít vlastní /, /etc a /var a můžou (byť nemusí) sdílet swap a případně /home. Klíčové je, že není potřeba přiřadit jim diskový prostor předem. Diskový prostor bude vždy k dispozici, když je potřeba.
• kdykoliv přidávat a odebírat subvolumes, případně celé distribuce atd.
• nastavit odlišné mount options pro každý subvolume, podle potřeby, například nodev nosuid pro /home či něco podobného.

Kromě toho má Btrfs ještě spoustu dalších výhod a killer features. Dělení disku předem na oddíly je fakt zlo, které uživatele jen omezuje a dřív nebo později ho dostihne — například způsobem popsaným v dotazu.

[ewew]

Nedelenie nová moda ako ultra super featura. Bez delenia ten systém nebude nikdy bezpečný a selinux si môžu dať za klobuk.

[Jendа]

Můžeš uvést příklady útoků možných díky nerozdělenému disku?

Napadá mě jediný, někdo může odpojovat šifrovaný oddíl, když ho nepotřebuje, aby klíče nebyly v paměti, odkud je někdo může vycoldbootovat. Řekl bych, že tohle ale dělá minimum uživatelů.

[Andrej]

Kromě toho, posledně jmenovaná metoda se dá snadno emulovat pomocí loopbacku (což může být sparse soubor a nemusí předem zabírat místo), případně pomocí encfs (i když encfs není ideální řešení, protože prozrazuje spoustu metadat, například uspořádání adresářů, počty a přibližné velikosti souborů).

[Andrej]

Překvapuje mě jeden častý jev: Někdo si úplně zbytečně rozdrobí svůj diskový prostor na kousky a pak se snaží sám pro sebe hledat zdůvodnění, proč to vlastně udělat. Inu, pro nic za nic.

Oddělené filesystémy neposkytují žádnou bezpečnostní výhodu ve srovnání s jediným. Ve chvíli, kdy je v kernelu zásadní bug kolem eskalace práv nebo izolace virtuálních prostředí, jsou všechny možné konfigurace napadnutelné asi tak stejnou měrou.

Pro „ten systém nebude nikdy bezpečný“ bych prosil citaci. Co je to bezpečný systém? Jak se to pozná? Jak se pozná, když není bezpečný, a jaká přesně rizika pak hrozí? (Ta otázka nežádá výčet, nýbrž přesnou a konkrétní definici relevantní pro tento kontext, tedy pro dělené a nedělené filesystémy.) Kde je důkaz implikace, že systém s jedním filesystémem není nikdy bezpečný?

SELinux je v tomto případě téměř ortogonální záležitost. Nevidím důvod plést dohromady dělení či nedělení filesystémů a SELinux. UNIXové systémy mají, jak známo, jeden jediný adresářový strom, ve kterém jsou vidět všechny namountované filesystémy. SELinux tedy (ne)chrání (ne)rozdrobené filesystémy přesně stejnou měrou, tedy podle konkrétní konfigurace a konkrétního nasazení.

[pavele]

Andreji, mohl bys popsat tvůj způsob použití harddisku?

Já mám / samostatně, protože se mi lépe zálohuje a obnovuje celý malý diskový oddíl.

Kolem 15 GB.

[Jendа]

Andreji, mohl bys popsat tvůj způsob použití harddisku?

Já mám velkou partition s btrfs, kde mám subvolumes pro / a /home. Je to hlavně pro to, abych mohl říct, kdy chci snapshotovat systém, a kdy data.

Pak mám ještě jeden oddíl, s ext4, na kterém mám image virtuálů, protože ty se fragmentují kvůli btrfs CoW (které dřív nešlo vypnout selektivně pro subvolume, možná už to jde).

Já mám / samostatně, protože se mi lépe zálohuje a obnovuje celý malý diskový oddíl.

Nikdy jsem systém nezálohoval jako bitovou kopii, vždycky rsyncuju, taruju atd. soubory.

[Honza]

Treba v Archi jde nastavit "nodatacow" pro Btfrs subvolume...

[Jendа]

Nejde.

[Honza]

Btfrs nepouzivam, vychazel jsem z informaci: https://wiki.archlinux.org/index.php/Btrfs#Disabling_CoW

[Andrej]

Já mám / nesamostatné, protože nechci mít žádné omezení na 15 GB ani na jakoukoliv jinou konstantu. A když root nezabírá celých 15 GB, pak samozřejmě chci, aby všechen nevyužitý prostor byl kdykoliv k dispozici jinde, třeba v /home nebo /var, podle aktuální potřeby.

Zálohování je triviální, protože / je zkrátka obyčejný Btrfs subvolume. Takže prostě udělám snapshot, zazálohuju a hotovo. S obnovením by to bylo podobné, kdybych ho snad (hrůza pomyslet) někdy potřeboval provést. Nic mě přece nenutí zálohovat úplně celý Btrfs zároveň.

[multi]

+1 za Btrfs + subvolume

[Leinad]

Btrfs nedoporučuji, pokud se uživatel nechce stát expertem na Btrfs a chce počítač jen používat. Já jsem si ho dal jen na domácí počítač, naštěstí ne na pracovní a za tu dobu mě potkalo:

 

• Kvůli CoW po aktualizaci došlo místo a odmítl mi počítač nabootovat. Hledal jsem na internetu, jak v záchraném módu promazat pomocí snapper staré snapshoty
• Kvůli CoW nešlo uvolnit místo smazáním souboru.
• Kvůli CoW přejmenování velkého souboru skončilo tím, že došlo místo na disku
• Kvůli komplikované struktuře filesystému a vlastním utilitám pro výpočet volného místa volné místo zjištěné v Dolphin / Nautilus neodpovídalo skutečnému místu. Takže xGB volného místa podle Dolphina a přesto jsem už nenabootoval.
• Použil jsem grafickou utilitku Snapper pro vrácení půlky systému a během vracení to vyměnilo nejspíše dost knihoven na to, že mi spadl systém během vracení
• Nabootoval jsem do readonly snapshotu a udělat z něj normální zapisovací. A byl jsem nadšený, jak to krásně funguje. Než jsem zjistil, že originální snapshot nejde vymazat (snapper na tom vždy spadl, low level btrfs utilita se sudo odmítla kvůli nějakým oprávněním). Takže pak jsem skončil s tím, že uvolnit místo mohu formátem disku

Btrfs tedy doporučuji používat jen pokud mu opravdu dobře člověk rozumí a zná všechny ty případy, které ho mohou rozbít. A nebo pokud mu nevadí, že mu to propálí hromadu času na záchranách počítače.

 

[Jan Dzít]

Použil jsem grafickou utilitku Snapper pro vrácení půlky systému a během vracení to vyměnilo nejspíše dost knihoven na to, že mi spadl systém během vracení

Mě naštěstí jen spuštění utility vytížilo systém na 100%, plán byl jen pomocí toho zkonfigurovat časy záloh aby nedocházelo k častému vytěžování, to bylo ale na 13.2.

Nabootoval jsem do readonly snapshotu a udělat z něj normální zapisovací. A byl jsem nadšený, jak to krásně funguje. Než jsem zjistil, že originální snapshot nejde vymazat (snapper na tom vždy spadl, low level btrfs utilita se sudo odmítla kvůli nějakým oprávněním). Takže pak jsem skončil s tím, že uvolnit místo mohu formátem disku

Nápodobně, prroto, jsem při instalaci Leapu poprvé zvolil EXT4. Teď stále váhám, jestli ho nepoužít znovu, i když to bude spíš jen o nedostatku článků jak se s tím pracuje aby z toho použití bylo více výhod než naopak.

[Andrej]

Tohle je výčet problémů z roku 2009. Dnes máme rok 2016.

[Leinad]

Tohle je výčet problémů z openSUSE 13.2 z roku 2014 až 2016

[Leinad]

Poprosil bych upřesnit co z toho považujete za neplatné v současnosti

[Aleš Kapica]

Kdybys byl použil číslovaný seznam, bylo by to jednodušší. Nu ale pokusím se to vzít popořadě:

Je zvláštní, že když ti došlo místo, že ti po restartu systém s Btrfs nenabootoval, protože Btrfs si vždy udržuje část, kterou nechává jako rezervu pro takový případ. Po rebootu by měla být k dispozici - nebo alespoň při namountování přes ramdisk, nebo live CD.

Btrfs není Ext4. Takže myslet si že uvolním místo tím že něco smažu je silně naivní - obzvláště, pokud používám snapshoty.

Pokud soubor "pouze" přejmenuješ, tak záleží co k tomu použiješ. Není přejmenování jako přejmenování - některý soft to udělá tím, že vytvoří kopii souboru s novým jménem a pak ten původní smaže, místo toho aby udělal skutečně pouze akci rename.

To že Dolhin ukazuje blbosti a ne skutečně obsazené místo je problém Dolphinu, nikoliv Btrfs - to má na to vlastní tool. A je to z toho důvodu, že objem reálně uložených dat může být diametrálně odlišný od toho co se vypočítá příkazem 'du'.

Pokud nechceš mít problémy, tak se nauč používat konzolové nástroje. Grafické utilitky jsou většinou jejich pouhá grafická nadstavba, která může mít své mouchy.

Závěr: Nejdřív mysli a pak aplikuj. Je vždycky lepší si nejprve o věci zjistit co nejvíc informací, než se do ní bezhlavě pouštět a pak se divit.

[Leinad]

Ale vždyť jsem psal: "Btrfs tedy doporučuji používat jen pokud mu opravdu dobře člověk rozumí a zná všechny ty případy, které ho mohou rozbít." Všechno, co jsi vyjmenoval je z toho, že máš s ním zkušenosti a víš, že nemůžeš přejmenovávat soubor v Krusaderu, koukat se na volné místo v Dolphinu, mazat soubory pro uvolnění místa, atd.

S tím volným místem, jestli tam je nějaká rezerva, tak je to buď relativně nové, nebo jsem něco (ne)zaškrtnul při instalaci. Ale opravdu mi partition šla až nadoraz, takže bootoval jen nějaký záchraný režim a klasický boot neproběhl. A v záchraném režimu jsem si ručně mazal pomocí snapperu staré snapshoty.

[lertimir]

Myslím, že hlavní rozdíl je způsob použití. Je to jako rozhovor mezi tuningářem, který si se svým autem hraje a má ho vyladěné, tlumiče, kotouče, přebroušené kanály v motoru a pod., a člověkem který používá auto na odvezení dětí do školy, dopravu do práce a převezení věcí, když je třeba. Pak skoro jediné co je podstatné, aby ráno, když otočí klíčkem bylo auto funkční a jelo a bez toho, aby se o něj musel starat víc než výměnu oleje a standardní prohlídky. OpenSUSE a distra jako Mint, Ubuntu, nebo možná i Fedora jsou distra na dopravu do práce, Arch nebo Debian sid jsou naopak distra pro tuningáře. A to že tvurci opensuse to celekm zmrvili, když nahodili snapshoty každou hodinu a nenastavily nějaké agresivnější odmazávání třeba když dochází místo.

To že Dolhin ukazuje blbosti a ne skutečně obsazené místo je problém Dolphinu, nikoliv Btrfs - to má na to vlastní tool. A je to z toho důvodu, že objem reálně uložených dat může být diametrálně odlišný od toho co se vypočítá příkazem 'du'.

To je právě naopak. to že dolphin nebo df ukazuje blbosti je hloupá a nepříjemná arogance tvůrců btrfs. pododobně jako odstřelení /var/messages je arogance lidí od systemd. Není podstatné aby seděl udaj obsazenosti s du. To nesedí ani jinde. Ale důležité a podstatné je, aby FS odpověděl smyslupným číslem na dotaz, kolik má volné místo. protože to znamená odhad, kolik ještě tam případně mohu zapsat. Všechny FS tento udaj symslupně odpoví standardním dotazem ale tvurci btrfs prohlásili, my na to kašlem a máme svoje nástroje. Tím vlastně říkají, že kašlou na všechny, kdo ten udaj používají ať již v grafických nebo textových nástrojích. A vůbec nic to nemění na tom, že ten údaj může být třeba minimální smysluplný odhad, že v mnoha případech se tam pak zapíše více, nebo průměr, kdy když budu zapisovat data bude klesat mnohem rychleji než co jsem zapsal, ale to, že FS hlási 15% místa, ale systém spadne proto nezapíše ani sektor je blbě.

Přesto btrfs používám, protože některé jeho vlastnosti jsou pro mne důležitější než problém s reportem místa. Nicméně pořád to považuji za hloupou aroganci tvůrců.

[Peter Golis]

pododobně jako odstřelení /var/messages je arogance lidí od systemd.

Linux používam vyše desaťročie, ale o /var/messages som ešte nepočul. Ak sa jednalo o textové logy vo /var/, tak tie má na starosti syslog a ten bez problémov koexistuje s systemd. Ak si si ho nenainštaloval, tak ho nepotrebuješ. A zvalovať to na chybu niečoho iného je mierne infantilné.

[Ruža Becelin]

/var/log/messages je zalezitost CentOS/RHEL/Fedora, syslog ma sice na starosti soubory pod /var/log, ale treba v posledni Fedore uz neni ani nainstalovany, musel jsem pridat rsyslog a upravit journald.conf, aby to fungovalo jak v RHEL 7.

[Peter Golis]

/var/log/messages je zalezitost CentOS/RHEL/Fedora,

To je rôzne. Niektoré distribúcie to majú napríklad ako /var/log/syslog. Ale ako /var/messages som to ešte nevidel.

syslog ma sice na starosti soubory pod /var/log, ale treba v posledni Fedore uz neni ani nainstalovany, musel jsem pridat rsyslog a upravit journald.conf, aby to fungovalo jak v RHEL 7.

V ktoromsi Ubuntu vyhodili syslog ešte pred zavedením SystemD, takže som si ho doinštaloval. A úpravu journald.conf som nikdy nemusel robiť aby sa mi chytil syslog. Takže naozaj za to nemôže SystemD, ale balíčkovači metabalíkov ktorí vyhodia voliteľné balíky a vytvárajú východziu konfiguráciu. Práve mám pod rukami napríklad Ubuntu 16.04, a v ňom má SystemD všetky položky zakomentované, a funguje mi bez problémov preposielanie na syslog (rsyslog).

[lertimir]

Myslel jsem /var/log/messages a nebo obdobný textový log v jiných distrech.

[Peter Golis]

Pohoda. U ľudí ktorí sa boja noviniek je zvýšená pravdepodobnosť preklepov.

[kyknos]

novinka je hezky eufemismus pro regresi :)

[k3dAR]

Peter je totiz zastance hranateho volantu a trojuhelnikovych kol ;)

[Peter Golis]

To je pravda. S logovaním do /var/messages som za tých pár desaťročí v IT nikdy nerátal.

[_]

Ještě vysvětli pojem rátal. S tím jsem se ještě nesetkal.

[Peter Golis]

SLEX.

[_]

Aha. Proč vlastně nepřejdete na normální spisovnou češtinu? Udělat si z nářečí státní jazyk je takové dětinské.

[k3dAR]

souhlasim s prvni vetou... druha veta je jen dukaz ze neumis cist, protoze preklep uz to byl davno opraven, vsimni si toho casu, aaano?

[Peter Golis]

Nesúhlasím, keďže presne na to som reagoval. Ale to by si nesmel mať poruchy pozornosti z nadmerného ožívania neurotoxínov. Vytiahol som to len ako excelentný príklad tých tvojích hranatých kolies a čojaviem čoho ešte čo ti behá po rozume keď máš stavy.

[k3dAR]

aaano

[_]

K čemu je dobrý filesystem, kde nelze uvolnit místo tím, že něco smažu?

[Filip Jirsák]

K ukládání souborů.

[k3dAR]

a jak tam ulozis soubory kdyz se nevejdou? kdyz smazanim souboru misto neuvolnis? pripojenim prazdneho dalsiho hdd do poolu? :)

[kyknos]

copak smazat, horší je, že občas nejdou přečíst (nebo aspoň nešly když se mi to kdysi jako default nainstalovalo v suse, od té doby jsme to nepoužil, a nehodlám) :D

[Filip Jirsák]

Když je disk plný potřebných souborů, a potřebuji uložit další soubor, samozřejmě musím připojit další úložiště. Nebo vy, když vám dojde na disku místo, mažete nějaké potřebné soubory?

To, že se mazáním nemusí uvolnit místo, je vlastnost všech souborových systémů, které si ten název zaslouží. To, že smažete nějaký soubor, totiž neznamená, že se mohou smazat i jeho data – může na ně být odkaz z jiného souboru, ze snapshotu… Data se smažou teprve tehdy, když se smažou i všechny odkazy. Fungují tak všechny souborové systémy (ext2/3/4, XFS, btrfs, ReiserFS, Reiser4, XFS, JFS, NTFS), protože jinak to s vícenásobnými odkazy na soubor prostě rozumně udělat nejde.

Z používanějších „souborových systémů“ máte jedině u FAT (pokud ho řadíte mezi souborové systémy) v případě smazání souboru jistotu, že se uvolní místo.

[k3dAR]

kdyz je disk plny potrebnych souboru tak jde o jinou situaci nez byla rec ;) btw: nehjhorsi je jirsakfs, to je samej nepotrebnej soubor a stejne to nejde smazat...

[Filip Jirsák]

Řeč byla o plném disku. Pokud máte na disku nějaké nepotřebné soubory, nevím, proč je nesmažete hned, a čekáte, až dojde volné místo. Jinak pokud je ten soubor opravdu nepotřebný, tak asi můžete smazat všechny odkazy na něj, a tím se místo na disku uvolní.

[vážná řeč]

Tím chcete říct, že pokud odkaz je součástí i snapshotu, místo se bez smazání celého toho snapshotu neuvolní? Ačkoliv vím, že snapshot obsahuje jen adresáře ve kterých se obvykle neukládají velké soubory a navíc obsahují jen rozdílové verze.

[Jendа]

Tím chcete říct, že pokud odkaz je součástí i snapshotu, místo se bez smazání celého toho snapshotu neuvolní?

Mně se to na btrfs uvolňuje, teď jsem to vyzkoušel.

Ačkoliv vím, že snapshot obsahuje jen adresáře ve kterých se obvykle neukládají velké soubory

Já teda používám snapshoty pro zálohování, to znamená, že mám stroj, na který každý den rsyncnu / z několika jiných serverů a pak udělám snapshot (a staré snapshoty po půl roce mažu). Takže snapshot obsahuje velmi velké soubory…

[vážná řeč]

Ačkoliv vím, že snapshot obsahuje jen adresáře ve kterých se obvykle neukládají velké soubory a navíc obsahují jen rozdílové verze.

Tak nevím, je to jinak, snapshot1 zabírá 5.5GiB ale snapshot66 už 5.6GiB, znamená to, že jsou to kompletní obrazy, bohužel se duplikují i celé adresáře /usr/bin a /lib které vytváří ty GiBs, naštěstí to neukládá /home nebo /var/log.

[Jendа]

Co to je za FS, jak snapshoty děláš a jak zjišťuješ velikost? btrfs i ZFS pochopitelně drží jenom změněné bloky (pomocí CoW).

[vážná řeč]

BTRFS, snapshoty vytváří snapper a zjišťuju to Dolphinem (Super user mode) a to vše v OpenSUSE Leap

[Filip Jirsák]

Špatně interpretujete význam toho „zabírá“. To znamená, že v daném snapshotu jsou data o dané celkové velikosti – ale data, která jsou stejná ve více snapshotech, jsou na disku jenom jednou. Pokud budete mít v souborovém systému 1 GiB dat, vytvoříte z něj snapshot a do něj zapíšete nový soubor o velikosti 0,5 GiB, budou oba snapshoty dohromady na disku zabírat 1,5 GiB, protože to původní nezměněné 1 GiB budou sdílet.

[Filip Jirsák]

Ne. Místo se uvolní, když se odstraní všechny odkazy na soubor. Třeba na ext4 mohou být odkazy na soubor pevné odkazy (hardlinky) na souborovém systému a odkazy v běžících programech. V souborovém systému se snapshoty (třeba btrfs) mohou ty pevné odkazy (hard linky) být uložené v různých snapshotech. Takže pokud chcete data souboru smazat na btrfs, musíte odstranit odkaz ze všech snapshotů (ale snapshoty můžete ponechat).

[Andrej]

Všechno. Poslední výskyt nejdéle přežívající z uvedených chyb jsem viděl kolem roku 2012 a to nebyl zrovna moc aktuální kernel.

[Jendа]

Mně na mém bloated systému zabírá / 20 GB.

[Jan Dzít]

Dobře, vytvořím tedy LV s minimální velikostí 20GB pro /. Ne nepotřebuji mít disk rozdľlený více jak pro /, /boot (vyhovuje mi šifrovaný) a swap (hibernovat nemusím, systém nabíhá do cca 15s když nepočítám psaní hesla pro šifrovaný /boot).

[Filip Jirsák]

Pokud disk nepotřebujete mít rozdělený, tak jej nedělte. Ušetříte si tím dotaz za půl roku, co máte dělat s tím, že máte na rootu 20 GB a je to málo. Vytvořte si /boot a swap a celý zbytek disku použijte pro /.

[Jan Dzít]

OK, díky, stejně to nechám až na zítra.

[Jan Dzít]

Příloha:

• autoprepare-leap.png (85023 bytů)

No tak takhle mi to instalátor rozdělil, žádné LV, žádný šifrovaný / (předtím jsem to poplet měl jsem šifrovaný /, ne /boot). Je to tedy stále omezující a měl bych to znova překopat na to LV s jediným oddílem, protože to má zase pevnou velikost a špatně by se to zálohovalo? Proč mi zvolil XFS pro /home?

[Jan Dzít]

Jo a takhle vypadá fstab.

UUID=b9004a1e-a8f9-451e-bc26-ebe474735e25 swap swap defaults 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 / btrfs defaults 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /boot/grub2/i386-pc btrfs subvol=@/boot/grub2/i386-pc 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /boot/grub2/x86_64-efi btrfs subvol=@/boot/grub2/x86_64-efi 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /opt btrfs subvol=@/opt 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /srv btrfs subvol=@/srv 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /tmp btrfs subvol=@/tmp 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /usr/local btrfs subvol=@/usr/local 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/crash btrfs subvol=@/var/crash 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/lib/libvirt/images btrfs subvol=@/var/lib/libvirt/images 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/lib/mailman btrfs subvol=@/var/lib/mailman 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/lib/mariadb btrfs subvol=@/var/lib/mariadb 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/lib/mysql btrfs subvol=@/var/lib/mysql 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/lib/named btrfs subvol=@/var/lib/named 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/lib/pgsql btrfs subvol=@/var/lib/pgsql 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/log btrfs subvol=@/var/log 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/opt btrfs subvol=@/var/opt 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/spool btrfs subvol=@/var/spool 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/tmp btrfs subvol=@/var/tmp 0 0
UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /.snapshots btrfs subvol=@/.snapshots 0 0
UUID=4b4eadb7-7ffd-4a20-a497-4b5d32f6d393 /home                xfs        defaults              1 2

[pavele]

Dokonce ani /boot ani swap není potřeba samostatně, i když se to doporučuje (odzkoušeno na CentOS 7). Prostě každý si to nastavuje podle svých potřeb...

[ajp]

K čemu všemu je dobrý mít /boot zvlášť?

[Aleš Kapica]

Třeba k tomu, že si tím zvýšíš šanci se strojem něco udělat i v situaci kdy se mu rozesere kořenový souborový systém.

[Filip Jirsák]

Já /boot mountuji jen při aktualizaci jádra, takže se tím snižuje riziko, že ho nějak poškodím a systém už nenabootuje. A také mám /boot udělaný tak, aby z něj vždy šlo nějaké jádro nabootovat a dávám tam nějaký minimální shell nebo busybox. Pořád lepší, když se do vzdáleného počítače přes KVM dostanu alespoň do shellu, než když nenabootuje vůbec a musím řešit boot ze sítě.

[lazywriter]

Taky k tomu byly historicke důvody. Byly doby, kdy nemuselo být jisté, že půjde nahrát jádro z vyšších sektorů (hranice si už nepamatuju). Takže se dávala /boot partition na začátek disku.

[lertimir]

Já mám root na 40G a obsazeno je asi 25G, ale vlastní data FS jsou asi 7G, zbytek jsou snapshoty btrfs filesystému.

[Bedňa]

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        20G  7.4G   11G  41% /
/dev/sda2       343G  264G   62G  81% /home

Takto to mám už roky. Používam fakt dosť aplikácií, tie najväčšie sú asi Libre Office, GIMP, Blender, Inkscape, FireFox, Tor Browser, FileZilla viacero vývojových prostredí ako QT SDK, Lazarus, Geany, Gambas ... a množstvo všelijakého užitočného softvéru, a ako vidíš systém je zaplnený len na 41%.

[Jan Dzít]

No tak já to měl zhruba 3měsíce a jen /usr měl 6.4GB a to tam nebyla ani žádná hra (nativní, wine, steam), jen KDE5, GNOME, Cinnamon a třeba Firefox, Chrome, Opera36, Vivaldi, Libre Office, GIMP a už jen ty menší než třeba VLC. V keši jsem měl jen instalátory Chrome a Vivaldi (cca 300Mib), jinak nic tam kešováno co bylo instalováno nebylo.

[Bedňa]

Takže máš celkovo cca ako ja 7,4GB, takže ostáva otázka, či po troch mesiacoch používania chceš nainštalovať ďalších 10GB programov. Pri mojej konfigurácií budeš mať aj tak stále 4GB volného miesta na systémovej partícií. Samozrejme počítam, že po troch mesiacoch už tam väčšinu obľúbených programov máš a ten priestor nezaplníš.

Čo sa týka hier, tie sa už dlhšiu dobu väčšinu inštaľujú do home, ak nepočítam tie staršie ktoré sú v zdrojoch softvéru.