klt Ez nem a Windows, ami kizárólag hízni tud

Azért az sem a normál működés jele. A régebbi W10 rendszerem évekig futott egy 128GB-os SSD-n, de minden más szoftverrel együtt sem volt 80GB-nál nagyobb foglaltság. Jelenleg mint másodlagos rendszer 32GB-ot foglal.
Növekmény nyilván van, hiszen a frissítések általában új funkciókat is hoznak, viszont ennek hatása egy normálisan megválasztott rendszer háttértár esetén minimális. (Az automatikus rendszermentések sem halmozódnak, hiszen meghatározott idő után törlődnek.) Nem gondolnám, hogy egy Ubuntu esetén ne ugyanez lenne a helyzet.
Én általában nem spórolok a rendszer helyével (észszerű határok között), hiszen azon történik a legtöbb lemezművelet, azon folyik a rendszer karbantartása, legtöbbször a rendszer működési mentései is oda kerülnek (nem is beszélve a használt szoftverek mennyiségéről és azok frissítéséről), nem feltétlen jó, ha ki van centizve.

Egyébként érdekesség, hogy a W10 és az Ubuntu hivatalos rendszerkövetelményei gyakorlatilag megegyeznek.

  • klt válaszolt erre.

      Rövid válasz:
      [A megfelelő óvintézkedések (adat és rendszermentés készítése és visszaellenőrzése) után] egy live rendszer alól tudod átméretezni a rendszerhez működése során csatolva lévő partíciókat, így a rendszerpartíciót is.
      Azonban én ezt most nem kapkodnám el.
      Hosszabb válasz:
      Bár nem ez a kérdésed, de szerintem igazából itt az érdekes, hogy nálad mi a nyavalya foglal 96 GB-ot a rendszerpartíción?
      Lehet, ha ezt egy picit átbeszéljük, akkor eljutunk oda, hogy egy icipici átalakítás után neked is bőségesen elég lenne az eredetileg gondolt 512 GB-os helyett egy 256 GB-os rendszerpartíció.
      Persze az is megeshet, hogy van néhány Snap alkalmazásod, ami ennyi helyet elfoglal, de én azt javasolnám, kezdjük ezzel, nézzük meg, mi foglal ekkora helyet a rendszerpartíción. Mit mutat a Lemezhasználat-elemző, mi zabálja fel a helyet?
      Igazából ennek tisztázásával és esetleg a felhasználói szokásod megváltoztatásával juthatnál el oda, hogy esetleg sokkal kisebb rendszerpartíció is elég volna neked, jóval átláthatóbb lenne számodra is a rendszered és a lemezeid, partícióid kialakítása.
      Terefere:
      Extrém felhasználói járatlansággal találkoztam már, amikor talán 256 GB volt az egész lemez, amin a rendszer csücsült és kedves felhasználó elindított egy bányász programot, ami figyelmeztette is, hogy olyan 600 GB helyet fog elfoglalni. (Emlékeim szerint ez egy Flatpak alkalmazás volt, szóval valahová a felhasználó könyvtárába egy rejtett könyvtárba tette a letöltött dolgokat és mivel a home a rendszerpartíción belül kapott helyet, hamarost betelt a rendszerpartíció.)
      Amit még el lehet követni az szerintem az, hogy ugyan van külön home vagy adatpartíció, de valaki a rendszermentés helyéül mégis a rendszerpartíciót adja meg és a rendszermentésbe belevesz mindent. Szóval nem csak magát a rendszert, hanem a felhasználói és adatfájlokat is. Na ha a következő rendszermentésben benne lesz ez a rendszermentés is, akkor létrejöhet elméletben egy jó nagy hurok.
      De ha ilyeneket leszámítunk, tudjuk, hogy van egy jó nagy home partíció, akkor a rendszerpartíciónak igazából sokkal kisebb is elég kellene legyen.
      Az én rendszerem egy picit sem óvott, napi használatban lévő, ütött-vágott rendszer, egy Linux Mint, vannak rajta Flatpak csomagok is.
      A rendszerpartíción 18 GB foglalt (a 46 GB-ból).
      A home partíción (a 279 GB-ból) 68 GB foglalt, úgy hogy itt van 8 GB-os swapfájl és Timeshift mentések is (persze az adatok [Dokumentumok, Letöltések, Képek] szokás szerint „kisymlinkelve” az adatpartícióra, szerintem ott azoknak a helye, de ez neked most mindegy, mert lehet minden ilyesmi a home partíciódon is.)

      • klt válaszolt erre.

        • klt

        • 11. bejegyzés
        • Szerkesztve

        tenkes Én általában nem spórolok a rendszer helyével (észszerű határok között),

        Én meg spórolok, szintén ésszerű határok között.
        Nyilván nem jó bájtra kicentizni, de a frissítések önmagukban nem okoznak észrevehető méretnövekedést.
        Új szoftverek telepítése nyilván lehet, hogy igen, de nem mindegy, hogy egy 3MB-os Gimagereadert telepítünk, 90MB-os GIMP-et, vagy 9 GB-os Davincit.

        tenkes hiszen azon történik a legtöbb lemezművelet, azon folyik a rendszer karbantartása

        Ez felhasználás függő, ha valaki bebútol, aztán böngészőt indít, fészbúkozgat, akkor valóban ott történik a legtöbb olvasás. Írás jellemzően csak frissítésekkor, új program telepítésekor történik oda. Nem gondolnám ezt a legtöbbnek. Ha valaki dolgozik is a géppel, akkor szükségszerűen adatfájlokkal, dokumentumokkal, képekkel (esetleg RAW képekkel), netalántán videófájlokkal ügyködik, mindjárt 2-4 nagyságrenddel több lemezművelet adódik az adatterületekre.

        csuhas32 hogy nálad mi a nyavalya foglal 96 GB-ot a rendszerpartíción?

        Csak (kb.) 72GB, amit az 1TB 7%-os foglaltságából vezettem le. A 96GB-ot én javasoltam a 72 alapján, hogy maradjon egy kis terület, hogy tudjon lélegezni a rendszer, de pocsékolásnak érzem, amit @tenkes javasol.
        (Nyilván bennem van, hogy már túlzottan is hozzászoktam a Debianhoz.)
        Emlékeim szerint van ott Blender, Krita, meg ki tudja még mi, szép testes darabok, persze valószínűleg minden snap-ből telepítve, mert az a jó az Ubuntunak, így nekem végül is hihetőnek tűnik a kb. 72GB.

        Szerk.:
        A VPS-emen a TELJES terület 20GB (mondjuk, az egyben van). Na most ezzel mit lehetne kezdeni a min. 128GB-os logika alapján?
        😃

        Amúgy kb. félig van.

        root@reflector:~# df -h
