moin Community
swapfile bauen : auf einem Notebook - wie würdet ihr das machen!?
sudo fallocate -l 2G /swapfile
ich denke dass das so gehen müsste. 'Und dass das auch iwie cleverer ist als eine swap-partition?
Bei meinem Ubuntu sieht das so aus: in der fstab folgende Zeile
1 |
|
Ansonsten empfehle ich den Artikel https://wiki.ubuntuusers.de/Swap/ -> Swap-Datei erstellen, dort wird von fallocate dringend abgeraten.
Hängt vom Dateisystem & Massenspeicher ab.
CoW-Dateisysteme haben keine Freude an Swapfiles, da muss dann (z.B. bei btrfs) ein "NoCoW"-Attribut mit an die Datei. Und das lässt sich nur bei 0-Byte-Dateien setzen. https://btrfs.readthedocs.io/en/latest/Swapfile.html
Und wenn du dein Swap-File "sparse" anlegst, fragmentiert es u.U. stark. Bei SSDs egal, bei HDDs eher nicht.
Meist ist eine Swap-Partition (oder Swap-LV) die einfachere Wahl, da passt es immer.
Meist ist eine Swap-Partition (oder Swap-LV) die einfachere Wahl, da passt es immer.
Das gilt auch für SD-Karten, also Flashspeicher. Wenn die Zellen erschöpft sind, dann fällt erst mal nur diese Partition aus. Das verhindert größere Verluste.
Das gilt auch für SD-Karten, also Flashspeicher.
Würd ich so nicht unterschreiben. Da macht der SSD-Controller (bzw. höherwertige SD-Karten-Controller) nochmal ein re-mapping/wear-leveling, und die ausgenuddelten Blöcke aus der Swap-Partition landen irgendwann auch mal im Datenbereich.
Wenn die Zellen erschöpft sind, dann fällt erst mal nur diese Partition aus.
Das gilt vielleicht für FLASH aus den frühen Siebzigern! (Also 1570, kurz nach der letalen Erwärmung der Kräuterfrauen)
Das gilt auch für SD-Karten, also Flashspeicher. Wenn die Zellen erschöpft sind, dann fällt erst mal nur diese Partition aus. Das verhindert größere Verluste.
Nö, auch SD-Karten machen mindestens dynamisches wear leveling, d.h. am geringsten belastete freie Blöcke werden zuerst beschrieben, egal wo sie liegen.
Bei mir ist das Root ein md raid 1. Würde ich eine 64GiB Swap Datei da drauf packen, würde das auf beiden Drives im Raid 64GiB verschwenden. Stattdessen habe ich auf beiden Platten je eine swap Partition. Gibt gleich doppelt so viel Swap.
Vielleicht wars auch mehr als 64GiB, bin mir gerade nicht sicher. Ist meistens ungenutzt. Ich verwende es hauptsächlich für ein grosses tmpfs, auf dem ich build jobs laufen lasse. Ist auf schnellen NVMe SSDs drauf. Zusammen mit der tonne RAM im Server geht da alles sau schnell.
Das gilt auch für SD-Karten, also Flashspeicher. Wenn die Zellen erschöpft sind, dann fällt erst mal nur diese Partition aus.
Kein analog zu einer Disk genutztes Speichermedium wie SD,USB,SATA,... mit NAND-Flash überschreibt bestehende Blöcke. Das ist technisch schlichtweg nicht möglich. Geschriebene Daten landen deshalb immer an anderer Stelle als vorher. Unabhängig von jedwedem wear leveling.
Da diese Medien ausserdem nichts von Partitionen wissen, betrifft das das ganze Medium, d.h. eine Allokation oder ein Schreibproblem aussschliesslich in einer Partition gibt es nicht.
Kein analog zu einer Disk genutztes Speichermedium wie SD,USB,SATA,... mit NAND-Flash überschreibt bestehende Blöcke. Das ist technisch schlichtweg nicht möglich.
Natürlich ist das irgendwie möglich (und passiert auch) der Trick ist ganz einfach: Page-Daten in Page-Puffer im Flashcontroller laden, Page löschen, Page aus Buffer schreiben. Typisch haben Flashcontroller sogar weitaus mehr RAM als nur für eine Page.
Geschriebene Daten landen deshalb immer an anderer Stelle als vorher. Unabhängig von jedwedem wear leveling.
Definitiv: Nein.
Da diese Medien ausserdem nichts von Partitionen wissen
Auch falsch. Sie kennen oft die vom Hersteller vorgegebene Partitionierung und richten sehr wohl auch oft ihre wear-leveling-Strategie darauf aus. Bei Billich-Scheiß (USB-Sticks und SD) ist das absolut üblich und sehr leicht nachweisbar. Das liegt daran, dass echtes wear-leveling durch die zusätzlichen Schritte schlicht Zeit kostet, sobald es keine ungenutzten Pages mehr gibt.
Man findet sehr leicht heraus, dass wear-leveling hier nur für für die Pages erfolgt, die (in der vorgegebenen Partitionierung) erwartbar hoch beansprucht sind. Für den ganzen Rest, also die übergroße Mehrheit des Datenbereichs, gibt es typisch kein wear-leveling, sondern nur simple Ersetzung aus dem Spare. Bis dieser alle ist. Und gerade bei dem Billich-Scheiß ist er eher klein bis hinab zu: ab Werk überhaupt nicht vorhanden...
(prx) A. K. schrieb:
Kein analog zu einer Disk genutztes Speichermedium wie SD,USB,SATA,... mit NAND-Flash überschreibt bestehende Blöcke. Das ist technisch schlichtweg nicht möglich.
Natürlich ist das irgendwie möglich (und passiert auch) der Trick ist ganz einfach: Page-Daten in Page-Puffer im Flashcontroller laden, Page löschen, Page aus Buffer schreiben.
Das Problem ist, dass die Page-Größe für alle drei Operationen (laden, löschen und schreiben) unterschiedlich ist. Insbesondere für das Löschen ist sie üblicherweise besonders groß. Deshalb - und weil allgemein das Löschen als zusätzliche Operation auch zusätzlich Zeit braucht, ist die von dir beschriebene Art, das zu tun, sehr ineffizient und daher langsam. Deshalb wird der Controller es möglichst vermeiden und beim "Überschreiben" die Daten lieber auf andere, bereits leere Sektoren verlagern. So kann die Löschoperation auch später durchgeführt werden, wenn gerade keine Daten gelesen oder geschrieben werden müssen.
Geschriebene Daten landen deshalb immer an anderer Stelle als vorher. Unabhängig von jedwedem wear leveling.
Definitiv: Nein.
Woher hast du diese Information? Hast du bei SD-Karten, USB-Sticks oder SSDs schon mal geprüft, wo die Daten nach wiederholtem Schreiben jeweils landen? Oder entwickelst du solche Speichermedien?
Da diese Medien ausserdem nichts von Partitionen wissen
Auch falsch. Sie kennen oft die vom Hersteller vorgegebene Partitionierung und richten sehr wohl auch oft ihre wear-leveling-Strategie darauf aus. Bei Billich-Scheiß (USB-Sticks und SD) ist das absolut üblich und sehr leicht nachweisbar. Das liegt daran, dass echtes wear-leveling durch die zusätzlichen Schritte schlicht Zeit kostet, sobald es keine ungenutzten Pages mehr gibt.
Es liegt vor allem auch daran, dass für SD-Karten Dateisysteme als Standard vorgegeben (und bei USB-Sticks üblich) sind, die eigentlich nicht für Flash-Speicher geeignet sind. Deshalb berücksichtigen die Controller das speziell, damit bestimmte für die Integrität des Dateisystems benötigte Sektoren nicht besonders schnell runtergeritten werden. Mit Partitionen an sich hat das eher indirekt zu tun, schon alleine, weil SD-Karten und USB-Sticks in der Regel gar nicht mit mehreren Partitionen ausgeliefert werden. Und wenn man sie selbst umpartitioniert, bekommt der Controller das nicht mit, weiß also nichts darüber, wo welche Partition liegt. Bei SSDs dagegen gibt es keine Bindung an eine bestimmte Partitionierung, und daher werden da die Sektoren auch über Partitionsgrenzen umsortiert, ohne dass die SSD das merkt, da sie ebenfalls nicht mitbekommt, wo welche Partition liegt.
hallo und guten Abend
vielen dank für eure Tipps und Erwägungen.
also wenn ich das so einrichte:
sudo fallocate -l 2G /swapfile
dann kann ich die Einrichtung auch testen - danach eben.
also nach dem Einrichten eines swapfile auf dem notebook mit sudo fallocate -l 2G /swapfile
gehts weiter mit dem Enablen des swapfile:
sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile
dann kann ich das verifizieren: also gucken ob das swapfile aktiv ist
sudo swapon --show
es sollten dann die informationen kommen zum swapfile, inklusive size und usage.
Den Überblick - m.a.W. also eine Art Monitor gibts mit
watch -n 1 swapon -s
das refreshed den output alle Sekunden und zeigt den aktuellen Swap-Einsatz
ungefähr so eben...
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
14 |
|
15 |
|
btw. hab nur 1 g genommen da das ein altes ASUS a 54 l ist - mit 4 g ram
vg
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.