Havarie po aktualizaci U20-mate BTFSR(misto), RSYNC obnoveni ze zalohy nefunkcni

[miro_]

Po posledni aktualizaci systemu havarovala aktualizace pro nedostatek mista na BTFSR partition.
Nechce se mi verit, ze by pred jejim spustenim tam bylo malo mista. Pred spustenim aktualizace
jsem delal zalohu do BTFSR a bylo tam asi 10GB mista ! Kdyz jsem stopl neuspesnou
aktualizaci, kde bylo ve vypisu logu indikovano mnoho neuspesnych operaci, restartem tak tam zbylo asi 200MB.

Obnoveni stavu z RSYNC zaloh (12/2020 a 2/2021) pres 'timeshift' je nefunkcni.
Ve vypisu logu pri bootovani je videt spoustu "FAILED to start ..."   napr. 'login service', 'virtualbox.service' atd.
Pokud z nasledneho zastaveni na prazdne obrazovce, kdy zmizi vypis log a poslu to dale pres "ctrl-alt-del"
tak se to zastavuje na nekolika "snap daemonech" az to prejde to restartu PC.
Po obnoveni z 'timehift' ma BTFSR obsazeno 11.2GiB z 39.6GiB

Zkusil jsem z takto nefunkcniho systemu vytahnout aktualni logy, kdyz jsem se pokousel system spustit.
Zipovany stav ma asi 440KB. Zkusil jsem jej prilozit, pokud by se na ne nekdo podival.

-Z cele situace uzivani 'timeshift' pro zalohy mam spatny pocit, protoze pred koncem 2020 se mi takto
bez problemu podarilo preinstalovat poskozeny system vlivem nejakych pokusu.
(Nova instalace min. systemu do BTFSR, nasledna instalace 'timeshift' a obnoveni stavu z RSYNC zalohy)
Proto jsem tomuto systemu zaloh dosud veril.

-Ma smysl uchovavat starsi RSYNC zalohy ?

[juwa2]

S tím místem na btrfs partition je to trošku složitější. Každopádně je dobré jednou za čas udělat balance. Tím se uvolní částečně obsazené bloky.
V opačném případě se zmenšuje volné místo a není zdánlivě jasné kam jakoby "mizí" (neplatí rovnice total = used + free).
Zjištění místa:

Kód: [Vybrat]

btrfs filesystem df /
#nebo
sudo btrfs filesystem usage /

Balance (lze provádět z běžícího systému):

Kód: [Vybrat]

sudo btrfs balance start -dusage=90 -v /
sudo btrfs balance start -musage=50 -v /

Jinak tento způsob záloh používám bez potíží dlouhá léta. Možnou příčinu problémů bych viděl ve fyzickém stavu disku (sektory) nebo porušeném filesystému (jednu za čas nutno zkontrolovat/opravit pomocí fsck).

Rsync zálohy probíhají na úrovni souborů. Důvod selhání obnovy buď disk/fs viz výše nebo chybně provedená záloha.
K obnovení rsync záloh nepotřebuješ ani Timeshift, stačí použít příkaz rsync který soubory zkopíruje kam libo.

Kód: [Vybrat]

sudo rsync -aP /path/to/backup/ /path/to/restore/to/
Pokud je záloha zdravá, její uchování smysl má. Navíc z rsync zálohy lze snadno vykopírovat i jednotlivé soubory.

Další způsob zálohy je Clonezilla či Rescuezilla. Probíhá na bázi sektorů. Umí zálohovat i btrfs, na obnoveném oddíle jsou zachovány i všechny
btrfs snapshoty.

Rovněž lze použít i obyčejný TAR s parametrem p

Kód: [Vybrat]

#záloha (z běžícího syst.)
sudo tar -cvpzf system-backup.tar.gz --one-file-system /

#obnova (z live)
sudo mkdir /media/bak
sudo mount /dev/sdXY /media/bak
sudo tar -xvpzf /path/to/system-backup.tar.gz -C /media/bak --numeric-owner

Snap daemon nemá se zálohou/obnovou nic.  Pokud byl systém v okamžiku zálohy funkční, musí být funkční i po obnově této zálohy - to je jasná logika...