Fájlrendszer           Méret Fogl. Szab. Fo.% Csatol. pont
udev                    463M     0  463M   0% /dev
tmpfs                    97M  648K   96M   1% /run
/dev/mapper/vg-lv_root   19G  8,3G  9,3G  48% /
tmpfs                   483M     0  483M   0% /dev/shm
tmpfs                   5,0M     0  5,0M   0% /run/lock
/dev/sda1               234M   90M  133M  41% /boot
tmpfs                    97M     0   97M   0% /run/user/0
root@reflector:~#

                klt Emlékeim szerint van ott Blender, Krita, meg ki tudja még mi, szép testes darabok, persze valószínűleg minden snap-ből telepítve

                Nekem valamiért AppImage vagy valamilyen honlapról letöltött és kicsomagolt változatokról vannak emlékeim, de ezen se fogunk összeveszni. Kérek szépen @KiralyMarta -tól egy snap list kimenetet és ha megkapom, máris látjuk a jelenlegi helyzetet ezen a fronton.

                    csuhas32 a következőre módosította a címet: Lemezterület módosítása.

                    csuhas32
                    Elnézést de váratlanul kellett elmennem. elfoglalt hely:
                    Lemezek:

                    Lemezhasználat:

                    /usr/lib 6,7GB, /usr/share 2,4 GB, /var/lib 22 GB, /var/log 11.6 Gb

                    Én a foglaltságot a Lemezek alapján adtam meg, de lehet látni nagy a különbség a két adat között okát nem tudom.
                    A Log könyvtárban több syslog fájl van mind nagy de egy syslog.1 8,6 GB. Mindenkinek köszönöm a válaszát.

                        KiralyMarta /var/lib 22 GB

                        És nincs kedved a Lemezhasználat-elemzőben a kis füleket lejjebb nyitogatni, hogy mégis mi a /var/lib-ben 22 GB? (Nálam ugyanez 3,9 GB)

                        KiralyMarta /var/log 11.6 GB
                        syslog.1 8,6 GB

                        Én biztos vagyok benne, hogy egy 8 GB-os logfájlt nem fogsz végigolvasni, talán nem is tudja a rendszered megnyitni.
                        Magam ezt (meg a többi) nagy méretű logfájlt sudo rm -rf -fel szanálnám.
                        Előtte persze rendszergazdai joggal szerkeszteném a /etc/systemd/journald.conf fájlt és beletenném a
                        SystemMaxUse=50M
                        sort, hogy az újonnan létrejövő logfájlok majd már ne hízhassanak 50 MB-nál nagyobbra. (Lehet, hogy utána kell egy rendszer újraindítás, ezt nem tudom biztosra megmondani.)
                        Ez persze csak tüneti kezelés, utána jöhet a létrejövő kezelhető méretű logfájlok megnyitása, annak megkeresése, hogy miért logol folyton a rendszer és a hiba elhárítása.

                        Ezt követően a rendszerpartíciód foglaltsága máris csak 36 GB körül lesz a cirka 1000 GB-ból.
                        Talán tudunk majd még lejjebb is menni, ha megismerjük, mi van a /var/lib alatt, de szerintem már ez is eléggé kis szám, csak kezdjük közelíteni, hogy 120 GB is bőven elég lehet, ha jól be van állítva az a rendszer.

                              Amikor nekem kellett átméretezést csinálni és gparteddel csináltam live-ban. Picike, de jól működő program.
                              50 GB-nál többet nem szoktam a rendszerpartíciónak adni, eddig mindig elég volt.

                              • klt válaszolt erre.
                              • klt kedveli ezt.

                                • klt

                                • 17. bejegyzés
                                • Szerkesztve

                                csuhas32

                                csuhas32 hogy mégis mi a /var/lib-ben 22 GB?

                                Lefogadom, hogy /var/lib/snapd/ méretes lesz (oda mennek a szappan darabok).
                                🙂

                                csuhas32 /var/log 11.6 GB

                                Itt én is sejtek spórolási lehetőséget. Nálam 30MB most éppen...

                                csuhas32 csak kezdjük közelíteni, hogy 120 GB is bőven elég lehet, ha jól be van állítva az a rendszer.

                                Még ezt is sokallom, de nem az én rendszerem.

                                rapfen 50 GB-nál többet nem szoktam a rendszerpartíciónak adni,

                                👍️
                                Dettó. Csak tényleg indokolt esetben!

                                            klt Még ezt is sokallom, de nem az én rendszerem.

                                            Igazából ma nem is illik engedni a '48-ból, ha te rendszered lenne ragaszkodnék ehhez.
                                            Itt nagyságrendileg 500 GB-ról kezdjük az alkudozást, ha 120-ra le tudunk menni, szerintem szép eredmény.
                                            Majd egy következő lépésben megfelezi a 120-at és akkor is megmarad a működő rendszere plusz lesz egy tartalék rendszerpartíciója egy másik rendszer számra. :-)
                                            (Nálam már az 50 GB körüli rendszerpartíció is olyan „sose telik be, ne kelljen már figyelni rá még egy kicsit se” szándékos túlzásnak számít, a 120 GB még akkor is elég lesz szerintem, ha Márta véletlenül néha félrenyúl.)

                                            • klt kedveli ezt.

                                              klt
                                              Nálam a /var/log/journal mappa hízott folyamatosan.
                                              Mígnem meguntam, és egy root script minden rendszer indításkor törli a tartalmat.
                                              https://ibb.co/G4Xnn12r
                                              Mivel, octet-stream fájlokról van szó, van mivel megnyitni/megnézni őket?
                                              En nem ismerek ilyet.

                                                csuhas32
                                                /var/lib-ben 22 GB? snapd 21.6 GB foglalja a helyet. Log fájlal nem tudtam mit lehet kezdeni de megcsinálom amit mondasz.

                                                    • klt

                                                    • 21. bejegyzés

                                                    KiralyMarta Log fájlal nem tudtam mit lehet kezdeni

                                                    sudo journalctl --vacuum-time=5m

                                                    Ezt így próbaképp...

                                                      csuhas32
                                                      Mielőtt futtatnám sudo rm -rf fájlnév egyenként?n itt több log fájlból is van több darab azokat is törölhetem?

                                                      Összesen 8,3G
