Swap File auf SSD richtig erstellen inkl. Trim?

  • Ersteller Ersteller computerfrust
  • Erstellt am Erstellt am
HominiLupus schrieb:
Dann wurdest du pingelig und hast Dinge geschrieben die falsch sind wie "Der Partitionstyp ist SWAP und es wird unter /swap gemountet."

Falsch? Wohl eher richtig! http://80686.net/downloads/04-05-19-aufbau-einer-festplatte.pdf Nach dem physischen Part folgt der erste "logische" und das ist die Partition mit MBR, Bootsektor, Dateisystem.

Und Swap ist ein Dateisystem. ... https://wiki.ubuntuusers.de/Dateisystem/

Zitat:

Besonderheit /swap:
Obwohl die Swap-Partition kein Dateisystem im eigentlichen Sinne enthält, ist auch hier ein Formatieren notwendig. Wird bei der Installation von Ubuntu eine Swap-Partition erstellt, so wird die Formatierung automatisch durchgeführt. Siehe auch: Swap


zwar keines im üblichen, im eigentlichen Sinne (man kann nicht wie auf ext3 oder so zugreifen) ... aber es ist dennoch ein Dateisystem
 
Zuletzt bearbeitet:
HominiLupus schrieb:
Swap ist kein Dateisystem und auch nicht zwingend eine Partition. mkswap Manpage: "After creating the swap area," im Gegensatz zu mkfs.ext4: mke2fs will create the file system
/swap ist schlicht nicht existent, und in der swap area sind keine Dateien drin. FHS kennt kein /swap, fstab hat kein /swap. Es existiert nicht! Wenn jemand von /foo schreibt dann erwartet man das es existiert, "Everything is a file", insbesondere wenn es mit / anfängt. Ausser es ist eben keins wie /swap.

ahja, der profi. wenn es ja kein mkfs für swap gibt dann nutze doch einfach
mkswap /dev/hda1
und
swapon /dev/hda1
damit Linux auch weis, wo es liegt.
 
Man kann natürlich auch unter Linux, wenn man es denn möchte, eine Containerdatei für swap erstellen. Es muß nicht zwingend eine eigene Partition sein. Das dann darunterliegende Dateisystem kann auch discard/fstrim unterstützen und ausführen, ist alles möglich. Allerdings gilt für die Containerdatei, iirc: sie muß der Größe entsprechen, die für swap zugedacht ist. Dynamische allozierung ist iirc nicht.

Ob swap nun eine Datei ist oder ein Dateisystem wie z.B. ext4... Spielt das wirklich für den einfachen Anwender eine so große Rolle?
 
Man kann eine Swap-Partition nutzen. Oder eine Datei. Die Aussage, dass Swap zwingend auf einer eigenen Partition liegt, ist falsch.

Einen praktischen Unterschied macht es für den unbedarften Anwender nicht.

Ich nutze eine Datei. Die lässt sich ggf. leicht in der Größe anpassen oder verschieben.
 
Problem an der Swap Datei ist das der Hybernate nicht funktioniert. Ja Discard funktioniert zuverlässig ab 4.8.
 
computerfrust schrieb:
statt einer Swap-Partition ein Swap-File erstellen, weil ich mal gehört habe, dass dies für eine SSD sinnvoller sei.
Sinnvoller wofür?
Swap in ein File statt auf eine Partition heißt: Der Kernel kann beim Swappen nicht mehr direkt auf einem bequem zusammenhängenden Bereich eines simplen Blockdevices arbeiten sondern muss sich erstmal durch Filesystemcode wühlen, bevor die Daten letztendlich in viel komplizierterer Struktur doch irgendwann auf dem gleichen Blockdevice landen. Ein Swapfile ist die Von-hinten-durch-die-Brust-ins-Auge-Alternative zur Swap-Partition, die man wählt, wenn man mal ausnahmsweise kurz viel mehr Swap brauch als im Normalbetrieb.

HominiLupus schrieb:
Linux ist es schon mindestens 20 Jahre egal ob diese Datei dann eine Datei, eine Partition oder ne ganze Platte ist.
Aus Sicht der Speicherverwaltung ist es egal oder sagen wir mal transparent. Wenn der swap wirklich verwendet wird, ist der Mehraufwand eines Files ggü. einer Partition oder eines rohen Blockgeräts nach wie vor vorhanden. Den kann man nicht wegzaubern.

HominiLupus schrieb:
swap ... kein Dateisystem ... hat kein Trims. swap ... immer "voll". Da wird nie was gelöscht sondern immer nur überschrieben.
Nönö. Die Swapartition (oder ein File) auf der Platte wird zwar beim Freigeben von Bereichen tatsächlich nicht geleert/überschrieben, aber der Kernel erzeugt für nicht mehr genutzen swap-Bereiche sehr wohl discard(aka Trim)-Befehle an die SSD, wie er es auch bei freigegebenen Blöcken "normaler" Filesysteme ala extX tun kann, die ebenfalls nicht überschrieben werden, wenn sie von "genutzt" in "ungenutzt" übergehen.


