staging.inyokaproject.org

So ist es. Habe jetzt das Ganze nocheinmal ausgeführt und diesmal auch gespeichert...

Hallo,

JETZT sehe ich auch was 😉 IMHO ok.

Gruß, noisefloor

In der Tabelle Manuelle_Partitionierung#Vorüberlegungen wird als Swap-Größe für Suspend to disk 2xRAM + 20-30% empfohlen. Im Artikel Swap werden RAM+ 1GB empfohlen - was ich für realistisch halte. Da im vorhergehenden Satz RAM+20-30% als Faustregel erwähnt wird, gehe ich nicht von einem Tippfehler aus.

Natürlich kann man keine allgemeingültige Empfehlung aussprechen, aber ich denke, das sollte nach Möglichkeit wikiweit einheitlich sein. Wo sollte man das jetzt ändern, bzw. auf welche Empfehlung kann man sich hier einigen?

Hallo,

auf welche Empfehlung kann man sich hier einigen?

Frag' 5 Leute und du bekommst 6 Meinungen 😉

Allerdings ist meine Lesweise des Artikels anders: es werden verschiedene SWAP-Größen empfohlen, je nach dem, ob man suspend-to-disk benutzt oder nicht. Aber warum soll man bei suspend-to-disk eigentlich so viel SWAP-Speicher brauchen?

Gruß, noisefloor

noisefloor schrieb:

Aber warum soll man bei suspend-to-disk eigentlich so viel SWAP-Speicher brauchen?

Ja eben. Ich habe das gerade noch mal nachgesehen, das wurde am 21.6. erst geändert mit dem Kommentar:

21. Juni 2016 14:33 : Hat man im Web-Browser viele Tabs offen und zudem noch MySQL Workbench und Android Studio laufen, wird der Speicher schnell knapp. Grösserer Swap-Bereich ist angeraten.

Ich halte das für einen Spezialfall, der so nicht ins Wiki gehört.

Stattdessen halte ich aber 200 MB für Boot inzwischen mit dem 4er Kernel für zu knapp. Da würde ich eher zu 500 MB raten?

Gibt es zu beidem Meinungen?

lionlizard schrieb:

Ich halte das für einen Spezialfall, der so nicht ins Wiki gehört.

+1 Zumal Swap als RAM-Ergänzung immer nur ein Notbehelf ist.

Stattdessen halte ich aber 200 MB für Boot inzwischen mit dem 4er Kernel für zu knapp. Da würde ich eher zu 500 MB raten?

Bei Preisen von unter 1 € pro GB selbst für SSDs würde ich nicht "knausern" und gleich ein ganzes GB spendieren.

Thomas_Do schrieb:

Bei Preisen von unter 1 € pro GB selbst für SSDs würde ich nicht "knausern" und gleich ein ganzes GB spendieren.

Prinzipiell wohl nicht verkehrt, wenn man aber mit mehreren verschlüsselten Installationen arbeitet, läppert sich das doch recht schnell. Bei meiner 119 Gib Laptopplatte wäre mir das zu viel, und mit 500 MB kann man ja durchaus 3 Kernel-Gernationen und einen Low-Latency fürs Vinyl-Platten einlesen verwalten, ohne dass man Probleme bekommt.

Aber mal sehen, was andere dazu meinen… 😉

Hi.

Also ich hab auf der Seite kürzlich ein bisschen rumeditiert. Leider war ich nicht ganz konsequent, da unten Screenshots sind mit GB-Grössen und der Text teilweise darauf bezug nimmt.

Ich bin auf Linux umgestiegen und hab mir die Seite "manuelle Partitionierung" gründlich durchgelesen und alles so gemacht. Resultat: Wenn ich einen alten Kernel behalte und es kommt eine Aktualisierung, dann geht die schief, weil 3 Versionen nicht bei mir in /boot reinpassen.

Sodann hab ich mir jetzt ein neues Motherboard gekauft und weil RAM so billig ist, gleich 8GiB RAM rein. Das passt jetzt aber nicht mehr in meine swap, weil die nur 8000 MiB hat (und das sind eben keine 8GiB). Wenn mein RAM also voll ist, geht kein suspend-to-disk mehr.