Neověřená záloha je celkem nanic, až je jí nejvíce potřeba, najednou se zjistí, že není funkční.  Zálohy se ověřují provedením nevynucené obnovy. Pokud proběhne OK, lze tuto zálohu považovat za ověřenou/plně použitelnou do budoucna.

Spousta uživatelů zvládne "jakousi" zálohu vytvořit, s její (úspěšnou) obnovou už to bývá horší (neumí to, nikdy to nedělali atd.).
Závěr:  Pravidelně kontrolovat stav disků. Kontrolovat/udržovat filesystém. Btrfs snapshoty nesmí být (už jenom z důvodu "odejítí" disku) jediným způsobem zálohy, další možnosti viz výše. Pak k žádné krizové situaci nemůže dojít.

-----------------------------
Pokud na systému btrfs dojde místo (v důsledku přidávání dalších a daších souborů), tak fs v podstatě zkolabuje, protože už nemá prostor pro svoje vlastní operace (btrfs-transactions, btrfs-clean) zvláště pokud je OS násilně ukončen.
Pak bych doporučil nabootovat live a filesystem se pokusit nejprve opravit (fsck) a uvolnit nějaké místo (třeba smazáním starých snapshotů).
Potom doinstalovat (do live) Timeshift a provést obnovu některého z posledních snapshotů.

Na každém fs s OS je rozumné udržovat cca 1/4 volného místa (průběžně odstraňovat nepotřebné věci, staré kernely - lze to řešit i automaticky skriptem spouštěným cronem). Je to užitečné kvůli životnosti disků, zabránění poklesu rychlosti a zejména předejítí tomu aby mohla nastat výše uvedená situace...

[singularis]

Situace s přeplněným btrfs oddílem jsem nějakou dobu zkoumal/a a doporučuji btrfs nepoužívat pro systémový (kořenový) oddíl; použitím ext4 si uživatel ušetří spoustu starostí. Btrfs je podle mě ale vhodné pro domovské adresáře (/home) a pro uživatelská data.

V případě, že opravdu dojde místo, se může stát, že btrfs balance se zasekne. V takovém případě se systém souborů vynuceně přepne do režimu „jen pro čtení“ (což je katastrofa, pokud jde o kořenový oddíl...), takže už z něj pak nelze ani nic mazat. Tuto situaci lze vyřešit následujícím způsobem:

1. Odpojit souborový systém a připojit ho s parametrem „skip\_balance“ (ten zabrání, aby se znovu spustila přerušená operace „balance“ a vynutila přechod do režimu jen pro čtení).
2. Přidat k souborovému systému pomocné blokové zařízení pro zvýšení kapacity (může to být např. flash disk, malý oddíl vytvořený v LVM nebo soubor jako „loop-zařízení“) — alespoň 2 GB. (Příkaz „btrfs device add“ — viz manuálové stránky.)
3. Smazat nějaké snapshoty, velké soubory apod.
4. Znovu spustit brtfs balance a počkat, než doběhne.
5. Odebrat ze souborového systému pomocné blokové zařízení.

Ale není to postup, který by mohl provádět začátečník, a dost pochybuji, že k tomu existuje nějaké GUI...

[juwa2]

1. Podle mě je to přesně naopak - systémový oddíl ano, /home spíše ne, tam to takový význam nemá a třeba pro oddíl s filmy bych to používat rozhodně nechtěl, to bych se místa nedopočítal.  A nedávno na btrfs jako vých. přešla např. Fedora...

2. Balance (a obecně jakoukoli defragmentaci) nelze spouštět na zcela plném oddíle, bloky není kam přesouvat, to je snad každému jasné. Použítí balance je míněno jako preventivní - až se systém kousne, je už pozdě...
Takže závěr platí stále stejný = udržovat volné místo + občas fsck + balance, není to tedy až tak náročné...

Spousta uživatelů ale bohužel vůbec netuší, co všechno jim na disku (zbytečně) zabírá místo a začne to řešit až je pozdě. Naprosto typický je mrak starých kernelů nebo .deb balíků v apt cache či množství objemných logů (journal).
Přitom na základní věci stačí třeba Ubuntu Cleaner nebo Bleachbit.

[miro_]

Dekuji za zajimave reakce. Jeste jsem nestihnul Vase odpovedi dukladne prostudovat a stravit.

Doplnuji jeste mozna nekolik informaci, kteryma jsem nechtel uvod tohoto vlakna zatezovat.