Für die Praxis ist sicher nützlich, dass man nicht _sinnlos_ auf einer SSD rumswappt - ihrer Lebenszeit wegen meine ich. Ich vermute, dass es dem Threaderöffner um die Lebenszeit der SSD ginbg. Da helfen mehr RAM, ein Verringern von vm.swappiness(!!!1) und evtl. ein Gedanke an die tmpfsse (<-- Mehrzahl von tmpfs ^^). Wenn man aber regelmäßig swap wirklich benötigt und nutzt, spricht mMn nach nichts mehr für ein File als für eine Partition.
 
Da sollte man vielleicht noch anmerken, dass man eine Mittelklasse SSD auch mit etwas gehobenem Anforderungsprofil auf absehbare Zeit nicht totschreibt weil darauf ausgelagert wird. Zumindest solang eine halbwegs vernünftige Menge an Ram zur Verfügung steht werden eher Nutzeraktionen und Programme innerhalb ihrer Funktionalität eine weit größere Schreiblast provozieren als die meisten Distributionen mit ihre Standardeinstellung der swapiness.
 
mensch183 schrieb:
Sinnvoller wofür?
Swap in ein File statt auf eine Partition heißt: Der Kernel kann beim Swappen nicht mehr direkt auf einem bequem zusammenhängenden Bereich eines simplen Blockdevices arbeiten sondern muss sich erstmal durch Filesystemcode wühlen, bevor die Daten letztendlich in viel komplizierterer Struktur doch irgendwann auf dem gleichen Blockdevice landen.
Das ist gefühlt schon ewig nicht mehr so.
Sobald die Swap-Datei aktiviert wird, gibts eine "Map" der belegten Blöcke. Der Kernel kann also direkt drauf zugreifen ohne den Umweg über den Dateisystemtreiber zu gehen.

Dadurch landet zum Beispiel auch nix im Disk-Cache, was ja bei Swap kontraproduktiv wäre.

Wenn man Fragmentierung der Swap-Datei vermeiden möchte, sollte man die Datei optimalerweise recht früh nach erstellen des Dateisystem anlegen. Wobei bei SSD Fragmentierung ja praktisch gar nicht mehr zu Performanceseinbrüchen führt und es da so ziemlich egal ist.

Siehe dazu auch den Linux-Kernel Source-Datei: ./mm/swapfile.c
SYSCALL swapon ist ein guter Startpunkt für eigene Recherchen.

G8
A.
 
computerfrust schrieb:
Ich möchte auf meiner SSD statt einer Swap-Partition ein Swap-File erstellen, weil ich mal gehört habe, dass dies für eine SSD sinnvoller sei.

Ich bin der Anleitung "manually" im Arch Wiki gefolgt: https://wiki.archlinux.org/index.php/swap#Swap_file_creation
Beim Eintrag in der /etc/fstab frage ich mich nun, ob ich noch die Option "discard" hinzufügen muss, wie bereits bei der SSD-Partition geschehen, oder ob das Probleme verursachen würde bzw. aus bestimmten Gründen überflüssig wäre.

Code:
/dev/sda1 / ext4 rw,relatime,data=ordered,discard 0 1
/swapfile none swap defaults 0 0

Auch wenn der Thread etwas älter ist , mittlerweile muss man trim nicht mehr ausführen und ist auch auf einer SSD nicht mehr Nötig.
Mittlerweile werden die entsprechenden verwaltungen von Linux dank entsprechender Treiber im Kernel korrekt unterstützt.
Ich selbst haben och eine alte SSD mit 120 GB im PC die mittlerweile 4 Jahre alt ist.
Es ist eine OCZ Vertex 3.
Auf Ihre sind bei mir 32 GB als Swap angelegt wobei ich dies bei 64 GB Speicher (DDR 3 PC 2133 CL9) eigentlich nicht mehr brauche.
Und wenn man unbedingt trim ausführen will kann man zur Not sich auch noch ein kleines Script schreiben und das in Cron oder als Cron Job entsprechend Anbinden.
So muss man es nicht jedesmal Manuell ausführen.
 
fax668 schrieb:
Du redest vermutlich von Garbage Collection? Das haben zwar viele SSDs, aber optimal ist weiterhin die Benutzung von Trim: https://de.wikipedia.org/wiki/Solid..._Verwendung_.28TRIM_und_Garbage_Collection.29. Dass man besser periodisch fstrim macht statt discard, hatte ich ja schon geschrieben: https://www.computerbase.de/forum/t...ig-erstellen-inkl-trim.1655772/#post-19731047.

