Ik heb een laptop met een 500Gb HD
De indeling was
20GB-root (ext4)
2GB -swap
en de rest toegewezen als /home (ext4)
Nu heb ik de boel op nieuw geïnstalleerd en geformatteerd.
Root is nu BTRFS en /home XFS
20GB als root, bleek te klein, en raakte heel snel vol.
Heb de partitie dan ook vergroot (nu 50GB)
Moet eerlijk zeggen dat ik dat maar heb gegokt.
Wat is eigenlijk de aanbevolen grote van een root partitie bij een BTRFS indeling?
Goed gegokt. De aanbevolen grootte is 40GB, maar eigen ervaring met TW leert dat dat nog wel 's aan de krappe kant kan zijn doordat er meer snapshots gemaakt worden.
Voor een TW installatie hanteer ik meestal
50 GB voor /
2 x RAM grootte voor swap ( bij meer dan 4 GB gebruik ik geen swap, maar als je bijv. suspend-to-disk veel gebruikt, wel doen )
Rest voor /home (en evt. andere zaken. Ik hou bijv. muziek buiten de gebruiker homes op een aparte partitie, aangekoppeld op /Muzickx)
Op laptops gebruik ik nog steeds geen btrfs, nare ervaringen met mijn laptop die opeens zonder stroom zat. Tegenwoordig zijn er prima tools om btrfs te repareren bij zoiets, maar XFS en ext4 doen 't voor mij prima. Op desktops/servers gebruik ik wel btrfs voor /.
Bedankt voor het snelle antwoord.
Is er nog een nadeel als je wel swap hebt, en meer dan 4 Gb geheugen?
Of is het alleen maar zonder van de ruimte op je HD…?
Niet gebruikte swap is alleen maar ruimte niet gebruikt.
Maar ik begrijp dat je een laptop hebt. Zoals Knurpht zegt, als je dan suspend to disk wilt doen moer je geheugen wel in swap gesuspend kunnen worden. Dat gebeurt gecomprimeerd, dus zou swapgrootte gelijk aan geheugengrootte genoeg moeten zijn.
Bedankt voor de info.
Zal het doen zoals je voorstelt…
Hallo allen,
Even op inhaken: ingeval je / partitie met ext4 is geformatteerd wat is dan de minimum grootte?
vraag 2: waarom gebruikt OpenSuSE zoveel ruimte in de root?
Grtz
Karel
Voor ext4 is de verstekgrootte 20GB.
Bij mij is dat i.h.a. voor ⅓ gevuld, dus ruim voldoende. MMaar ik guik maaééen Desktop Environment en vered ook niet zoveel extr sofftware. Wel is LAMP geïnstalleerd.
Vraag 2 duidt volgens mij op door jou gedachte zaken, Aangezien je die niet vermeldt kan ik alleen maar reageren met:
Hoezo zoveel? Er wordt zoveel gebruikt als nodig is. Als 13 GB veel voor je is moet je kijken of je met minder software toe kan. Maar meestal kan er niet veel weg. Als het niet om een klein/oud systeem gaat is 20 GB op de huidige schijven van 0.5 en meer TB een lachertje. Gaat het wel om een oud systeem met weinig schijfruimte, geheugen en langzame CPU, probeer dan een kleine Linux. Er zijn er genoeg.
Zoals Henk al aangeeft, standaard wordt voor ext4 ~20GB aangehouden. Ik heb zelf KDE Plasma5 en GNOME geïnstalleerd, LAMP server, kernel-sources ivm NVIDIA driver en zit nu op ~12 GB.
Op vraag 2: omdat sinds enige jaren btrfs het standaard filesystem is voor de systeempartitie ( aangekoppeld op “/” ). Het mooie aan btrfs is dat het kan snapshotten, dwz. momentopnames van het systeem maken. Stel nou dat je je systeem onbruikbaar maakt, dan kun je terug naar een vorig snapshot en zo in no time je systeem weer in de lucht hebben. Die snapshots worden op in “/.snapshots” opgeslagen en daar is ruimte voor nodig. Standaard wordt 40GB voorgesteld, ik gebruik zelf vaak meer dan 40GB als er toch genoeg beschikbaar is. Veel servers hebben tegenwoordig ook een SSD om het OS van te draaien, databases etc. dan buiten de root partitie, die lekker groot ( zodat je regelmatig kunt snapshotten ).
Dank hcvv en knurpht voor jullie reacties.
Eens: ik had duidelijker moeten zijn;
Hardware:
Desktop met quad AMD FX
8gb intern
ssd 60 gb
hdd 2 tb
Geen 2e besturingssysteem
3 dagen geleden heb ik tumbleweed geïnstalleerd op de ssd met de volgende partities:
4gb swap
20gb / ext4
36gb /home ext4
Plasma5 als enige Desktop
Standaard install aangevuld met VLC, Kodi, en allerlei codecs.
Update gedaan en verder wat gedownload naar mijn gewone 2 tb hdd (oa een torrent van Leap 42.1)
Na de download start ik op en krijg de waarschuwing dat mijn /tmp vol zit en KDE dus niet kan starten. Live DVD opgestart en/tmp en /var/tmp gecheckt. Daar zit een schamele 800 mb in. De / partitie geeft aan vol te zitten. (De volle 20 gb dus)
Met Manjaro gebruikte ik ook rond de 11gb met ext4 in /
Nu lees ik dat jullie dezelfde waardes hebben.
Vandaar mijn vraag waarom Suusje zoveel gebruikt.
Klaarblijkelijk gaat er bij mij iets niet goed.
Ik zal op onderzoek uitgaan. Suggesties in een bepaalde richting?
Gr Kage
Met Ctrl-Alt-F2 kun je naar een virtuele console. Log daar in en doe
cd /
cat /etc/fstab
df -h
sudo du -h --max-depth=1
Maak van ieder commando een foto, zet die ergens op het web en post de links hier.
Naar de verkeerde plek gedownload?
Die 2TB disk komt ineens uit de lucht vallen. Tot nu toe had je alleen 4 + 20 + 36 (= 60) GB aan diskruimte in je systeem. Iets meer precisie bij wat je vertelt en iets minder denken dat wij “het wel zullen snappen” is misschien handig.
Hopelijk komen we er met de gegevens die Knurpht vraagt (en daarna verder zoeken wat er zo groot is) uit.
Goedemorgen Knurpht,
Bij deze even de tekst uit de konsole geknipt / geplakt
kanux@linux-wg8y:~> cd /
kanux@linux-wg8y:/> cat /etc/fstab
UUID=6886a24f-2667-479b-9317-80544203f8bb swap swap defaults 0 0
UUID=8adaa40c-1bf3-489a-801b-ae3b274dde92 / ext4 acl,user_xattr 1 1
UUID=da091e95-bcf6-48f0-9c45-8a8b2da8c5d2 /home ext4 acl,user_xattr 1 2
/dev/sdb3 /media/Opslag ntfs-3g defaults 0 0
kanux@linux-wg8y:/> df -h
Bestandssysteem Grootte Gebruikt Besch Geb% Aangekoppeld op
devtmpfs 3,9G 0 3,9G 0% /dev
tmpfs 3,9G 39M 3,9G 1% /dev/shm
tmpfs 3,9G 2,3M 3,9G 1% /run
tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup
/dev/sda2 20G 17G 1,2G 94% /
/dev/sda3 34G 13G 21G 38% /home
/dev/sdb3 1,7T 1,6T 134G 93% /media/Opslag
tmpfs 799M 12K 799M 1% /run/user/1000
kanux@linux-wg8y:/> sudo du -h --max-depth=1
[sudo] wachtwoord voor root:
5,2M ./bin
2,1M ./run
4,0K ./opt
160K ./dev
12M ./root
34M ./boot
349M ./lib
8,3M ./sbin
4,0K ./mnt
4,0K ./selinux
11G ./var
0 ./sys
17M ./etc
5,8G ./usr
752K ./tmp
1,4M ./srv
16K ./lost+found
du: kan geen toegang krijgen tot ‘./proc/4855/task/4855/fd/4’: Bestand of map bestaat niet
du: kan geen toegang krijgen tot ‘./proc/4855/task/4855/fdinfo/4’: Bestand of map bestaat niet
du: kan geen toegang krijgen tot ‘./proc/4855/fd/3’: Bestand of map bestaat niet
du: kan geen toegang krijgen tot ‘./proc/4855/fdinfo/3’: Bestand of map bestaat niet
0 ./proc
16M ./lib64
1,6T ./media
13G ./home
1,6T .
kanux@linux-wg8y:/>
kanux@linux-wg8y:/>
Alle uitkomsten staan hierboven. Daarbij valt direct de omvang van /var op
Dank vast voor je hulp
kage
Goedemorgen Henk,
Ik begon mijn tweede post met dit stukje tekst.
Eens: ik had duidelijker moeten zijn;
Hardware:
Desktop met quad AMD FX
8gb intern
ssd 60 gb
hdd 2 tb
Dat heb je misschien gemist.
Hierin geef ik mijn fout aan en licht verder toe welke hardware ik heb en wat er precies fout ging.
Ik snap heel goed dat het voor jullie als gewaardeerde helper vervelend is om te moeten gokken wat er nu precies bedoeld word.
Daarom juist geef ik mijn fout toe en ben dan ook verbaasd dat je daarna zo reageert.
Is hiermee de kou uit de lucht?
Een hele mooie dag allemaal!
kage
Ik moest ook even terug kijken, en de hele draad doorlezen. Het misverstand ontstaat o.a. omdat je op een bestaande draad aanhaakt, wij zoeken evt. info in de eerste posts en dan mis je zoiets snel. Advies: maak je eigen onderwerp/draad aan.
En terug naar het probleem: inderdaad /var . Om nu te achterhalen waar 't probleem binnne /var zit, doe je
cd /var
su -c 'du -h --max-depth=1'
Je kunt dan zien in welke onderliggende map die gigabytes aan data staan. Één van de usual suspects is /var/log
Ondertussen is het zaak om uit te vogelen waardoor die data daar worden weggeschreven.
Dank voor je reactie Knurpht,
Ik zal idd mijn eigen draadje starten in de toekomst.
De uitkomst van sudo du -h --max-depth=1:
kanux@linux-wg8y:~> cd /var
kanux@linux-wg8y:/var> su -c ‘du -h --max-depth=1’
Wachtwoord:
2,1M ./run
4,0K ./opt
4,0K ./db
161M ./cache
8,2G ./lib
84M ./adm
137M ./log
4,0K ./games
12K ./yp
202M ./tmp
124K ./spool
4,0K ./crash
8,7G .
kanux@linux-wg8y:/var>
ik ben verbaasd over 8.7g aan het einde. Daar staat alleen een punt. Heb in de dir gekeken maar kan daar niets van die omvang vinden. Dit is klaarblijkelijk de reden waarom mijn root volzit/volloopt
gr
Kage
Eerst even een forum technisch aspect. Je post je computer teksten op een manier om ze af te scheiden van de rest van het verhaal. Zeer goed. Alleen kan het beter door niet de QUOTE ma de CODE “tags” te gebruiken. Dat is de knop met het #.
Ten tweede mag het zo zijn dat je een stukje hardware, die 2TB disk hebt vermeld, maar dat zegt er niets over of die in gebruik is. Daar moet eerst een file systeem op gemaakt worden (of één of meer partities and daar file systemen op) en dat/die file syste(e)m(en) moeten errgens “gemount” worden. En daar zeg je niets over.
Wel laat nu je uitvoer dat zien.
Afgezien van de hulp bij het zoeken die je van Knurpht krijgt, valt mij het volgende op:
Je root partitie is 94% vol. Dat wil inderdaad zeggen dat gewone (niet root) gebruikers geen bestanden meer kunnen aanmaken/uitbreiden. Dat heeft waarschijnlijk het gevolg dat gewone gebruike niet meer met de GUI kunnen inloggen omdat de GUI tijdelijke bestanden voor die gebruikers gaat aanmaken.
Met root inloggen in de CLI moet nog steeds mogelijk zijn. Die 5% reserve kan door root wel gebruikt worden en bovendien, het inloggen in de GUI maakt niet veel rommel aan zoals de GUI. Uit de hand gelopen logs, zoals boven geconstateerd lijkt de oorzaak. Maar er moet natuurlijk wel gekeken worden waarom die logs zo groot worden.
Ook zien we dat sdb3 (zijn sdb1 en sdb2 er ook?) een NIET Linux bestandssysteem is. Het is ook al aardig vol. Verder zien we dat je dat hebt gemount binnen de /media directory boom. Dat is ioet aanbevelenswaardig. /media is bedoeld voor gebruik door “het systeem” en je zou dus “het systeem” dwars kunnen zitten.
Die 8.7GB voor . is gewoon het totaal van alles wat er in die map /var zit. De “boosdoener” is /var/lib. Die kun je ook weer in gaan en het commando uitvoeren, en zo kom je erachter waar evt. grote bestanden zitten. Bij mij is /var/lib nog geen 1 GB groot, ik draai Tumbleweed en “rol” al een paar jaar voort op dezelfde “/”, oudste mappen zijn uit begin 2014.
Hoi Knurpht.
Dank voor je snelle reactie. Idd is de boosdoener /var/lib. Om precies te zijn is het /var/lib/systemd/coredump. Sinds de installatie is daar dagelijks naar toe geschreven. Ik had overigens hetzelfde probleem met Leap 42.1.
Is de coredump van deze omvang noodzakelijk?
gr
Kage
Noodzakelijk is 't blijkbaar. Ik heb 't in het verleden wel gezien met een kapot RAM bankje, zal 's even kijken of dit meer voorkomt.
Je zou kunnen kijken naar de output van
journalctl | grep -i coredump