News Ubuntu Pro: Kostenlos mehr Sicherheit auch für Privatanwender

andy_m4 schrieb:
Das ist ja eher ein Argument etwas Swap ruhig zu erlauben, weil es freidrehender Prozess eben nicht dazu führt, das massiv in den Swap gedrückt wird.

Tut mir leid. Die Beschreibung gibt so keinen Sinn?

CGroup sind dafür da ein Limit zu erzwingen. Wenn die SMS-Anwendung undefiniert RAM allokiert, schießt man die ab und das System zu schützen. Wenn Firefox zu viel allokiert, schießt man den ab um die komplette restliche(n) Usersession(s) und das System zu schützen.

SWAP hat tatsächlich den Nutzen Zeit zu erkaufen für den OOM oder OOMD. Das wird hoffentlich durch bessere Lösungen (CGroups und Namespace) und einem verlässlicheren OOM egalisiert. Bei Allzweckcomputern ist das jedoch aufwendiger als bei Embedded (da steht das hoffentlich in der Spec).
 
flaphoschi schrieb:
Tut mir leid. Die Beschreibung gibt so keinen Sinn?
Dann lies es noch mal und frage bei unklaren Stellen konkret nach. :-)

flaphoschi schrieb:
CGroup sind dafür da ein Limit zu erzwingen.
Exakt.

flaphoschi schrieb:
SWAP hat tatsächlich den Nutzen Zeit zu erkaufen für den OOM oder OOMD.
Ähm nein. Nicht nur.

Swap ermöglicht es dem System Speicher auszulagern, den es selten (oder im Augenblick gar nicht) braucht. Das ist halt auch eine Art der Optimierung.
Außerdem kommt es durchaus vor, das man mehrere Programme parallel laufen hat und das man z.B. auch mal kurz ne VM startet, um schnell mal was zu testen oder was auch immer. Da gibt Swap dann ne gute Möglichkeit das zu überbrücken und entsprechend zu handhaben.

Legt man keinen Swap an, beraubt man sich dieser Möglichkeit.

Hinter der Überlegung, keinen Swap zu vergeben, steckt ja eigentlich die Idee, das man halt nicht will das das System unnützerweise auslagert. Weil auslagern ist langsam. Und wenn ich genug RAM habe, dann besteht ja nicht mehr die zwingende Notwendigkeit zu swappen. Damit das System das nicht versehentlich von sich aus macht, knipst man Swap aus.

Allerdings haben sich auch die Systeme an die neuen Bedingungen angepasst. Vor ein paar Jahren hatte man tatsächlich noch das Problem, das das System geswappt hat, obwohls eigentlich gar nicht nötig gewesen ist. Weils auch sowas wie vorsorgliches swappen gab, um besser einer etwaigen plötzlichen Speicheranforderung gerecht werden zu können.
Man hat inzwischen das Memory-Management überarbeitet und den heutigen Gegebenheiten angepasst und das System neigt heute nicht mehr so zum swappen wie früher.
Das heißt aber auch, das man dem System eigentlich dann ruhig Swap gönnen kann, weil es benutzt ihn nur noch dann, wenn es wirklich angebracht ist.

Man sollte dem System aber dennoch nicht zu viel geben. Falls es doch mal in einer Fehlfunktion in einem Prozess kommt, den Du nicht unter Limits gesetzt hast.
Das wäre sozusagen noch ein guter Grund kein Swap oder wenig Swap zu setzen. Wenn Du aber explizit schreibst
flaphoschi schrieb:
Ich habe auf einem System gar keine Swap. Wenn es eskaliert gibt es CGroups
fällt ja sogar das weg, denn weglassen des Swaps mit einem cgroups-limited-process zu begründet passt dann halt nicht mehr.
 
  • Gefällt mir
Reaktionen: sedot und @mo
andy_m4 schrieb:
Das heißt aber auch, das man dem System eigentlich dann ruhig Swap gönnen kann, weil es benutzt ihn nur noch dann, wenn es wirklich angebracht ist.
Swap ist Bloat 😎