Find ich total ärgerlich, denn ich hätte 160GB auf der Platte gehabt und hätte gar nicht sparen müssen. Von daher ist sehr kleinlich, beim /boot hier über ein Paar MB mehr oder weniger zu diskutieren. Hat man nämlich die partition zu klein gemacht, dann kann man es hinterher nur noch sehr schlecht korrigieren.

Beim Swap genauso, wer kuckt denn heute noch auf 10GB, wenn es kaum noch Platten unter 500GB gibt.

Swap (immer empfohlen)

kein Swap: nur bei ausreichend Arbeitsspeicher für den maximal Belastungsfall

empf: 512 MiB (falls so viel Swap tatsächlich aktiv genutzt wird, reagiert das System extrem langsam)

StD: ca. 1 x RAM * 512 MiB (bessere Empfehlung? Unterteilung?)

max: 4GB (Mehr macht selten Sinn - konkretes Szenario?, großes Projekt pausieren?)

Empfohlen 512MiB??? Wenn ich Android-Studio, Chrome und MySQl-Workbench laufen habe, da hatte ich 4GiB im RAM und 3GiB im Swap! Warum soll das denn langsam sein? Jetzt habe ich 8GiB RAM, wo soll das denn hin wenn ich Suspend-to-Disk mache??

Immer dran denken: wer heute eine Platte partitoniert, der nutzt das vielleicht 4-8 Jahre, und in der Zeit tut sich viel! Nicht ohne Grund planen ledige Paare beim Hausbau schon das Kinderzimmer mit ein.

Ubuntu läuft ja nicht nur auf Desktop-Rechnern oder modernen Netbooks, die mit RAM nur so prahlen können, sondern auch auf bekannten Einplatinen-Computern, etc. Dort ist meistens schnell Ende mit der Hardware. Insofern fände ich einen Minimalvorschlag immer passend.

btw: In Zeiten von Verschlüsselung und LVM kann man einzelne groups nachträglich sehr einfach vergrößern.

Zu stfischr's Vorschlag: Ich finde den etwas zu unübersichtlich mit den Beispielen darin. Möglicherweise wäre eine tabellarische Übersicht besser geeignet, nach Verwendung, Größe, Beschreibung?

Also bspw:

Wenn, dann so:

Das wäre zu speziell, denke ich. Minimum ist ja auch abhängig von dem, was man aufbauen will, etc. Da müsste man dann für minimal, Standard und Desktop jeweils ne Beschreibung/Kommentarspalte einfügen.

Wenn es aufgedröselt würde, wäre das wohl sinniger ne Extraseite mit Beispielen zu machen und jedem eine Tabelle zu spendieren. Aber ich möchte die weder erstellen, noch pflegen müssen ☺

Da es nicht DIE Aufteilung gibt, könnte man sich da quasi ne Datenbank anlegen mit Modell/Komponenten-Abfrage und per Script einen Vorschlag generieren...

Ich würde nicht so viel ändern wollen, da halte ich es mit noisefloor:

Frag' 5 Leute und du bekommst 6 Meinungen 😉

jms3000 schrieb:

Sodann hab ich mir jetzt ein neues Motherboard gekauft und weil RAM so billig ist, gleich 8GiB RAM rein. Das passt jetzt aber nicht mehr in meine swap, weil die nur 8000 MiB hat (und das sind eben keine 8GiB). … Find ich total ärgerlich, denn ich hätte 160GB auf der Platte gehabt und hätte gar nicht sparen müssen.

Deswegen aber die doppelte Swap-Größe zu empfehlen, halte ich für übertrieben. Bei RAM+30% ist klar, wenn ich mehr RAM reinstecke, werde ich auch Swap vergrößern müssen (für Suspend to disk )

… wer kuckt denn heute noch auf 10GB, wenn es kaum noch Platten unter 500GB gibt.

SSD-Platten sind teilweise noch deutlich unter 500 GB, und da können 10 GB durchaus eine Rolle spielen - da bringe ich schon mal ein Rettungs-Lubuntu unter (meine Grundinstalltion nimmt ca. 5 GB ein)