drwxrwxr-x  18 root              syslog          4,0K márc  15 07:11 .
drwxr-xr-x  15 root              root            4,0K febr  10 15:43 ..
-rw-r--r--   1 root              root            1,4K márc  11 14:02 alternatives.log
-rw-r--r--   1 root              root            3,8K febr  19 10:24 alternatives.log.1
-rw-r--r--   1 root              root             459 jan   29 06:55 alternatives.log.2.gz
-rw-r--r--   1 root              root             236 dec   22 09:05 alternatives.log.3.gz
-rw-r--r--   1 root              root             872 nov   30 07:14 alternatives.log.4.gz
-rw-r--r--   1 root              root             545 okt   24 06:01 alternatives.log.5.gz
-rw-r--r--   1 root              root            4,2K szept 30 08:37 alternatives.log.6.gz
-rw-r--r--   1 root              root            4,9K aug   29  2024 alternatives.log.7.gz
-rw-r-----   1 root              adm                0 márc  13 06:54 apport.log
-rw-r-----   1 root              adm              112 márc  12 16:25 apport.log.1
-rw-r-----   1 root              adm              134 márc   2 13:28 apport.log.2.gz
-rw-r-----   1 root              adm              116 márc   1 17:52 apport.log.3.gz
-rw-r-----   1 root              adm              134 febr  23 17:55 apport.log.4.gz
-rw-r-----   1 root              adm              134 febr   7 15:48 apport.log.5.gz
-rw-r-----   1 root              adm              268 febr   1 11:45 apport.log.6.gz
-rw-r-----   1 root              adm              215 jan   18 07:26 apport.log.7.gz
drwxr-xr-x   2 root              root            4,0K márc  13 07:26 apt
-rw-r-----   1 syslog            adm             150K márc  15 13:02 auth.log
-rw-r-----   1 syslog            adm             257K márc   9 07:15 auth.log.1
-rw-r-----   1 syslog            adm              11K márc   2 07:16 auth.log.2.gz
-rw-r-----   1 syslog            adm              27K febr  23 06:54 auth.log.3.gz
-rw-r-----   1 syslog            adm              27K febr  16 07:27 auth.log.4.gz
-rw-------   1 root              root            5,2K márc  15 07:11 boot.log
-rw-------   1 root              root             23K márc  15 07:11 boot.log.1
-rw-------   1 root              root             35K márc  14 07:04 boot.log.2
-rw-------   1 root              root             24K márc  13 06:54 boot.log.3
-rw-------   1 root              root             22K márc  12 07:00 boot.log.4
-rw-------   1 root              root             23K márc  11 07:04 boot.log.5
-rw-------   1 root              root             12K márc  10 07:12 boot.log.6
-rw-------   1 root              root             23K márc   9 07:15 boot.log.7
-rw-r--r--   1 root              root            106K aug    9  2022 bootstrap.log
-rw-rw----   1 root              utmp               0 márc   1 07:24 btmp
-rw-rw----   1 root              utmp               0 febr   1 07:30 btmp.1
drwxr-xr-x   2 root              root            4,0K márc  15 07:11 cups
drwxr-xr-x   2 cups-browsed      lpadmin         4,0K szept 22 19:01 cups-browsed
drwxr-xr-x   3 root              root            4,0K szept 22 19:24 dist-upgrade
-rw-r-----   1 root              adm              92K márc  15 07:11 dmesg
-rw-r-----   1 root              adm              92K márc  14 18:33 dmesg.0
-rw-r-----   1 root              adm              23K márc  14 07:04 dmesg.1.gz
-rw-r-----   1 root              adm              22K márc  13 18:56 dmesg.2.gz
-rw-r-----   1 root              adm              22K márc  13 16:04 dmesg.3.gz
-rw-r-----   1 root              adm              23K márc  13 06:54 dmesg.4.gz
-rw-r--r--   1 root              root            132K márc  13 07:26 dpkg.log
-rw-r--r--   1 root              root            350K febr  23 08:14 dpkg.log.1
-rw-r--r--   1 root              root            6,8K jan   29 06:56 dpkg.log.2.gz
-rw-r--r--   1 root              root             12K dec   28 16:08 dpkg.log.3.gz
-rw-r--r--   1 root              root             16K nov   30 07:14 dpkg.log.4.gz
-rw-r--r--   1 root              root             11K okt   31 06:46 dpkg.log.5.gz
-rw-r--r--   1 root              root            174K szept 30 08:37 dpkg.log.6.gz
-rw-r--r--   1 root              root            152K aug   31  2024 dpkg.log.7.gz
-rw-r--r--   1 root              root             32K szept 22 19:25 faillog
drwxr-xr-x   2 root              root            4,0K febr   9  2022 firebird
-rw-r--r--   1 root              root             15K márc  11 14:02 fontconfig.log
drwx--x--x   2 root              gdm             4,0K aug   21  2024 gdm3
-rw-r--r--   1 root              root            1,9K márc  15 07:11 gpu-manager.log
-rw-r--r--   1 root              root            1,9K márc  15 12:31 gpu-manager-switch.log
drwxr-xr-x   3 root              root            4,0K aug    9  2022 hp
drwxrwxr-x   2 root              root            4,0K aug   21  2024 installer
drwxr-xr-x   2 root              root            4,0K febr  10 15:43 ipp-usb
drwxr-sr-x+  3 root              systemd-journal 4,0K aug   21  2024 journal
-rw-r-----   1 syslog            adm             2,2M márc  15 13:02 kern.log
-rw-r-----   1 syslog            adm             2,9M márc   9 07:15 kern.log.1
-rw-r-----   1 syslog            adm             115K márc   2 07:16 kern.log.2.gz
-rw-r-----   1 syslog            adm             306K febr  23 06:54 kern.log.3.gz
-rw-r-----   1 syslog            adm             308K febr  16 07:27 kern.log.4.gz
-rw-rw-r--   1 root              utmp            286K szept 22 19:25 lastlog
drwxr-xr-x   2 root              root            4,0K márc  22  2022 openvpn
drwx------   2 root              root            4,0K aug    9  2022 private
lrwxrwxrwx   1 root              root              39 szept 22 18:54 README -> ../../usr/share/doc/systemd/README.logs
drwx------   2 speech-dispatcher root            4,0K júl   21  2022 speech-dispatcher
-rw-r-----   1 syslog            adm             285M márc  15 13:04 syslog
-rw-r-----   1 syslog            adm             8,0G márc   9 07:15 syslog.1
-rw-r-----   1 syslog            adm             630K márc   2 07:16 syslog.2.gz
-rw-r-----   1 syslog            adm             1,7M febr  23 06:54 syslog.3.gz
-rw-r-----   1 syslog            adm              15M febr  16 07:27 syslog.4.gz
drwxr-xr-x   2 root              root            4,0K jan    9  2024 sysstat
-rw-r--r--   1 root              root               0 szept 22 18:34 ubuntu-advantage-apt-hook.log
-rw-r--r--   1 root              root               0 szept 23 07:04 ubuntu-advantage.log
-rw-r--r--   1 root              root            2,7K szept 22 19:07 ubuntu-advantage.log.1
drwxr-x---   2 root              adm             4,0K márc   1 07:24 unattended-upgrades
drwxr-xr-x   2 root              root            4,0K szept 22 19:07 upgrade
-rw-r--r--   1 root              root             102 márc   6 07:25 vbox-setup.log
-rw-r--r--   1 root              root             102 márc   2 12:02 vbox-setup.log.1
-rw-r--r--   1 root              root             102 febr  12 18:42 vbox-setup.log.2
-rw-r--r--   1 root              root             102 jan   29 15:32 vbox-setup.log.3
-rw-r--r--   1 root              root             102 jan   28 00:17 vbox-setup.log.4
-rw-rw-r--   1 root              utmp            650K márc  15 07:12 wtmp
root@marta-ubuntu:/var/log#

                                                          • klt

                                                          • 23. bejegyzés

                                                          KiralyMarta A ###.szám.log és .gz simán törölheted, de szerintem nem érdemes görcsölni rajta. Alig jelent nyereséget. Neked a journal alatt lesz a sok szemét, arra meg jó a porszívózás, amit adtam.

                                                            KiralyMarta Én itt egyetlen óriási fájlt látok, csak arra adnám ki a
                                                            sudo rm -rf /var/log/syslog.1 parancsot. A kicsikkel nem kell foglalkozni, semmi jelentőségük, nem zavarnak senkit és semmit, viszont lehet van bennük értékes információ, azokat nem bántanám.

                                                            • klt válaszolt erre.

                                                                • klt

                                                                • 25. bejegyzés

                                                                csuhas32 Én itt egyetlen óriási fájlt látok, csak arra adnám ki a
                                                                sudo rm -rf /var/log/syslog.1

                                                                Tényleg, ez hogy nem ütötte ki a szemem!?

                                                                    OFF
                                                                    Azért érdekes, hogy a Windows van elkönyvelve egy végletekig feleslegesen növekvő rendszerré, miközben itt mindenkinek megvan a maga trükkje, hogyan szoktassa le erről a Linuxot. 🙂
                                                                    Az ok amiért én más tárhely mértekben gondolkodom, nem feltétlen a Windows-Linux eltérésekből adódik, hanem mert egy ideje rászoktam arra, hogy a rendszer és a tárhely valóban külön fizikai meghajtón van. Így rendszerre a manapság elérhető legkisebb SSD méretekben gondolkodom 128/256. Mivel ezeknek csak a rendszer futtatása a feladatuk, nincs ok a méretek csökkentésére.
                                                                    Egy 2TB-os tároló ilyen felosztása azért nem egy szokványos megoldás.
                                                                    ON

                                                                    • klt válaszolt erre.

                                                                      klt

                                                                      Ezt viszont te találtad el:

                                                                      KiralyMarta var/lib-ben 22 GB? snapd 21.6 GB foglalja a helyet.

                                                                      Szerintem lassan megvagyunk, most már elegendő az információ, Márta el tudja dönteni mekkorára szeretné zsugorítani a rendszerpartícióját, a módja pedig már régen nem kérdés.

                                                                            A Snap és a Flatpak esetén is előfordul, hogy egy app futtatásához, egy nagyságrendileg nagyobb csomag letöltésére is szükség van (hiszen nincs benne az alaprendszerben). Miután ezt automatikusan teszi meg, okozhat meglepetést.