U20-mate je solo SSD SU630 480GB, ktery jsem si vyhradil na overovani mnou uzivanych aplikaci tohoto OS.
Je na nem pouze linux. Na pocatku jsem nechal nejake NTFS datove oddily pro jine zalohy.
Pro Linux je vyhrazena extended cast 293GB. BTRFS 42GB (dle nejakych vlaken z 2018 tohoto fora)
je na jejim pocatku, dale nasleduje oddil pro home a data a na konci swap.

 - Ma zde smysl pred novou instalaci BTRFS zvetsit a na kolik ?   
   
SSD byl koupen loni na konci leta, je uzivan obcas a ma najeto dle 'smart' mene nez 14hod !

Zalohy RSYNC byly delany na HDD 2T urceny pro zalohy pri koupi noveho PC rovnez z konce lonskeho leta.
Dle 'smart' ma najeto asi 3 mesice.
HDD je premistovan mezi PC (uzivam AKASA boxy) a prevazne byl umisten a uzit v tomto novem PC
na ukladani neprohlednutych poradu stahovanych z TV tuneru. 
Je zde pro mne zajimavost. Na tomto PC pro multimedialni akce byl porizen interni SSD s WIN10.
Z ruznych duvodu bylo a je uzito jen obcas. Jako hlavni OS je uzivan U18-mate spousteny z legacy rezimu biosu.
U18 ma pristup do obou disku pouze po jejich nalogovani. Pritom SSD s WIN10 ma dle 'smart' najeto
nekolik dni zatim co HDD 3 mesice srovnatelne s chodem SSD s U18.

 - Lze nejak omezit pristupy na HDD i kdyz neni v U18 nalogovan ?

Jeste se vratim k nefunkcnimu bootu U20 po obnoveni.

Pri prechodu v boot do "Advanced option do Ubuntu" jsou po obnoveni
dve verze jadra 5.4.0-58 a 5.4.0-56. Pokud vstoupim do 'recovery mode' kterehokoli
a spustim 'fsck' vraci err code s hlasenim:
'/usr/sbin/fsck.btrfs: UUID=... does not exist'
'Job for systemd-remount-fs.service and joutnalctl -xe' for details

Spusteni 'dpkg' vraci:
Traceback (most recent call last):
  File "/usr/li/python3/dist-packages/DistUpgrade/dist-ubgrade.py", line 8, in <module>
    sys.exit(main())I polozka menu 'grub' rve cca.:  'cannot create' ... 'Read-only file system' !
a dalsi podobne dve chyby ...
na konci:
  OS Error:[Errno 30] Read-only file system: '/var/log/dist-upgrade/main.log.partial
(muze byt v tomto opisu ze scr terminalu nejaky preklep !)
I polozka menu 'grub' rve cca.:  'cannot create' ... 'Read-only file system' !

singularis  mohlo by to mit souvislost ?

- Neni mozne ze zde  uvedenho rici, v cem  byly posledni zalohy udelany spatne ?

Jeste poznamka k prilozenemu zipu logu-boot nefunkcniho systemu.
Bylo zajimave, ze z logu boot nefunkcniho systemu ze spusteneho live systemu
 jsem musel nektere obsahy souboru si kopirovat na pripojenou USB-flash pres jejich edici.
 Jsou to logy uvedene pod jmenem 'jmeno_log.log' v pripojenem zipu.
 V OS spustenem z live i jako 'spravce' to neslo primo kopirovat.

[singularis]

Nerozumím, co je to „nalogovat“ pevný disk. Pevný disk se dá připojit (buď USB kabelem, pokud je v AKASA boxu, nebo SATA kabelem sám o sobě) a zapnout; v systému pak můžeš připojovat oddíly na tom disku, ale to už je něco jiného.

- Lze nejak omezit pristupy na HDD i kdyz neni v U18 nalogovan ?

Omezit přístupy na HDD lze např. následujícími způsoby:

• Odpojit HDD od počítače (nečekaně  ).
• Odpojit HDD od napájení.
• Zakázat port v BIOSu (zejména SATA, ale lepší BIOSy by to měly umět i s USB porty).
• Zakázat přístup parametrem jádra (jen pro pokročilé uživatele).

  OS Error:[Errno 30] Read-only file system: '/var/log/dist-upgrade/main.log.partial