Swap (immer empfohlen)

Empfohlen 512MiB??? Wenn ich Android-Studio, Chrome und MySQl-Workbench laufen habe, da hatte ich 4GiB im RAM und 3GiB im Swap!

Das halte ich für einen Spezialfall. Browser, Bildbearbeitung, Videoschnitt und LibreOffice Writer haben bei mir den Swap nicht mal angefasst. Bei 4-8 GB RAM wird Swap eher selten benötigt.

Jetzt habe ich 8GiB RAM, wo soll das denn hin wenn ich Suspend-to-Disk mache??

Wenn man jetzt nicht umpartitionieren will, könnte man beispielsweise eine Swap-Datei anlegen.

Immer dran denken: wer heute eine Platte partitoniert, der nutzt das vielleicht 4-8 Jahre, und in der Zeit tut sich viel! Nicht ohne Grund planen ledige Paare beim Hausbau schon das Kinderzimmer mit ein.

Nun ist ein Rechner kein Haus, und in 4 bis 8 Jahren dürften schon durch die Updates mindestens 2 bis 3 Neuinstallationen fällig werden. Denn auch wenn ein Update von einer LTS auf die andere möglich ist, habe ich bisher nur Empfehlungen gelesen, beim LTS Versionswechsel die nächste LTS sauber neu zu installieren.

stfischr schrieb:

/boot (nur nötig bei Vollverschlüsselung oder speziellen, nicht von Grub unterstützen Dateisystemen/Raids)

• min: 256 MiB (genug für ca. 5 Kernel, regelmäßiges autoremove)

• empf: 512 MiB (ca. 10 Kernel)

• max: 1 GB (wüste kein Szenario wo das nicht reicht)

256 MB für /boot halte ich aber für zu wenig.

benutzer@Rechner:~$ df -h /boot
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sdb9       477M    213M  235M   48% /boot
benutzer@Rechner:~$ du -sh /boot
du: das Verzeichnis '/boot/lost+found' kann nicht gelesen werden: Keine Berechtigung
211M	/boot
benutzer@Rechner:~$ ls -l /boot
insgesamt 208193
-rw-r--r-- 1 root     root      1239732 Jun  8 23:39 abi-4.4.0-24-generic
-rw-r--r-- 1 root     root      1240417 Jun  9 00:47 abi-4.4.0-24-lowlatency
-rw-r--r-- 1 root     root      1240018 Jun 24 14:03 abi-4.4.0-28-generic
-rw-r--r-- 1 root     root      1240703 Jun 24 15:03 abi-4.4.0-28-lowlatency
-rw-r--r-- 1 root     root       189521 Jun  8 23:39 config-4.4.0-24-generic
-rw-r--r-- 1 root     root       189451 Jun  9 00:47 config-4.4.0-24-lowlatency
-rw-r--r-- 1 root     root       189533 Jun 24 14:03 config-4.4.0-28-generic
-rw-r--r-- 1 root     root       189463 Jun 24 15:03 config-4.4.0-28-lowlatency
drwxr-xr-x 2 stepfahn stepfahn     1024 Apr 22 22:28 efi
drwxr-xr-x 2 root     root         1024 Jul  4 22:43 grub
drwxr-xr-x 3 root     root         1024 Mai 13 12:16 grub-pc
lrwxrwxrwx 1 root     root           27 Jun 30 22:25 initrd.img -> initrd.img-4.4.0-28-generic
-rw-r--r-- 1 root     root     37318355 Jun 23 19:25 initrd.img-4.4.0-24-generic
-rw-r--r-- 1 root     root     37308021 Jul  4 21:51 initrd.img-4.4.0-24-lowlatency
-rw-r--r-- 1 root     root     37311889 Jul  1 11:19 initrd.img-4.4.0-28-generic
-rw-r--r-- 1 root     root     37309304 Jul  4 21:40 initrd.img-4.4.0-28-lowlatency
drwx------ 2 root     root        12288 Apr 22 18:19 lost+found
-rw-r--r-- 1 root     root       182704 Jan 28 13:44 memtest86+.bin
-rw-r--r-- 1 root     root       184380 Jan 28 13:44 memtest86+.elf
-rw-r--r-- 1 root     root       184840 Jan 28 13:44 memtest86+_multiboot.bin
-rw------- 1 root     root      3855383 Jun  8 23:39 System.map-4.4.0-24-generic
-rw------- 1 root     root      3856808 Jun  9 00:47 System.map-4.4.0-24-lowlatency
-rw------- 1 root     root      3859655 Jun 24 14:03 System.map-4.4.0-28-generic
-rw------- 1 root     root      3861080 Jun 24 15:03 System.map-4.4.0-28-lowlatency
lrwxrwxrwx 1 root     root           24 Jun 30 22:26 vmlinuz -> vmlinuz-4.4.0-28-generic
-rw------- 1 root     root      7020176 Jun  8 23:39 vmlinuz-4.4.0-24-generic
-rw------- 1 root     root      7022104 Jun 15 10:05 vmlinuz-4.4.0-24-generic.efi.signed
-rw------- 1 root     root      7050656 Jun  9 00:47 vmlinuz-4.4.0-24-lowlatency
-rw------- 1 root     root      7026864 Jun 24 14:03 vmlinuz-4.4.0-28-generic
-rw------- 1 root     root      7028792 Jun 28 01:13 vmlinuz-4.4.0-28-generic.efi.signed
-rw------- 1 root     root      7058144 Jun 24 15:03 vmlinuz-4.4.0-28-lowlatency
benutzer@Rechner:~$ 