Ich hatte während der Installation letztes(?) Jahr mal testweise diese Option abgewählt, bisher ist mir zumindest noch kein Nachteil in meinen Szenarien aufgefallen. Eine Swapfile nachträglich anzulegen ist ja auch möglich falls es Bedarf geben sollte.
 
  • Gefällt mir
Reaktionen: Marco01_809
SE. schrieb:
:-)
Das man völlig ohne Swap auskommt, stell ich gar nicht in frage.
Ich hab ja auch nur dargelegt, warum es trotzdem nützlich sein kann und warum es kein Nachteil ist welchen zu haben.

SE. schrieb:
Eine Swapfile nachträglich anzulegen ist ja auch möglich falls es Bedarf geben sollte.
Ja.
Gerade weil die Bedeutung von Swap abgenommen hat, macht es sicherlich nicht all zu viel Sinn ne Swap-Partition anzulegen, wie es früher mal üblich war. Eine Swapdatei tut es in vielen Fällen auch.

SE. schrieb:
Ich hatte während der Installation letztes(?) Jahr mal testweise diese Option abgewählt
Bei einer Installation mach ich sowieso immer manuelle Partitionierung. Da muss ich nix explizit abwählen oder so. :-)
 
  • Gefällt mir
Reaktionen: sedot
@andy_m4
Ich wollte dir nicht widersprechen, nur falls es so ankam. War eher ein unqualifizierter Zwischenruf, sozusagen.
Es ist vieles eine Frage von Gewohnheiten oder auch Erfahrungen und so weiter, mit meinem Einstieg „in Linux“ probiere ich gern einfach etwas mehr herum, so eben auch bei swap. Hatte ich glaub ich bei der ersten Installation und jetzt nicht mehr. Stellt sich raus, es gibt keine Notwendigkeit bisher für die Funktion – ganz grob formuliert.

Es überrascht mich jetzt nicht, dass du manuell partitionierst. 😅
Für mich wäre es schon eine Herausforderung snapper erfolgreich mit den btrfs subvolumes (oder andersrum) zu verheiraten. Ich klicke tatsächlich lieber durch ein geführtes Setup an der Stelle und bin ganz froh, dass das Thema elegant wegautomatisiert worden ist.
 
SE. schrieb:
War eher ein unqualifizierter Zwischenruf
Ja. Also alles vollkommen forumsgerecht. :-)

SE. schrieb:
Es überrascht mich jetzt nicht, dass du manuell partitionierst.
In der Regel hab ich ja gar keine Partitionen mehr bzw. besser gesagt nur eine große quasi wo alles rein kommt. Von daher gibts ja da i.d.R.nicht so viel aufwendig zu partitionieren.

SE. schrieb:
Für mich wäre es schon eine Herausforderung snapper erfolgreich mit den btrfs subvolumes
Subvolumes sind aber sowieso auch was Anderes als Partitionen. :-)
Und da kann tatsächlich auch mal Einiges zusammen kommen. Und dann kann man auch gucken, ob man sich das nicht zumindest teilautomatisieren kann.

SE. schrieb:
Ich klicke tatsächlich lieber durch ein geführtes Setup an der Stelle und bin ganz froh, dass das Thema elegant wegautomatisiert worden ist.
Ist auch völlig in Ordnung. Insbesondere dann, wenn es nicht fest vorgeben ist, sondern sozusagen als Vorschlag unterbreitet wird, wo man auch einzelne Dinge dran editieren kann.
 
andy_m4 schrieb:
Subvolumes sind aber sowieso auch was Anderes als Partitionen.
Ja, naja, kommt darauf an auf welche Bezeichnungen du dich beziehst und auf welchen Sprachgebrauch wir uns einigen. Volume ist für mich synonym mit dem Begriff Partition, Subvolume ist eine untergeordnete Partition auf dem selben Datenträger.
Anekdotischer Ausflug. Je nach Anwendung reicht die Darstellung (und/oder Namensgebung) von Subvolume bis hin zu Folder oder Drive. So ganz eindeutig und kohärent ist es (leider) nicht. Die Gemeinsamkeit ist überwiegend, aber nicht immer, die Zuordnung zu einer Disc. Also sda1, sda2, etc. – sdb, sdc, usw. hab ich auch schon gesehen, ist dann verwirrend wenn die Bezeichnungen die Anzahl der tatsächlich verbauten Laufwerke (sehr weit) übersteigt. Vielleicht hänge ich hier aber auch in meiner antrainierten Erwartungshaltung fest.