(muze byt v tomto opisu ze scr terminalu nejaky preklep !)
I polozka menu 'grub' rve cca.:  'cannot create' ... 'Read-only file system' !

singularis  mohlo by to mit souvislost ?

Mohlo, ale úplně jisté to není. „Read-only file system“ to může hlásit i tehdy, pokud pracuješ s pododdílem jen pro čtení (read-only subvolume). Přesněji to zjistíš příkazem:

Kód: [Vybrat]

findmnt / | cat(Za „/“ dosaď cestu přípojného bodu tvého btrfs filesystemu.)

Pokud se ve sloupci „OPTIONS“ ukáže „ro“, je to ten problém a budeš muset použít moje řešení (nebo celé btrfs znovu zformátovat). Pokud se tam ukáže „rw“, je to něco jiného.

[singularis]

1. Podle mě je to přesně naopak - systémový oddíl ano, /home spíše ne, tam to takový význam nemá a třeba pro oddíl s filmy bych to používat rozhodně nechtěl, to bych se místa nedopočítal.  A nedávno na btrfs jako vých. přešla např. Fedora...

U /home se mi btrfs velice osvědčilo; mohu si tak z některého domovského adresáře udělat pododdíl (subvolume), ten naklonovat (snapshot) a při každém startu systému daný domovský adresář (skriptem) smazat a nahradit novým klonem snapshotu, tím pádem se při každém startu smažou všechny změny provedené z daného uživatelského účtu (na ext4 by totéž nešlo jinak než obrovským kopírováním).

Moje zkušenosti jsou takové, že systém jako takový se mi „rozbije“ jen zřídka, naopak se mi už minimálně dvakrát „rozbil“ domovský adresář, protože nějaká aplikace někam do konfigurace zapsala nějaké nesmysly a něco se tím úplně pokazilo. Do systémových adresářů běžné aplikace zapisovat nemohou, takže tam se to tak snadno nepokazí.

Velká výhoda ext4 je, že když dojde místo, tak prostě smažeš nějaký velký soubor a hned máš spoustu volného místa. Btrfs je v takové situaci příliš „inteligentní“, takže si bude stěžovat něco ve smyslu: „Nemám dost volného místa, abych mohlo smazat ten soubor.“

[juwa2]

Dekuji za zajimave reakce. Jeste jsem nestihnul Vase odpovedi dukladne prostudovat a stravit.

Doplnuji jeste mozna nekolik informaci, kteryma jsem nechtel uvod tohoto vlakna zatezovat.

U20-mate je solo SSD SU630 480GB, ktery jsem si vyhradil na overovani mnou uzivanych aplikaci tohoto OS.
Je na nem pouze linux. Na pocatku jsem nechal nejake NTFS datove oddily pro jine zalohy.
Pro Linux je vyhrazena extended cast 293GB. BTRFS 42GB (dle nejakych vlaken z 2018 tohoto fora)
je na jejim pocatku, dale nasleduje oddil pro home a data a na konci swap.

 - Ma zde smysl pred novou instalaci BTRFS zvetsit a na kolik ?   
   
SSD byl koupen loni na konci leta, je uzivan obcas a ma najeto dle 'smart' mene nez 14hod !

Zalohy RSYNC byly delany na HDD 2T urceny pro zalohy pri koupi noveho PC rovnez z konce lonskeho leta.
Dle 'smart' ma najeto asi 3 mesice.
HDD je premistovan mezi PC (uzivam AKASA boxy) a prevazne byl umisten a uzit v tomto novem PC
na ukladani neprohlednutych poradu stahovanych z TV tuneru. 
Je zde pro mne zajimavost. Na tomto PC pro multimedialni akce byl porizen interni SSD s WIN10.
Z ruznych duvodu bylo a je uzito jen obcas. Jako hlavni OS je uzivan U18-mate spousteny z legacy rezimu biosu.
U18 ma pristup do obou disku pouze po jejich nalogovani. Pritom SSD s WIN10 ma dle 'smart' najeto
nekolik dni zatim co HDD 3 mesice srovnatelne s chodem SSD s U18.

 - Lze nejak omezit pristupy na HDD i kdyz neni v U18 nalogovan ?

Jeste se vratim k nefunkcnimu bootu U20 po obnoveni.