Das ist meine Belegung von /boot und kürzlich gabs hier mal wieder die Anfrage, dass für die Installation eines neuen Kernels 119 MB freier Platz benötigt wurden. Daher sind m.E. für /boot 500 MB inzwischen Minimum. Aber wenn allgemein 1 GB für sinnvoll gehalten werden, kann ich das auch vertreten.

Man kann ja den Leuten empfehlen, aber man sollte auch dazusagen: Leute, wenn ihr Platz habt, seid an dieser und jener Stelle grosszügig.

(Ich habe 4x in 30 Jahren ein System neu installiert, der Rest waren nur Updates)

Auf die anderen Dinge gehe ich später noch ein, jetzt fehlt gerade die Zeit.

ChickenLipsRfun2eat schrieb:

Ubuntu läuft ja nicht nur auf Desktop-Rechnern oder modernen Netbooks, die mit RAM nur so prahlen können, sondern auch auf bekannten Einplatinen-Computern, etc. Dort ist meistens schnell Ende mit der Hardware. Insofern fände ich einen Minimalvorschlag immer passend.

Genau. Meine angegebenen Größen sind nur Vorschläge, wir sollten uns hier auf die besten/sinnvollsten Werte einigen.

Zu stfischr's Vorschlag: Ich finde den etwas zu unübersichtlich mit den Beispielen darin.

Natürlich, das war nur die quick&dirty Version, ich hatte nicht vor das so ins Wiki zu rotzen. 😀

lionlizard schrieb:

Das ist meine Belegung von /boot

und ein absoluter Spezialfall. Wer unbedingt 3 Versionen von jedem Kernel vorhalten will, dem sollte klar sein, dass er nicht die minimale Partitionsgröße wählen kann (da steht ca 5 Kernel).

Wer wenig Platz hat, aber ne extra /boot braucht, kommt mit 256MiB gut hin. Gerne kann man Fälle erwähnen, die mehr benötigen.

und kürzlich gabs hier mal wieder die Anfrage, dass für die Installation eines neuen Kernels 119 MB freier Platz benötigt wurden.

In /boot? Glaube ich nicht, Link?

Daher sind m.E. für /boot 500 MB inzwischen Minimum. Aber wenn allgemein 1 GB für sinnvoll gehalten werden, kann ich das auch vertreten.

Mit einer Standardinstallation in 64 Bit ist /boot nach autoremove 151 MiB groß, notfalls muss man vor einem Upgrade alle alten Kernels manuell löschen. Daher wurden entsprechende Einschränkungen und Pflegehinweise gegeben. Min != Empfohlen