swapfile bauen : auf einem Notebook

[Martin K. (dilbert_man)]

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?

[Stephan S. (uxdx)]

Bei meinem Ubuntu sieht das so aus: in der fstab folgende Zeile

/swapfile   none   swap   sw   0   0

Ansonsten empfehle ich den Artikel https://wiki.ubuntuusers.de/Swap/ -> 
Swap-Datei erstellen, dort wird von fallocate dringend abgeraten.

[Oliver R. (orb)]

Martin K. schrieb:
> Und dass das auch iwie cleverer ist
> als eine swap-partition?

Warum?

[Εrnst B. (ernst)]

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.

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

Εrnst B. schrieb:
> 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.

[Εrnst B. (ernst)]

Dieter D. schrieb:
> 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.

[Norbert (der_norbert)]

Dieter D. schrieb:
> 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)

[Michael L. (nanu)]

Dieter D. schrieb:

> 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.

[Daniel A. (daniel-a)]

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.

[(prx) A. K. (prx)]

Dieter D. schrieb:
> 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.

[C-hater (c-hater)]

(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. 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...

[Rolf M. (rmagnus)]

C-hater schrieb:
> (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.

[Martin K. (dilbert_man)]

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

[Martin K. (dilbert_man)]

ungefähr so eben...

```
[martin@martineos ~]$ sudo fallocate -l 1G /swapfile
[sudo] Passwort für martin:
[martin@martineos ~]$ sudo fallocate -l 2G /swapfile
[martin@martineos ~]$ sudo fallocate -l 2G /swapfile
[sudo] Passwort für martin:
[martin@martineos ~]$ sudo chmod 600 /swapfile
[martin@martineos ~]$ sudo mkswap /swapfile
Auslagerungsbereich Version 1 wird angelegt, Größe = 2 GiB (2147479552 
Bytes)
keine Bezeichnung, UUID=cc08290f-f1e5-4f99-9591-7afcfd04208e
[martin@martineos ~]$ sudo swapon /swapfile
[martin@martineos ~]$
sudo swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file   2G   0B   -2
[martin@martineos ~]$
```

btw. hab nur 1 g genommen da das ein altes ASUS a 54 l ist - mit 4 g ram

 vg