Pri prechodu v boot do "Advanced option do Ubuntu" jsou po obnoveni
dve verze jadra 5.4.0-58 a 5.4.0-56. Pokud vstoupim do 'recovery mode' kterehokoli
a spustim 'fsck' vraci err code s hlasenim:
'/usr/sbin/fsck.btrfs: UUID=... does not exist'
'Job for systemd-remount-fs.service and joutnalctl -xe' for details

Spusteni 'dpkg' vraci:
Traceback (most recent call last):
  File "/usr/li/python3/dist-packages/DistUpgrade/dist-ubgrade.py", line 8, in <module>
    sys.exit(main())I polozka menu 'grub' rve cca.:  'cannot create' ... 'Read-only file system' !
a dalsi podobne dve chyby ...
na konci:
  OS Error:[Errno 30] Read-only file system: '/var/log/dist-upgrade/main.log.partial
(muze byt v tomto opisu ze scr terminalu nejaky preklep !)
I polozka menu 'grub' rve cca.:  'cannot create' ... 'Read-only file system' !

singularis  mohlo by to mit souvislost ?

- Neni mozne ze zde  uvedenho rici, v cem  byly posledni zalohy udelany spatne ?

Jeste poznamka k prilozenemu zipu logu-boot nefunkcniho systemu.
Bylo zajimave, ze z logu boot nefunkcniho systemu ze spusteneho live systemu
 jsem musel nektere obsahy souboru si kopirovat na pripojenou USB-flash pres jejich edici.
 Jsou to logy uvedene pod jmenem 'jmeno_log.log' v pripojenem zipu.
 V OS spustenem z live i jako 'spravce' to neslo primo kopirovat.

Fsck nemůžeš spouštět na oddíle ze kterého běží systém (byť v recovery mode), oddíl musí být odpojený (umount). Dělá se to z nabootovaného live. V něm rovněž snadno zjistíš označení oddílů. Doporučuji použít vestavěné GParted kde si vše naklikáš, lze v něm provést i tu opravu.

Zálohy rsync by měly být funkční (pokud je cílový disk v pořádku a cílový oddíl je ext4). To zkontroluješ snadno i vizuálně.
Jak ty soubory obnovit (zkopírovat) na nově zformátovaný oddíl btrfs už jsem psal minule. Nový oddíl musí mít stejné uuid jako původně (nutno buď změnit) nebo to ošetrit v fstab. Na novém oddíle je třeba vytvořit btrfs subvolume @  Ta bude potom cílem obnovy (je to v podstatě složka).
Nic na tom celkem není (provádět z live!). Ostatně, už jsi to mohl dávno mít...
Někteří uživatelé ale sveřepě trvají na reinstalacích, snad je to i baví, mě tedy ani náhodou - znova vše nastavovat, instalovat...