andy_m4 schrieb:
Insbesondere dann, wenn es nicht fest vorgeben ist, sondern sozusagen als Vorschlag unterbreitet wird, wo man auch einzelne Dinge dran editieren kann.
Ja so ist es (beim openSUSE TW Yast Installer) gelöst, es gibt drei Optionen. Die Vorgabe übernehmen (Btrfs inklusive Swap), die Vorgabe anpassen (Btrfs bei mir ohne swap dann) oder selbst einrichten.
Der andere mit Mouse bedienbare Installer Calamares (*buntu plus Derivate, Fedora, etc.) ist imo weniger umfangreich. Arch hab ich mir noch nicht angeschaut, Archcraft hingegen schon vor längerer Zeit, es gab jedoch kein Btrfs zu diesem Zeitpunkt.
 
SE. schrieb:
Der andere mit Mouse bedienbare Installer Calamares (*buntu plus Derivate......
Von den offiziellen *buntus benutzt nur Lubuntu Calamares, alle anderen Ubiquity. Leider!
 
  • Gefällt mir
Reaktionen: sedot
Apropos Ubiquity und Swap: Wenn man bei der Installation in Ubiquity eine btrfs-Partition wählt, legt Ubiquity ein Swapfile an, das nicht genutzt werden kann, weil Swapfiles in cow-Dateisystemen nicht eingebunden werden. Dafür bräuchte es ein eigenes Subvolume. :freak:
 
@SE.

Unity ist noch recht neu als offizielles Derivat, von daher gut möglich, dass sich die Community da anders entschieden hat aber Kubuntu nutzt definitv Ubiquity. Neon ist halt Drittverwerter, weiß aber nicht was die verwenden. Ich glaube Mint nimmt aber auch Ubiquity.
Ergänzung ()

Garmor schrieb:
Apropos Ubiquity und Swap: Wenn man bei der Installation in Ubiquity eine btrfs-Partition wählt, legt Ubiquity ein Swapfile an, das nicht genutzt werden kann, weil Swapfiles in cow-Dateisystemen nicht eingebunden werden. Dafür bräuchte es ein eigenes Subvolume. :freak:
Ist halt nicht der einzige Bock von Ubiquity aber was willste machen...!?
 
  • Gefällt mir
Reaktionen: sedot
SE. schrieb:
Volume ist für mich synonym mit dem Begriff Partition, Subvolume ist eine untergeordnete Partition auf dem selben Datenträger.
Ja. Klar. Die Begriffe sind in der "Umgangssprache" nicht immer ganz eindeutig und deshalb sollte man das richtigerweise präzisieren.

Die Unterscheidung zwischen Partition und Subvolume könnte man auch anders angehen. Eine Partition ist ein relativ starrer Bereich auf einem Laufwerk. Was z.B. Btrfs unter Subvolume versteht, ist eher etwas Abstraktes. Das hat zwar die Charakteristika der Partition im Sinne von "abgetrennter Bereich". Aber wie groß der ist und auf welchen Laufwerken der liegt (kann sich theoretisch ja auch über mehrere Laufwerke erstrecken) ist erst mal gar nicht so fest definiert.
Und ja. Volume könnte man als obergeordneten (und neutralen) Begriff sehen. Das kann dann letztlich "alles" sein. Auch sowas wie ne Datei oder was auch immer.


Garmor schrieb:
legt Ubiquity ein Swapfile an, das nicht genutzt werden kann, weil Swapfiles in cow-Dateisystemen nicht eingebunden werden.
Das die übrigens nicht eingebunden werden ist keine bloße Schikane oder so, sondern darin begründet, wie Linux mit Swap umgeht. Aus Optimierungsgründen greift das nämlich auf die Swapdatei nicht mit den üblichen Dateioperationen zu, sondern mehr oder weniger direkt on disk.
Das heißt, man greift quasi an der Struktur vorbei auf die Daten im Swapfile zu. Das ist natürlich schwierig bei einem Dateisystem, wo die Zuordnung zwischen Datenbereich und tatsächlichen Datenbereich nicht mehr 1:1 ist.

Apropos Swap. Mir ist noch ein Grund eingefallen, warum man Swap - trotz viel RAM - haben wollen könnte. Nämlich wenn man suspend-to-disk macht. Der RAM wird nämlich dann im Swapspace gespeichert.
 
  • Gefällt mir
Reaktionen: @mo und sedot
andy_m4 schrieb:
Ja, guter Punkt, allerdings gibt es wohl auch die Option zram bzw. zswap zu verwenden wie ich gerade laß. So wie ich es verstehe werden, falls systemd service, quasi on-demand „Auslagerungsdateien“ angelegt bzw. verworfen. Klingt ganz interessant, hier werde ich mich mal belesen bzw. besser testen wie das dann praktisch funktioniert. Swap ohne file oder volume wäre tatsächlich ganz spannend.
https://github.com/systemd/zram-generator
 
SE. schrieb:
Ja, guter Punkt, allerdings gibt es wohl auch die Option zram bzw. zswap zu verwenden wie ich gerade laß.
Das Ding bei Suspend-to-disk ist ja, das der Rechner ausgeschaltet wird. Das was an Status im RAM usw. da ist, muss ja irgendwo hin in einen nichtflüchtigen Speicher gespeichert werden. An dieser simplen Tatsache kommt keine Technik - wie sie auch immer heißen mag - vorbei.

Jetzt kann man natürlich sagen: Wo das gespeichert wird, ist ja letztlich egal. Es muss nicht der Swap-Space sein. Das kann auch einfach eine Datei sein, ein Netzlaufwerk oder von mir aus kannst Du das auch auf CD brennen.

Swapspace zu nehmen bietet sich da aber einfach an. Weil das ja eh schon von der Struktur und Implementation ja genau dafür gedacht ist RAM-Inhalt zu lagern und zu verwalten. Was liegt also näher es dann auch zur RAM-Zwischenspeicherung bei suspend-to-disk zu nutzen? Es funktioniert zudem recht unabhängig von allem anderen. Ich brauche beim Bootup nicht erst irgendwie ein komplizierten Dateisystemtreiber damit ich den RAM-Zustand aus irgendeiner Datei ziehe. Weil Swap hat ein uniformes Design und ist auf einem festen Punkt verankert.

Wenn ich mir jetzt also irgendwie was bastel um von dem (vermeintlich blöden) Swapspache unabhängig zu werden, dann machts die Sache komplizierter.

Was ZRAM und ZSWAP angeht: die kümmern sich gar nicht um den Persistenz-Aspekt. Da gehts gar nicht darum: Speichere ich RAM in anderen Bereich außer dem Swapspace.
Da gehts um Datenkompression. Idealerweise so, das ich weniger oder bestensfalls gar kein Swapspace mehr brauche. Das kann hilfreich im Betrieb sein, weil der RAM-Bedarf (und damit auch der Bedarf nach Swap) reduziert wird. Nützt mir aber nix, wenn ich den kompletten RAM rausschreiben muss. Nützt mir vielleicht in dem Sinne, das ich weniger schreiben muss. Aber irgendwas muss ich schreiben. Und damit brauch ich auch wieder Swapspace.
 
Zuletzt bearbeitet:
andy_m4 schrieb:
Das Ding bei Suspend-to-disk ist ja, das der Rechner ausgeschaltet wird.
Ja, dann ist selbstverständlich ein persistentes swap sinnvoll.

Mit zswap war ich auf dem Holzweg wie mir inzwischen klar geworden ist nachdem ich etwas quergelesen habe.
 
Zurück
Oben