klt vagy legyen mondjug 64GB...
KiralyMarta 1TB rendszer
KiralyMarta A rendszer lemez (gyökér) 7% foglaltság
Én rendszernek sem mennék nagyon 128GB alá, de inkább 256 v. 512. KI tudja milyen szoftverre szottyan kedve az embernek.
klt vagy legyen mondjug 64GB...
KiralyMarta 1TB rendszer
KiralyMarta A rendszer lemez (gyökér) 7% foglaltság
Én rendszernek sem mennék nagyon 128GB alá, de inkább 256 v. 512. KI tudja milyen szoftverre szottyan kedve az embernek.
tenkes Én rendszernek sem mennék nagyon 128GB alá, de inkább 256 v. 512.
Ez nem a Windows, ami kizárólag hízni tud a sosem fogyatkozó WinSxS könyvtárával
Azt gondolom, ezt a rendszert már használja már egy ideje, feltehetően minden rajta van már, amire szüksége van.
Nagy hízásra nem kell számítani, ha csak meg nem gárgyul valami, és telef*ssa a logot hibajelzésekkel (de az meg megeshet nagyobb rendszerpartíció esetén is).
A mostani rendszerpartíció foglalt helyét megtolnám 30%-kal, és az lenne az új mérete.
Visszaszámolva, 72GB körül lehet ez, (1TB @ 7%), szóval kb. 96GB. Most így erre rácsodálkozva még ez is igen terebélyesnek tűnik nekem, de tény, hogy nálam nem Ubuntu van...
Én nem venném annál nagyobbra, adatterületként nekem hasznosabbnak tűnik a tárhely, mint üresen tartott helyként a rendszerpartíción
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.
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.)
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
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.
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
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.
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#
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.
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