Man sieht auch das dein Posting von jemanden verfasst wurde der keine Ahnung hat.

Meine erste SSD ist mittlerweile 6 Jahre alt und auf dieser wurde noch NIE Trim ausgeführt.
Sie wurde zu Zeiten genutzt als man noch (weil viele Nutzer angeblich Angst um Ihre Daten hatten) Trim manuell ausführen musste.
Selbst heute noch funktioniert Sie ohne Datenverlust oder Performance Einbußen einwandfrei.
Viele vergessen einfach das mittlerweile die Controller in der SSD so ausgereift sind ,das man Trim nicht mehr ausführen muss. Aber es hält sich hartnäckig das Gerücht es sei nötig, was auch in einigen anderen Bereichen ( Tante google lässt grüßen) bereits Bestätigt wurde ,das trim nicht notwendig ist.

Lediglich bei den SSD der allerersten Generation (also Modelle vor meiner ersten) da sollte man überlegen Trim anzuwenden ,da diese Controller geeignete Methoden zur korrekten Speichernutzung nicht hatten.
Und es auch hier vorkommen kann das fehlerhafte Speicherzellen auftreten können.

Im Geschäft läuft ein Testserver seit 4 Jahren der 5 SSD mit je 1 TB auf Raid 5 nutzt.
Auch hier haben wir keine Probleme damit alle Daten sind da ,trim wurde noch nie auf den SSD angewendet.
 
Silberfan schrieb:
Viele vergessen einfach das mittlerweile die Controller in der SSD so ausgereift sind ,das man Trim nicht mehr ausführen muss.
Dann verrate uns doch mal, woher der Controller weiß, welche Blöcke frei sind und deshalb wieder zum erneuten Beschreiben vorbereitet werden dürfen?

Klar könnte man theoretisch eine Lösung basteln, wo der Controller das Dateisystem auswertet und anhand dessen weiß, welche Blöcke er gefahrlos löschen kann.
Aber daran glaube ich nicht, weil man dann ja zig Dateisysteme berücksichtigen müsste (sdie sich ja auch in Zukunft noch ändern können).

Silberfan schrieb:
Meine erste SSD ist mittlerweile 6 Jahre alt und auf dieser wurde noch NIE Trim ausgeführt.
Vielleicht, weil inzwischen die Betriebssysteme SSDs erkennen und daher den entsprechenden Dateisystemtreiber in einem solchen Fall anweisen, TRIM zu benutzen.

Silberfan schrieb:
Sie wurde zu Zeiten genutzt als man noch (weil viele Nutzer angeblich Angst um Ihre Daten hatten) Trim manuell ausführen musste.
Ich vermute, TRIM wurde früher deshalb manuell ausgeführt, weil in den Dateisystemtreibern etc. noch gar keine Unterstützung für TRIM da war.
Man muss hier auch wohl unterscheiden zwischen GarbageCollection und TRIM.

TRIM macht so erst mal gar nichts, als ein Block als löschbar zu markieren.
Die Garbage Collection kümmert sich darum die gekennzeichneten Blöcke dann tatsächlich zu löschen, damit sie wieder neu beschrieben werden können. Und natürlich aus Geschwindigkeitsgründen möglichst zu Zeiten, in dem die SSD nicht anderweitig durch Lese-/Schreibzugriffe belastet ist.
 
Zuletzt bearbeitet:
Silberfan schrieb:
Man sieht auch das dein Posting von jemanden verfasst wurde der keine Ahnung hat.

Meine erste SSD ist mittlerweile 6 Jahre alt und auf dieser wurde noch NIE Trim ausgeführt.
Junge, als ich vor neun Jahren meine erste SSD in San Francisco gekauft habe, konnte weder die SSD noch Linux Trim. Weder manuell noch sonst wie. Die SSD steckt heute noch als Bootlaufwerk in meinem HTPC. Lies und verstehe erst mal die Links weiter oben.
 
andy_m4 schrieb:
Dann verrate uns doch mal, woher der Controller weiß, welche Blöcke frei sind und deshalb wieder zum erneuten Beschreiben vorbereitet werden dürfen?

Vom Directory?! In dem stehen schließlich die belegten Blöcke drin. Zumindest funktioniert so jede HDD.
 
Etwaige Informationen welche Blöcke belegt sind, sind auf Dateisystemebene und man will eben nicht, dass ein Laufwerk auf ebene des Dateisystems irgendetwas macht. Ganz abgesehen davon, dass ein entsprechendes Laufwerk die verschiedenen Dateisysteme über div. Versionen verstehen können müsste.

Wobei hier im Thread geht es um Swap und da wären mir iNodes wirklich ganz was Neues :)
 
Zurück
Oben