Btrfs oddíl 42GB stačí. Nicméně vzhledem k tomu, že jsi lajdák (o systém/místo/balance se nestaráš, můžeš ho zvětšit na 60GB.
Toto všechno ale smysl nemá, pokud nemáš 100% ní jistotu že je disk zdravý - zatím jsi o tom nepřesvědčil. Pokud je "chycený" disk (či řadič), je vše ostatní ztráta času.
(směrodatná je pouze kontrola utilitou nejépe výrobce provedená offline = z boot media, např. UBCD na kterém jsou testovacích utilit mraky, nikoli nějaký pofiderní rádoby pseudotest)

[juwa2]

1. Podle mě je to přesně naopak - systémový oddíl ano, /home spíše ne, tam to takový význam nemá a třeba pro oddíl s filmy bych to používat rozhodně nechtěl, to bych se místa nedopočítal.  A nedávno na btrfs jako vých. přešla např. Fedora...

U /home se mi btrfs velice osvědčilo; mohu si tak z některého domovského adresáře udělat pododdíl (subvolume), ten naklonovat (snapshot) a při každém startu systému daný domovský adresář (skriptem) smazat a nahradit novým klonem snapshotu, tím pádem se při každém startu smažou všechny změny provedené z daného uživatelského účtu (na ext4 by totéž nešlo jinak než obrovským kopírováním).

Moje zkušenosti jsou takové, že systém jako takový se mi „rozbije“ jen zřídka, naopak se mi už minimálně dvakrát „rozbil“ domovský adresář, protože nějaká aplikace někam do konfigurace zapsala nějaké nesmysly a něco se tím úplně pokazilo. Do systémových adresářů běžné aplikace zapisovat nemohou, takže tam se to tak snadno nepokazí.

Velká výhoda ext4 je, že když dojde místo, tak prostě smažeš nějaký velký soubor a hned máš spoustu volného místa. Btrfs je v takové situaci příliš „inteligentní“, takže si bude stěžovat něco ve smyslu: „Nemám dost volného místa, abych mohlo smazat ten soubor.“

1. S tím /home je to částečně pravda, občas může něco vyústit až v nemožnost se přihlásit (třeba login loop). Nicméně tohle se zase poměrně snadno opravuje. Tvůj způsob je sice účinný, ale podle mě až zbytečně radikální. Tohle se dá lépe řešit rsync zálohou s vyloučením objemných položek (tj. zálohovat jenom konfiguráky) a případnou obnovu provádět pouze v případě potíží (= skoro nikdy)..

2. Na systému se naopak toho pokazit může poměrně dost. Navíc často a rád experimentuji, což bych si tolik bez předem vytvořeného snapshotu "netroufal".
Péči o filesystém považuji za základ, mám na to napsaný skript který se o to automaticky "stará". Proto potíže nemám. 

P.S. Víš o tom, že na každém ext4 existuje 10% "nevyužitelného" prostoru který ale lze předisponovat (nebo část) ve prospěch std. uživatele?
Na větším oddíle je to totiž docela dost co normálně leží "ladem"...

Kód: [Vybrat]

#změna z 10 na 2%
sudo tune2fs -m 2 /dev/sdXY
Možno provést online, změna se projeví okamžitě.

[singularis]

1. S tím /home je to částečně pravda, občas může něco vyústit až v nemožnost se přihlásit (třeba login loop). Nicméně tohle se zase poměrně snadno opravuje. Tvůj způsob je sice účinný, ale podle mě až zbytečně radikální. Tohle se dá lépe řešit rsync zálohou s vyloučením objemných položek (tj. zálohovat jenom konfiguráky) a případnou obnovu provádět pouze v případě potíží (= skoro nikdy)..

2. Na systému se naopak toho pokazit může poměrně dost. Navíc často a rád experimentuji, což bych si tolik bez předem vytvořeného snapshotu "netroufal".
Péči o filesystém považuji za základ, mám na to napsaný skript který se o to automaticky "stará". Proto potíže nemám. 

P.S. Víš o tom, že na každém ext4 existuje 10% "nevyužitelného" prostoru který ale lze předisponovat (nebo část) ve prospěch std. uživatele?
Na větším oddíle je to totiž docela dost co normálně leží "ladem"...

Kód: [Vybrat]

#změna z 10 na 2%
sudo tune2fs -m 2 /dev/sdXY
Možno provést online, změna se projeví okamžitě.

„Nicméně tohle se zase poměrně snadno opravuje.“ — Jak kdy. Šlo to snadno, když měl domovský adresář omylem vlastnictví root:root, což způsobovalo login-loop. Ale jindy se mi stalo, že se nějak zbláznilo Pulseaudio, nešlo vůbec zprovoznit zvuk a přetrvalo to i po restartu (a projevovalo se to jen v tom jednom uživatelském profilu, na jiných zvuk fungoval normálně). Teprve po několika restartech to zmizelo, takže obnova nebyla nutná. A ještě na Ubuntu Studiu 18.04 jsem si zkoušel/a editovat menu programem Menulibre a ten tu strukturu menu úplně zničil. Nyní už vím, jak bych to opravil/a, jenže tenkrát jsem to nevěděl/a, takže obnova ze zálohy byla nutná.

„Navíc často a rád experimentuji“ — To já také, jenže já experimentuji ve virtuálních počítačích, kde jsou snapshoty celého systému normální vlastností virtualizace a otázkou kliknutí na pár tlačítek. To se pak experimentuje pohodlně a bezpečně... 

„Víš o tom, že na každém ext4 existuje 10% "nevyužitelného" prostoru“ — To jsem nevěděl/a, ale podle http://manpages.ubuntu.com/manpages/focal/en/man8/tune2fs.8.html a jiných zdrojů je to jen 5%. Navíc takto nevyužité bloky určitě podléhají operaci TRIM, takže mohou napomoci zvýšit životnost SSD disku, a prý pomáhají i snížit fragmentaci. Naprostou nezbytností pak jsou na kořenovém (systémovém) oddílu, kde umožní, aby nezhavarovalo úplně všechno (kromě jádra), když se nějaký ztřeštěný program rozhodne do /var/tmp zapsat víc, než se tam vejde. Na externích discích ale asi velký význam nemají, takže tam může být ten příkaz, který uvádíš, užitečný. Také u několikaterabajtových oddílů má smysl tu rezervu snížit, ale třeba u šedesátigigabajtového systémového oddílu bych to nedělal/a. V každém případě ale děkuji za tip. 

[juwa2]

1. Jó, Menulibre/Alacarte/Mozo, to už mám taky za sebou. Moc se rádi nemají, ale stačí pochopit jak to funguje (soubory *.desktop) - nezkušenému to ale může "zamotat šišku", meníčka to opravdu rozbije...
2. Virtualizace je sice hezká (i když ne každý má na to dostatečný HW), ale hlavně - spousta věcí nefunguje pořádně ani nativně, natož ve virtuálce, to je ten "problém".   Pokud např. zkoušíš rozchodit HW akceleraci videa grafikou, je ti virtuál celkem k ničemu (ano, ve Windows je to mnohem lepší).

[singularis]

1. Jó, Menulibre/Alacarte/Mozo, to už mám taky za sebou. Moc se rádi nemají, ale stačí pochopit jak to funguje (soubory *.desktop) - nezkušenému to ale může "zamotat šišku", meníčka to opravdu rozbije...
2. Virtualizace je sice hezká (i když ne každý má na to dostatečný HW), ale hlavně - spousta věcí nefunguje pořádně ani nativně, natož ve virtuálce, to je ten "problém".  Pokud např. zkoušíš rozchodit HW akceleraci videa grafikou, je ti virtuál celkem k ničemu (ano, ve Windows je to mnohem lepší).

„i když ne každý má na to dostatečný HW“ — Myslím, že v tomto ohledu se situace mění k lepšímu. Já nyní provozuji virtuální počítače i na procesoru Intel Celeron J3455 (2 jádra, 4 vlákna, 2300 MHz) s 8 GiB RAM a jsou sice trochu pomalé, ale jde to a zvládnu i dva virtuální počítače najednou. A běžné kapacity SSD disků už se také blíží k terabajtu, takže i ty nejlevnější nové notebooky virtuální počítače bez větších potíží zvládnou.

„Pokud např. zkoušíš rozchodit HW akceleraci videa grafikou, je ti virtuál celkem k ničemu (ano, ve Windows je to mnohem lepší).“ — To je pravda, na takové případy používám samostatný systém (nyní ho mám na „dual-boot“, ale připadne mi, že nainstalovat ho na externí SSD disk by možná bylo lepší). Zrovna hardwarovou akceleraci videa raději vypínám, protože mám skoro všude tak slabé grafiky, že CPU to zvládne lépe. (Alespoň mám takový dojem.)

[juwa2]

„Pokud např. zkoušíš rozchodit HW akceleraci videa grafikou, je ti virtuál celkem k ničemu (ano, ve Windows je to mnohem lepší).“ — To je pravda, na takové případy používám samostatný systém (nyní ho mám na „dual-boot“, ale připadne mi, že nainstalovat ho na externí SSD disk by možná bylo lepší). Zrovna hardwarovou akceleraci videa raději vypínám, protože mám skoro všude tak slabé grafiky, že CPU to zvládne lépe. (Alespoň mám takový dojem.)

Pokud HW akceleraci (určitého videokodeku, H264, H265, VP9, AV1) grafika neumí (resp. to nejde v daném OS zprovoznit), má to celé "na zádech" CPU.
A v případě slabšího CPU je to katastrofa = vytížení 100%++ a z toho pramenící praktická nemožnost přehrání (záseky atd.).
Přitom na stejném stroji ve Windows to funguje (DXVA) a vytížení CPU je cca 5 - 10% samozřejmě při přehrávání stejného materiálu.
Sny o virtuálu se v tomto kontextu zcela rozplývají...

Provozovat OS z ext. disku nikdy - max na vyzkoušení, jakékoli USB = brzda...

[miro_]

Pro zdravotni i jine problemy se vracim k tematu az nyni.

Nicméně vzhledem k tomu, že jsi lajdák (o systém/místo/balance se nestaráš,...

Dnes jiz nejsem schopen sledovat a studovat dopodrobna vse.  Resim problemy az kdyz na ne narazim.
O 'balanci' jsem nevedel..

Možnou příčinu problémů bych viděl ve fyzickém stavu disku (sektory) nebo porušeném filesystému ....

Proveroval jsem disky-oddily vcetne zalohy samozrejme i z 'live (' OS 18.04mate-32bit gparted-check),
samozrejme jsem delal i testy pres sw od 'vyrobce' SSD ! (Na jinem PC ..., existuje jen pro Win10  'ADATA ssd ToolBox').
Zadne problemy jsem nenasel.

Drive jsem s obnovenim OS pres 'timeshift' nemel problem, i kdyz se mi nekolikrat povedlo OS uplne zbourat.

Po te, kdyz jsem nevedel jak dal preinstaloval jsem U20mate v  '/' BTFSR s jeho preformatovanim.
? nebyla chyba, ze jsem neudelal cistou instalaci i s preformatovanim '/home' ?

Po instalaci je problem s 'chromium'.
'Chromium' spadne pri pokusu o ulozeni stranky pres 'ctrl-S'.
Domnivam se, ze nova instalace neinicializovala jeho nektera nastaveni (asi vlivem uziti BTFSR a jeho vazeb do '/home').
'Chromium' po preinstalacich nechtelo klicenku a stale udrzovalo nejaka nastaveni, historii....
'Resetovani jeho nastaveni' z jeho nastaveni neni plne funkcni !

Pri istalaci 'libre office' z 'butik' vznikl jeste problem ktery skoncil v
 'OSError: [Errno 5] Input/output error:...'.
Opravu pres 'synaptic' jsem byl schopen provest az po restartu OS  po 'sudo dpkg --configure -a'.
 
Po techto problemech jsem znovu proveroval stav oddilu a zazil jsem šok.

Pro testy jsem drive uzival 'gparted' z 'live' USB U18mate-32bit.
Na multiboot USB jsem si udelal misto a doinstaloval uzitou instalaci U20mate-64bit.

Z live U18mate jsou testy vsech oddilu OK ale 'check' z U20mate skonci v BTFSR oddilu chybou  !
Stav '.iso' U20 byl kontrolovan SHA..., chovani je stejne i pri spusteni z live DVD U20.

V pocatcich logu testu jsou  videt rozdily verzi uzitych programu:
log z U18: 'GParted 0.30.0              --enable-libparted-dmraid --enable-online-resize Libparted 3.2'  ....!!!
log z U20: 'GParted 1.0.0 configuration --enable-libparted-dmraid --enable-online-resize libparted 3.3   ....
 'Logy mohu prilozit. Problem z logu z U20 nevidim.
? cemu verit.

Chovani instalace U20mate z mnou uzivanych aplikaci je bezproblemove az na 'chromium'.

Poznamka pro pripadne komentare a nazory:
Chci zduraznit ze OS na tomto PC-SSD uzivam pro overovani funkcnosti mnou uzivanych aplikaci na U20mate.
U20 je provozovan na starsim PC MS7350, 2GB RAM, 2core CPU Intel 1.86GHz, Grafika NV106.
Pro dulezite aktivity uzivam jine PC s dele overovanymi OS.

[juwa2]

1. Pokud máš /home  zvlášť, tj. na oddíle ext4, žádné "vazby" na btrfs oddíl nejsou. Proto můžeš při přeinstalaci /home  zachovat (tj. neformátovat je).
2. Potíže s chromiem vyřešíš smáznutím složky s profilem (~/.config/chromium). Profil může být poškozený. Jiný důvod potíží nevidím.
Po smáznutí složky se po spuštění CH automaticky vytvoří nová, začneš tak s "čistým štítem".
3. Ano, oddíly vytvořené různými verzemi Ubuntu se opravdu liší - proto pro kontrolu/opravu používej nejnovější LTS verzi (aktuálně 20.04). Verzi 18.04 už k tomuto účelu nepoužívej.
P. S. Od začátku ti tvrdím, že máš chybu ve filesystému - proto ta obnova selhala. Pokud bys občas (preventivně) kontrolu + balance provedl, nedošlo by k tomu....