Sziasztok!
A segítségeteket kérem. A root partícióm (sda6) 40 GB, a home (sda7) 32, és még ezen kívül van másik 3. Tumbleweed, Lenovo T410.
Már többször előfordult, hogy egy-egy nagyobb frissítésnél gyakorlatilag teljesen elfogyott a hely a root partíción (btrfs). Ilyenkor a zypper clean, a snapper cleanup number, és a zypper purge-kernels parancsokat futtattam, néha elsőre, néha ötödjére, de valahogy csak helyreállt a világ rendje, és visszakaptam az elfoglalt területet. Nagyjából 8 GB szabad helyem volt már elég régóta. Ám a legutóbbi frissítés óta (2-3 hete) nem kaptam vissza, akármit csinálok. Egy tutac parancsot lefuttattam már a szokásosokon kívül, ahol lehetett, tájékozódtam, de semmi nem oldotta meg a problémát (árva csomagok törlésétől kezdve a tmp ürítése stb.).
Most folyamatosan 350 és 90 mega körül mozog a rendszer.
1. Van-e még esetleg tippetek, hogyan kaphatnám vissza az elfoglalt területet?
2. Az egyik partíciót (sda2, 70GB) leformáztam btrts-re, hozzá tudom toldani a root-hoz adatvesztés és bármilyen egyéb probléma nélkül?
Minden tippet köszönettel veszek!
Eszköz Indítható Start Vége Szektorok Size Id Típus
/dev/sda1 2048 145035263 145033216 69,2G 83 Linux
/dev/sda2 145035264 290027519 144992256 69,1G 83 Linux
/dev/sda3 290027520 444850175 154822656 73,8G f W95 kiterj. (LBA)
/dev/sda4 * 444850176 624110761 179260586 85,5G 7 HPFS/NTFS/exFAT
/dev/sda5 373917696 378111999 4194304 2G 82 Linux lapozó / Solaris
/dev/sda6 290029568 373915647 83886080 40G 83 Linux
/dev/sda7 378114048 444850175 66736128 31,8G 83 Linux
-------------------------------------
sudo snapper ls
# | Típus | Előtti # | Dátum | Felhasználó | Használt terület | Tisztítás | Leírás | Felhasználói adatok
------+--------+----------+-----------------------------------------+-------------+------------------+-----------+-----------------------+--------------------
0 | single | | | root | | | current |
1* | single | | 2018. febr. 11., vasárnap, 12:24:57 CET | root | 68,25 MiB | | first root filesystem |
1394 | pre | | 2022. jan. 7., péntek, 16:57:11 CET | root | 1,86 GiB | number | zypp(zypper) | important=yes
1395 | post | 1394 | 2022. jan. 7., péntek, 17:20:24 CET | root | 18,18 MiB | number | | important=yes
1396 | pre | | 2022. jan. 10., hétfő, 15:40:19 CET | root | 37,34 MiB | number | zypp(zypper) | important=yes
1397 | post | 1396 | 2022. jan. 10., hétfő, 17:33:42 CET | root | 1,12 GiB | number | | important=yes
1406 | pre | | 2022. jan. 31., hétfő, 08:54:52 CET | root | 524,00 KiB | number | yast online_update |
1407 | post | 1406 | 2022. jan. 31., hétfő, 08:55:38 CET | root | 504,00 KiB | number | |
- 1076 megtekintés
Hozzászólások
Mappákat átmozgathatsz másik valahova felcsatolt partícióra és az eredeti helyéről symlinkelsz a mappa új helyére.
Egyébként érdemes feltérképezni, mi zabálja fel nálad a helyet? Lehet adatfájl, logfájl, snapshot egyaránt. Sőt régebbi kernelek ha nem lettek törölve (apt autoremove), az is sok helyet elvisz az évek alatt.
- A hozzászóláshoz be kell jelentkezni
Sőt, nem is csak autoremove, de autoclean, clean is. A telepitett, de folosleges kerneleket el is kell elotte tavolitani.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
Mappákat átmozgathatsz másik valahova felcsatolt partícióra és az eredeti helyéről symlinkelsz a mappa új helyére.
Ebben az esetben a bind azért jóval elegánsabb és bizonyos esetekben problémamentesebb is.
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
- A hozzászóláshoz be kell jelentkezni
Nem maradnak meg az rpm csomagjaid a gépen?
A "/var/cache/zypp/packages" mappa tartalmát nézd meg.
A csomagok megtartása az "/etc/zypp/repos.d" mappában lévő config fájlokban a "keeppackages=1/0" segítségével állítható.
Nagy Gábor https://sign-el-soft.hu
- A hozzászóláshoz be kell jelentkezni
1, A faszé' kell mindent külön tenni. :D
2, Inkább töröld az sda2-t, hagyd üresen és növeld meg az sda1 méretét, sokkal kevesebb macera és adatvesztési lehetőség.
3, `du / --max-depth=1 -x` mit mond?
- A hozzászóláshoz be kell jelentkezni
Ezt az egész felosztást nem értem. Mi van az sda1 és sda2-őn? Valami másik Linux? Mert ha igen, akkor nem kell minden egyes disztrónak külön home partíció, lehet úgy is, hogy közös home partíciót használnak, de azon más-más home mappát. Így szerintem csak szüntesd meg az sda7-et, másold át az sda2-re, és az sda6-ot növeld meg a meghajtó végéig.
Plusz ha több OS is megy, akkor megfontolhatnád, hogy nagyobb meghajtóra váltasz, vagy beteszel egy másik háttértárat, mert ezt a helyet ezzel több OS-es felhasználással láthatóan kinőtted. Plusz ez sajnos a nagy mainstream vagy nagyvállalati disztrók átka, hogy sok szutyok van feltelepítve, az meg eszi a helyet.
Nálam Archon a szintén 40 gigás root partíción van 30 giga hely, és már ez is egy túlságosan sallangosodott, telepítés, egy csomó extra csomag fent van, amire már igazából nincs is szükségem, de fent maradt, nem tudom mihez kellett, igazából 7-9 giga körül szokott lenni nálam a rendszer, hiszen csak minimalista WM, meg CLI/TUI programok, grafikus alkalmazásból csak egy kevés. Plusz játékok, de azok már a home partíción vannak. Régen 50-60 gigás root partícióim voltak, de az meg nagy helypazarlás volt, így 40-re csökkentettem, és még mindig túl sok, és az 1 terás SSD-n még van egy csomó szabad hely, home-nak, adatoknak. 40 giga alá viszont nem szívesen mennék, mert ha esetleg valami /var vagy ilyesmi meghízik valami bug miatt varatlanul, akkor nehogy működőképtelen legyen a rendszer. Pacman cache-t nem tartom meg, tmpfs-be irányítom, így nem kell pucolgatni a régi csomagokat, meg systemd-bootot használok, és az Arch a régi kerneleket nem halmozgatja az EFI bootpartícióra.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
A napokban 2 gigát hízott a rendszer, kezdett gyanús lenni. Kiderült a du -sh parancsot használva, hogy a systemd journal log és a systemd coredump log foglal el 1,3 és 3,5 gigát. Egyiket a journelctl --vacuum-time=1d paranccsal ürítettem, a másikat meg rm paranccsal pucoltam ki a /var/lib/systemd/coredump mappából (ezek egy befosott Firefox profil miatti rendszeres crash-ek logjai) Töröltem 250 megányi régi clamav logot is, szintén a /var/-ból. Az is igaz, hogy a fenti hozzászólás óta leszedtem egy GUI szótárprogramot is jó pár Qt-s függőséggel, így már csak 7,6 gigát foglal az egész rendszer, úgy, hogy 888 csomag van fent. Leblogolom, hátha másnak is tanulságos, hogy nem csak btrfs snapshotok tudnak foglalni. Nekem ez az első alkalom, hogy logok miatt hízott a rendszer komolyabban.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Ez jó tipp!
Én is úgy jártam hogy kezdett fogyni a hely. A log már 5+ GB-ot foglalt.
Ez a vacuum parancs szépen truncatelte.
// Hocus Pocus, grab the focus
winSetFocus(...)
http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation
- A hozzászóláshoz be kell jelentkezni
Leblogolom, hátha másnak is tanulságos, hogy nem csak btrfs snapshotok tudnak foglalni.
Ehez még csak azt szeretném hozzáfűzni, hogyha a /var egy btrfs partíción van amin van egy full-snapshot, akkor bármit is törölsz a logokból, hely nem szabadul fel, mert a snapshot miatt a block-ok foglaltak maradnak.
- A hozzászóláshoz be kell jelentkezni
Köszönöm mindenkinek a választ!
A "/var/cache/zypp/packages" üres.
Ami furcsa számomra, hogy van egy proc nevű mappa, a Dolphin azt mondja, hogy 128 TiB(!) a mérete. Ami nyilván nem elképzelhető.
A "du / --max-depth=1 -x" azt mondja, hogy
32736 /etc
49084 /boot
9618920 /usr
5554472 /var
0 /mnt
217996 /root
40 /snap
0 /media
0 /.Trash-0
15473264 /
"autoremove, de autoclean, clean is. A telepitett, de folosleges kerneleket el is kell elotte tavolitani." - ezeket mind próbáltam, első lépésekként, azt mondja a konzol, hogy nincs teendő.
sudo zypper clean / sudo zypper purge-kernels / sudo snapper cleanup number - ezeket is mind próbáltam már.
Az sda1-en van egy Manjaro, de nem használom, illetve tele van adattal (ezeket fel tudom tenni felhőbe, ha szükséges).
sda2 most egy üres btrfs partíció.
Azt sda4-en egy win10 van, ha szükséges, néha azt használom.
Manjaro partíciókezelőjében nem tudom veszély nélkül a root-omhoz csatolni az üres btrfs-t?
Ami viszont engem is érdekel, hogy mi és miért foglalja el mind a 40 gigát a root partíciómon?
- A hozzászóláshoz be kell jelentkezni
Ami furcsa számomra, hogy van egy proc nevű mappa, a Dolphin azt mondja, hogy 128 TiB(!) a mérete. Ami nyilván nem elképzelhető.
A /proc egy virtuális fájlrendszer, a mérete is virtuális, semmi köze nincs ahhoz, hogy mennyi storage van a gépedben.
15473264 /
Ez ugye ~15GB, ennyi a fájlrendszer tényleges tartalma, szóval valami el van baszódva a btrfs fájlrendszeredben és/vagy van pár snapshot/subvolume, ami még foglalja a helyet. Egy `btrfs subvolume list /` mit mond?
- A hozzászóláshoz be kell jelentkezni
A /proc/ az nálam is 128TB-osnak van mutatva, szerintem kb. minden mai modern 64 bites disztrón ez lesz a helyzet.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Ja, akkor az van, amit írtam, befogod a /dev/sda2-őt mondjuk /usr csatolási pontnak, a root többi része marad a mostani /dev/sda6-on. Ezt is csak max. átmenetileg ajánlom, míg rendbe nem rakod a partícióid, vagy be nem szerzel másik/nagyobb háttértárat.
Azt nem értem mi foglal sokat, a du kimenete alapján elégnek kéne lennie annak a 40 gigás sda6-nak. Nem írtad milyen fájlrendszer, de ha btrfs, akkor tényleg csak az lehet, amit írtak, hogy a btrfs snapshotok híztak meg, töröld őket.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
A Thunar is ezt mondja, 128TB, keresem is a maradékot már félórája :)
- A hozzászóláshoz be kell jelentkezni
btrfs subvolume list /
mit ír? Nincsenek snapshotjaid?
- A hozzászóláshoz be kell jelentkezni
snapper ls - lásd első üzenetem.-------------------
Egy `btrfs subvolume list /` mit mond?
ID 257 gen 26887 top level 5 path @
ID 258 gen 610205 top level 257 path @/var/tmp
ID 259 gen 610211 top level 257 path @/var/spool
ID 260 gen 610204 top level 257 path @/var/opt
ID 261 gen 610209 top level 257 path @/var/log
ID 262 gen 609468 top level 257 path @/var/lib/pgsql
ID 263 gen 609468 top level 257 path @/var/lib/named
ID 264 gen 609468 top level 257 path @/var/lib/mysql
ID 265 gen 609468 top level 257 path @/var/lib/mariadb
ID 266 gen 609468 top level 257 path @/var/lib/mailman
ID 267 gen 26907 top level 257 path @/var/lib/machines
ID 268 gen 609468 top level 257 path @/var/lib/libvirt/images
ID 269 gen 609460 top level 257 path @/var/crash
ID 270 gen 610208 top level 257 path @/var/cache
ID 271 gen 609469 top level 257 path @/usr/local
ID 272 gen 610208 top level 257 path @/tmp
ID 273 gen 609565 top level 257 path @/srv
ID 274 gen 610205 top level 257 path @/opt
ID 275 gen 606809 top level 257 path @/boot/grub2/x86_64-efi
ID 276 gen 606809 top level 257 path @/boot/grub2/i386-pc
ID 277 gen 609567 top level 257 path @/.snapshots
ID 278 gen 610211 top level 277 path @/.snapshots/1/snapshot
ID 369 gen 94116 top level 277 path @/.snapshots/74/snapshot
ID 432 gen 96416 top level 277 path @/.snapshots/114/snapshot
ID 2058 gen 596011 top level 277 path @/.snapshots/1394/snapshot
ID 2059 gen 596011 top level 277 path @/.snapshots/1395/snapshot
ID 2067 gen 596101 top level 277 path @/.snapshots/1396/snapshot
ID 2070 gen 598263 top level 277 path @/.snapshots/1397/snapshot
ID 2081 gen 607434 top level 277 path @/.snapshots/1406/snapshot
ID 2082 gen 607434 top level 277 path @/.snapshots/1407/snapshot
- A hozzászóláshoz be kell jelentkezni
Szerintem megtaláltad, hogy miért nincs hely: van egy csomó snapshot, ami foglalja a helyet, ezeket át kellene nézni, hogy miért maradtak ott.
Ezt érdemes átnézni amúgy: https://doc.opensuse.org/documentation/leap/reference/html/book-referen…
- A hozzászóláshoz be kell jelentkezni
Bingó. Első hozzászólásomban ráéreztem. Az összes ilyen összetett fájlrendszernek, ami snapshotra képes (btrfs, zfs, ...) rákfenéje, hogy "önálló életre" képes kelni a default config alapján, a user pedig csak néz ki a fejéből, miért van fogytán a helye.
Akkor nincs már dolgod, mint a snapshotokat kézzel törölni
btrfs subvolume delete @snapshot_mappa- A hozzászóláshoz be kell jelentkezni
Nem, ez nem csak az összetett fájlrendszerek rákfenéje, hanem az összes modern konzumer/corporate OS-é, hogy a sok réteg komplexitási fok mögé elrejtve, a felhasználó háta mögött önálló életre kelnek, ami előbb-utóbb morbid belassulásokhoz, abnormális tárhelyelfogyáshoz, stb. vezet, mert próbálják a felhasználó helyett kitalálni, meg jobban tudni, hogy mi a jó neki.
Én ezért is maradok minimalista rendszernél, meg otthoni felhasználásnál sima ext4-nél. Mert elég, piszok gyors, beállítok mindent magam, nincsenek csúnya meglepetések. Annak ellenére, hogy használtam btrfs-t, és nincs azzal se bajom, Archon használtam egy régi, lassú HDD-s géphez, akkor arra ideális volt, mert jó volt a transzparens röptömörítése, tudott lecsatolás nélküli defragot, jó volt az adatkonzisztenciája áramszünetkor (ext4-en ilyenkor átment az fsck, meg a torrektkliens mindent újraellenőrzött, mert sérült a resume data, a btrfs meg ezeket jobban tűrte akkor), tud meghajtókon átnyúló köteteket kezelni, stb.. Még a snapshot funkciót is kipróbáltam, az is tetszett, de csak kézileg adtam hozzá őket, nem volt automatizálva. Szóval baj nincs vele, de én orrvérzésig nem erőltetném otthoni gépen, főleg SSD-n nem, és ha használja is valaki, nem ajánlom, hogy ilyen automatikus snapshotokkal használja, és főleg nem a rootra irányítva őket, mert ez olyan gáz, hogy Chuck Norris se vállalná be.
A rootra semmit nem érdemes tenni, csak a rendszert, pont ilyen helyelfogyási okból, meg esetleges gikszer miatti újratelepítéskor nem kell mindent a rootról lementeni. Ezért érdemes, amit csak lehet, másik partíción tartani, főleg /home és egyéb adatokat.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
A rootra semmit nem érdemes tenni, csak a rendszert, pont ilyen helyelfogyási okból, meg esetleges gikszer miatti újratelepítéskor nem kell mindent a rootról lementeni.
A snapshot pont azért jó, mert esetleges gikszer esetén könnyű visszaállni a snapshot tartalomra...
- A hozzászóláshoz be kell jelentkezni
Azt nem is mondtam, hogy nem hasznos, hanem hogy 1) nem ilyen szinten, a felhasználó háta mögött automatizálva, 2) nem a rootra, ahol a tárhely kritikus, mert ezzel saját maguk alá szarnak. Itt nem a szándékkal, hanem a kivitelezéssel van gond. Én emiatt nem is windowsosok meg használok mainstream/corporate disztrót, mert tele vannak ilyen szopatásokkal (pl. Snap, Flatkap, egyebek), és igen, ki lehet hekkelni egy kis tudással, utánaolvasással, de plusz munka, akkor inkább abból az erőfeszítésből felteszek egy saját rendszert, amin csak az van fent, ami tényleg kell, és úgy állítok be mindent, ahol jónak látom, nem más automatizálja helyettem a dolgokat.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Azt nem is mondtam, hogy nem hasznos, hanem hogy 1) nem ilyen szinten, a felhasználó háta mögött automatizálva, 2) nem a rootra, ahol a tárhely kritikus, mert ezzel saját maguk alá szarnak.
Hát pedig pont ez a kettő az, amiért létjogosultsága van: ha nem sikerül egy upgrade, akkor vissza lehessen állni akár automatikusan egy korábbi snapshot-ra. Ehhez az kell, hogy upgrade előtt csináljon egy snapshot-ot a root fájlrendszeren és upgrade után valamennyi idővel törölje a régit.
Én emiatt nem is windowsosok meg használok mainstream/corporate disztrót, mert tele vannak ilyen szopatásokkal (pl. Snap, Flatkap, egyebek), és igen, ki lehet hekkelni egy kis tudással, utánaolvasással, de plusz munka, akkor inkább abból az erőfeszítésből felteszek egy saját rendszert, amin csak az van fent, ami tényleg kell, és úgy állítok be mindent, ahol jónak látom, nem más automatizálja helyettem a dolgokat.
Használj, amit akarsz, de attól még felhasználók tömegének hasznos ez a feature.
- A hozzászóláshoz be kell jelentkezni
> felhasználók tömegének hasznos ez a feature.
ez a topik nem is jött volna létre, ha nem így volna. Komolyabban mondva, kimaradt az update _előtti_ takarítás, meg a szabad hely ellenőrzése, esetleg (isten ments!) a felhasználó tájékoztatása.
- A hozzászóláshoz be kell jelentkezni
Úgy gondolom, hogy mivel nem tömeges a hiba - nincsenek telesírva a fórumok azzal, hogy mennyire szar, ezért ez egy ritka és/vagy egyedi eset, amit okozhatott bármi is.
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy kibeszél a fősodorból, meg szutyok, meg önjáró alkalmazások. Csak arról nem beszél senki, hogy nem igazán egyéni döntés volt. Mert süsün ez default, de választahatott volna ext4-et is. De nem és ezért probléma adódott, Ő meg mert kérdezni. Csak egy páran próbálták meg fogni a dolog igazi lényegét, hogy adott egy szitu és azt meg kéne oldani.
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy kibeszél a fősodorból, meg szutyok, meg önjáró alkalmazások.
A felhasználók ezt igénylik. Olyan ez miatt sírni, mint az miatt, hogy miért nincs manuális szívató az új autókon.
Csak arról nem beszél senki, hogy nem igazán egyéni döntés volt. Mert süsün ez default, de választahatott volna ext4-et is.
A SuSE is egyéni döntés és az is, hogy btrfs legyen a fájlrendszer.
De nem és ezért probléma adódott, Ő meg mert kérdezni.
Nem azért adódott probléma, mert hagyott mindent default a telepítésnél. Emberek százezrei vagy milliói teszik ugyanezt. Ha ennek ellenére alig van ebből probléma, akkor a dolog nagyrészt működik. Bugok voltak, vannak és lesznek.
Csak egy páran próbálták meg fogni a dolog igazi lényegét, hogy adott egy szitu és azt meg kéne oldani.
Adtam komplett fejezetet olvasnivalónak, a SuSE dokumentációból, hogy mit lehet tenni. Olvassam el helyette?
- A hozzászóláshoz be kell jelentkezni
Nem, még mindig nem érted miről írok. Snapshotot a rootról akárhová lehet csinálni, kukutyinba, másodlagos háttértárra, külső háttértárra, stb.. Attól még a rootra állítod vissza, ha gond van. Ettől még nem kell a rooton tárolódnia, ahol KRITIKUS a tárhely a rendszer működése szempontjából. Másrészt meg az automatika itt a baj, hogy el van döntve, hogy x időnként snapshot készül, és még nem csak ez, de a felhasználó tudomására sincs hozva, csak akkor veszi észre, ha már elfogyott a hely, meg a rendszere esetleg nem bootol vagy nem működik. De kicsit ilyen a Debian-alapú rendszereken, mikor az apt a boot partícióra behalmozza az összes valaha használt kernelt.
Ezért nem szokták érteni, hogy az Arch, Gentoo, Void, Alpine, Slackware nem meme, hanem pont az a lényege, hogy ilyen „hasznos” (hülyebiztos) feature-ök nincsenek belerejtve, meg nincsenek tele sallanggal, így nem csak hogy felesleges szutykok nincsenek a rendszeren, nem futnak, gyorsabb lesz a rendszer, kevesebbet frissít, de ilyen csúnya bekészített meglepetések se várnak az emberre.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Snapshotot a rootról akárhová lehet csinálni, kukutyinba, másodlagos háttértárra, külső háttértárra, stb..
Lehet, de az nem snapshot. Amiről beszélsz, az backup.
Ettől még nem kell a rooton tárolódnia, ahol KRITIKUS a tárhely a rendszer működése szempontjából.
A snapshot ugyanazon a fájlrendszeren van, ez a természete.
Másrészt meg az automatika itt a baj, hogy el van döntve, hogy x időnként snapshot készül, és még nem csak ez, de a felhasználó tudomására sincs hozva, csak akkor veszi észre, ha már elfogyott a hely, meg a rendszere esetleg nem bootol vagy nem működik.
Elég sok helyen működik gond nélkül, szóval továbbra is tartom, hogy a jelen esetben valami egyéb elbaszás este forog fenn, aminek a tünete most és így jött elő. És ha egyéb elbaszás esete forog fenn, arra nem megoldás az, hogy megszüntetünk egy amúgy jól működő dolgot, ami lehet, hogy nem is tehet erről az elbaszásról, csak ugyanúgy érinti.
- A hozzászóláshoz be kell jelentkezni
Igen, fogalmilag backup, de technikailag snapshot. Én úgy tudom, hogy nem kell ugyanazon a fájlrendszeren lennie, de akkor a célfs-nek is btrfs-nek kell legyen. Bár nem kizárt, hogy neked van igazad, nem vagyok fs-guru. Mondom, itt nem a snapshotozással van baj, hanem hogy egy olyan partícióra készül, ahol feleszi a helyet a rendszer elől.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Igen, fogalmilag backup, de technikailag snapshot.
A nagy lófaszt, már bocsánat.
itt nem a snapshotozással van baj, hanem hogy egy olyan partícióra készül, ahol feleszi a helyet a rendszer elől
Nem, itt az a baj, hogy valami valamikor elbaszódott és ennek a tüneteit látjuk. Ennek az elbaszódásnak a forrása lehet az is, hogy a Tumbleweed nem a stabil kiadása az openSUSE-nak, akinek stabilitás kell, használjon Leap-et.
- A hozzászóláshoz be kell jelentkezni
Ragozhatod, de értelme nincs. A snapshot mindenképp egyfajta backup, akárhová készül. Most a kedvedért utánanéztem, és kiderült, hogy évekkel ezelőttről jól emlékeztem, btrfs snapshot csinálható másik partícióra és meghajtóra is. Szerintem csak annyi a megkötés, hogy azon is btrfs fájlrendszernek kell lennie. A btrfs subvolume snapshot parancs után megadhatsz akármilyen btrfs subvolume-ot forrásnak, és célnak is. Téged az zavar meg, hogy ilyen grafikus felületeken beállított automata snapshotok ugyanarra a partícióra szoktak készülni, de ez nem kötelező.
Ez egyáltalán nem stabilitási kérdés, ez egy nem jól meghúzott default a Tumbleweedben. Gondolom csak nagyobb meghajtókkal, partíciókkal, subvolume-okkal tesztelték a fejlesztők, ilyen terás méretben, és azt hitték, hogy mindenkinek lesz akkora. Arra nem gondoltak, hogy magyar a magyar fizetésből vett kisebb SSD-n nem terás tárhelyekkel gazdálkodik, és fent lehet neki több disztró is, és helyszűke fordulhat elő. Ez szimplán mentalistásbeli kérdés, ahogy a MS-nál is természetes, hogy mindenki szarja a pénz, Ferrárival a segge alatt a legújabb Surface Bookokat meg legújabb gebes csodagépeket veszi 1-2 évente, és elszállhatnak a hardverigénnyel. Ez van, ha valaki csak a saját kis világában él, és nem látja, hogy más mire használ, milyen gépeken, milyen más országokban a hardverpiac, gazdaság, fizetések. Ahogy nekünk hihetetlen, hogy pl. Kínában sokan még XP-t használnak, ilyen nagyobb nyugati helyeken meg az morbid nekik, hogy valaki még ilyen 10 éves Thinkpad-et, meg egyebet használ, meg csak kisebb SSD-je van.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Ragozhatod, de értelme nincs.
Te ragozod. :D
A snapshot mindenképp egyfajta backup, akárhová készül.
Nem, nem az.
- A hozzászóláshoz be kell jelentkezni
... hát, éppen minap jött ki a Slackware 15. Ez kevés háttérvarázslást tartalmaz, ezt szerettem benne. Cserébe több mindent neked kell összecsiszolni, viszont azt nem fogja "okosban" felülírni.
https://hup.hu/cikkek/20220204/slackware_15
- A hozzászóláshoz be kell jelentkezni
Én inkább onnan közelíteném meg a problémát, hogy miért sz*patod magad ennyi pici partícióval egy desktop gépen?
- A hozzászóláshoz be kell jelentkezni