Swap Partition löschen/ SSD langsam

0815burner

Commander
Registriert
Nov. 2006
Beiträge
2.655
Hallo,
mein Xubuntu 23.10 auf einer alten SATA 120GB SSD MX500..
1698669214520.png


..läuft mittlerweile grotten langsam. Als Ursache vermute ich den Schreibspeed der Platte:

1698669283283.png


Die Platte ist aber nicht defekt, unter Windows 10 (wo sie nicht Systemplatte ist) schafft sie folgendes:
1698669728971.png


Nun könnte ich die Swap Partition löschen und der /home (Partition 6) zuschlagen, auf der ich auch den Speedtest mache (4,5GB frei). Swap wird nicht benötigt:
1698669401896.png


Kann ich einfach dieser Anleitung folgen und dann die Swap Partition mit Gparted löschen?

P.S: Eine neue System-SSD für Dualboot mit Win10 ist im Zulauf (WD Black SN770 2TB). Keine Sorge, sie ersetzt nicht diese SATA SSD sondern diese M.2 (2280):
1698669592130.png

Hier wohnt im Moment nur Windows 10.
Das Ganze soll also in erster Linie zu meinem Verständnis und zum Lernen dienen.
Trim habe ich auch schon manuell ausgeführt. Würde gerne verstehen was los ist. Vielleicht liegt es aber auch daran, das seit 16.04 (?) keine Neuinstallation mehr gemacht wurde, immer nur Upgrades.

Abhilfe wird hoffentlich die neue SSD bringen.
Danke schon mal!

Edit: Hier noch Smartwerte:
1698670509737.png
 
Zuletzt bearbeitet:
Glaube nicht, dass das viel bringt. Wenn du sie im laufenden Betrieb löschen willst, solltest du vorher mit sudo swapoff -a die Partition ausbinden und aus der /etc/fstab austragen/auskommentieren.
 
  • Gefällt mir
Reaktionen: 0815burner und _roman_
Die Anleitung ist offenbar für den Fall, dass man mit einer Swapdatei arbeitet. Du hingegen hast aber eine Swap-Partition. Also so handeln, wie von Garmor vorgeschlagen. Danach ist die Partition nicht mehr in Benutzung und deinem System auch nicht mehr bekannt und du kannst mit z.B. Gparted frei darüber verfügen.

Das Verhalten der SSD ist allerdings trotzdem seltsam. Insbesondere, weil ich zuerst auch dachte, dass hier vielleicht lange kein TRIM durchgeführt wurde, was du aber jüngst manuell getan hast. Schneller dürfte das System bzw. die SSD nach löschen der Swap Partition vermutlich nicht sein. Die reinen Schreibwerte des Benchmarks haben ja nichts damit zu tun, ob das System eine Swap Partition besitzt oder nicht.
 
  • Gefällt mir
Reaktionen: 0815burner
Und damm mittels Gparted livecd die Partition vergrößern.

Mir ist es auch aufgefallen bei dem Plattformwechsel Im Jahr 2021. Ich hatte nur 120GB bzw 128GB SATA SSDs verwendet. Die sind extrem langsam im Vergleich zu einer NVME.

Ich habe diverse Fabrikate, auch zwei BX300 von Crucial, Adata ASP550SS, Sanddisk, usw.

--

rückfrage, was steht den in der /etc/fstab für das / ?

Laut meinem Gedächtnisprotokoll sollte man discard und noatime haben bei einer SSD in der fstab bei den mount points. Bitte in der Dokumentation gegenprüfen wegen TRIM / SSD Thematik.

Als Startpunkt, usw ....
https://unix.stackexchange.com/questions/649964/is-mounting-with-discard-needed-for-trim
 
  • Gefällt mir
Reaktionen: 0815burner
Code:
nano /etc/fstab

## Dein Swapeintrag aus der /etc/fstab entfernen
/swapdatei   none    swap    sw    0   0

Also so austragen?

@Grimba Dachte der Speicher wäre villeicht knapp. Keine Ahnung ob da TLC oder was für Speicher in der SSD ist.

@_roman_ Ich hänge die fstab mal an


Code:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda5 during installation
UUID=411dd9b5-da6a-4d64-a73c-8f4ae63ff77b /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=D754-0425  /boot/efi       vfat    umask=0077      0       1
# /home was on /dev/sda6 during installation
UUID=6683357e-6c96-4ab2-839d-629673108f4c /home           ext4    defaults        0       2
# /windows was on /dev/sda8 during installation
#UUID=3404B3EA04B3ACEC  /windows        vfat    utf8,umask=007,gid=46 0       1
#UUID=B258-D71E  /windows        vfat    utf8,umask=007,gid=46 0       1
# swap was on /dev/sda7 during installation
UUID=e736b1b4-1902-48f0-ad99-ded1f74f9b93 none            swap    sw              0       0
/dev/disk/by-uuid/27141B503B8ACCB9 /mnt/27141B503B8ACCB9 auto nosuid,nodev,nofail,x-gvfs-show 0 0

Her noch der Trim Befehl:
1698671201319.png
 
Naja, 4,5GB sind immerhin noch um die 4% freier Speicher auf der SSD. Außerdem (hier kann ich mich irren, im Zweifel bitte korrigieren!), sollte es dem SSD Controller ja egal sein, wo noch physisch freier Speicher auf der SSD ist, um das Flashen von Löschblöcken so gering wie möglich zu halten. Die Partitionen sind da eher virtuell übergeordnet. Das sind ja keine drehenden Platten mit festen Sektoren mehr. Problematisch wäre das wohl eher nur, wenn die gesamte Platte nur noch 4,5GB oder weniger Platz zur Verfügung hätte, obwohl dann auch nicht zwingend. Ich nehme an das ist nicht der Fall.
 
Fazit: Ich sehe eher das Problem - das die fstab nicht richtig erstellt wurde.


In der Zeile 9 steht ja gar nichts bei dir.

So als Beispiel von mir, sind 2 Junk Festplatten, die via lvm2 gespiegelt sind.

Schaust einmal, nach dem Dateisystem EXT4 - stehen noch interessante Dinge wie
defaults, discards, noatime.
Code:
/dev/mapper/harddrives-mirrored        /mnt/mirrored_harddrives        ext4 defaults,discard,noatime                0 0

Da würde ich mir auch einmal GEdanken darüber machen. Bei Fehler ist man nur im Lese Modus. Ob man dasss will ?
errors=remount-ro


Ich verweise mal auf das Gentoo Handbuch

fstab ist allgemeingültig

https://wiki.gentoo.org/wiki/Handbook:Parts/Installation/System/de

  1. Im vierten Feld stehen die Einhänge-Optionen, die von mount genutzt werden, wenn es die Partition eingehängt. Da jedes Dateisystem seine eigenen Optionen hat, empfiehlt sich ein Blick in die Manpage (man mount), wo sich eine vollständige Liste findet. Mehrere Einhänge-Optionen werden mit Kommata getrennt.



https://wiki.gentoo.org/wiki//etc/fstab

Hier steht es auch mit discard

---


Zeile 18 ist der swap -- erkennbar am dateisystemtyp swap

Rauslöschen.
abspeichern.
nochmals öffnen kontrolle.

rebooten mit gparted livecd und die partion vergrößern.

--

Zeile 13 würde ich auch ausbessern für das home Verzeichnis des Benutzers. ist dieselbe Thematik.
 
  • Gefällt mir
Reaktionen: 0815burner
Puh,
da werde ich heute Abend mal eine Stunde investieren müssen. Könnte mir gut vorstellen, dass hier einiges krumm ist. Ist, wie gesagt, seit Jahren, meinem Spiel- und Forscherdrang ausgeliefert..
 
_roman_ schrieb:
Laut meinem Gedächtnisprotokoll sollte man discard und noatime haben bei einer SSD in der fstab bei den mount points.
In meinem Gedächtnisprotokoll führt die discard-Mountoption zu schlechterer Performance. Stattdessen soll man™ regelmäßig (maximal einmal am Tag, üblich ist einmal pro Woche) fstrim auszuführen.

Grimba schrieb:
Naja, 4,5GB sind immerhin noch um die 4% freier Speicher auf der SSD.
Das ist ja nur das getrimmte Volumen seit dem letzten Lauf.

Da die SSD sehr alt ist, könnte es evtl. auch helfen, sie mal komplett plattzumachen (secure erase) und alles neu drauf zu schreiben. Ich habe eine fast acht Jahre alte BX100 500 GB hier, die macht auch jetzt noch ihre über 450 MB/s schreibend.

Was eventuell noch interessant sein könnte ist die korrekte Ausrichtung der Partitionen an Sektorengrenzen. Was sagt denn fdisk -l /dev/sd<Buchstabe> bzgl. der Startsektoren der Partitionen?
 
  • Gefällt mir
Reaktionen: 0815burner und guzzisti
Donnerkind schrieb:
Das ist ja nur das getrimmte Volumen seit dem letzten Lauf.
Das meine ich nicht. Der TE erwähnte im Fließtext, dass 4,5GB auf /home frei seien.
 
  • Gefällt mir
Reaktionen: 0815burner
Donnerkind schrieb:
Was eventuell noch interessant sein könnte ist die korrekte Ausrichtung der Partitionen an Sektorengrenzen. Was sagt denn fdisk -l /dev/sd<Buchstabe> bzgl. der Startsektoren der Partitionen?
Das Alignment habe ich auch schon als potenzielle Ursache ausgeschlossen. Huch, da scheint was nicht zu stimmen!
Edit2: Ich hatte diesen Befehl geprüft:
1698675766748.png


Der zeigte keinen Fehler im Gegensatz zu dem Vorschlag von @Donnerkind

1698675286305.png

Ich dachte es reicht wenn die Anfangsadresse durch 2048 teilbar ist?
Bekommt man das ohne Datenverlust ausgerichtet?

Donnerkind schrieb:
Da die SSD sehr alt ist, könnte es evtl. auch helfen, sie mal komplett plattzumachen (secure erase) und alles neu drauf zu schreiben. Ich habe eine fast acht Jahre alte BX100 500 GB hier, die macht auch jetzt noch ihre über 450 MB/s schreibend.
Ist erst mal nicht geplant. Am Wochenende kommt eine neue SSD und danach sollen die jetzigen Platten die erste Zeit noch als Fallback erhalten bleiben. Ich stimme aber zu, dies könnte hilfreich sein.

Edit: 4,5GB waren vor und nach dem Trim Befehl vorhanden. Da hat sich also nichts im Sichtbaren Bereich verändert.
 
Zuletzt bearbeitet:
Die Linuxe machen seit einiger Zeit schon keine separaten SWAP Partitionen mehr, die machen das über LVM und virtuelle Partitionen. Daher würde ich eher mal ein neues Linux komplett neu installieren.
 
Warum? Nur wegen der Swap Partition? Ohne LVM und Swap Datei hast du jetzt eigentlich keinen gravierenden Nachteil bzw. Grund, das nur deswegen neu zu installieren. Aber das Alignment sollte definitiv gefixt werden.
 
Zuletzt bearbeitet:
Das nicht-Vorhandensein von LVM alleine ist absolut kein Grund ein System zu nuken.
 
Erstmal Dank für die vielen Antworten.

System wird neu aufgesetzt, da sowohl Win 10 als auch Xubuntu unter Platzangst leiden. Eine neue SystemSSD ist unterwegs:
0815burner schrieb:
P.S: Eine neue System-SSD für Dualboot mit Win10 ist im Zulauf (WD Black SN770 2TB). Keine Sorge, sie ersetzt nicht diese SATA SSD sondern diese M.2 (2280):
Dazu noch eine neue SAMSUNG MZ-77Q4T0BW 870 QVO 4TB Sata-Platte als Datengrab. Über die Nachteile bin ich mir bewusst. Augenscheinlich war ich bisher ja auf der Systemplatte auch nicht schneller;-)

Ich denke ich suche mir mal einen Leitfaden, wie und in welcher Reihenfolge ich die NVME installiere. Auch da habe ich wieder genaue Vorstellungen, wie es aussehen soll:
2000GB total:
1. Bootloader (Größe minimal)
2. Win 10 (768GB)
3. Ubuntu / (64GB)
4. Ubuntu /home (128GB) -> eventuell mal ne VM installieren..
5. globales Laufwerk (NTFS) (Rest also ungefähr 1040GB)


Grimba schrieb:
Aber das Alignment sollte definitiv gefixt werden.
Dazu muss ich mich mal belesen. Keine Ahnung, ob und wie das geht. Die Daten will ich aber vorerst nicht verlieren, solange ich nicht sicher bin, das der Umzug komplett gelungen ist.
Wäre natürlich cool wenn es geht und man einen Unterschied feststellen könnte.
Ergänzung ()

nutrix schrieb:
Die Linuxe machen seit einiger Zeit schon keine separaten SWAP Partitionen mehr
Wie gesagt, das Linux hier lebt mindestens seit 16.04. Viel dran gefrickelt. Am Anfang ließ sich die Nvidia nicht abschalten, TLP, etc. Alles probiert, wovon ich keine Ahnung hatte, Wine, VMs, externe Paketquellen, ein paar Upgrades liefen echt semioptimal und habe ich wieder hingepuscht.:p
Dazu Windows ein paar mal neu installiert. Eigentlich kein Wunder das fstab und Alignment kapituliert haben.
Ergänzung ()

Zum Alignment:
Ubuntuuser schreibt dazu, das man das "bedenkenlos" mit gparted machen kann. Ich würde es theoretisch dann so machen:

  1. Live Linux booten, gparted aufrufen
  2. sda 1 um 200MB verkleinern.
  3. sda 2 um die 200MB vergrößern (damit was passiert) und den MiB Haken setzen.
Danach sollte alles gut sein?! Ist jetzt theoretisch, da ich kurz vor der neuen Platte jetzt nicht noch alles abschießen mag.
Das Swap löschen habe ich weg gelassen, da es augenscheinlich nicht mein Problem ist

1698685499438.png
 
Zuletzt bearbeitet:
Grimba schrieb:
Das nicht-Vorhandensein von LVM alleine ist absolut kein Grund ein System zu nuken.
Wenn jemand kundig ist, dann kann man das auch selbstverständlich anders und manuell machen, aber davon kannst Du nicht immer ausgehen.
 
  • Gefällt mir
Reaktionen: 0815burner
Absolut richtige Einschätzung. Auch wenn ich gerne bereit bin was dazuzulernen. Ganz auf verlorenen Posten bin ich auch nicht. Programmiere in der Automatisierungstechnik, verstehe es also auch binär zu denken.

Ich würde es machen wenn es relativ risikolos ist und ich eine brauchbare Anleitung hätte.
Das Interesse ein Vorher/ Nachher zu sehen ist definitiv gegeben. Nur ist Zeit nicht unendlich vorhanden und da das System ersetzt wird, warum dann noch Stunden Schwitzen um das bisher (schlecht) laufende wieder gangbar zu bekommen (nach dem GAU)? Man muss den Spieltrieb irgendwann überwinden.
 
@0815burner denk dran:
0815burner schrieb:
Die Daten will ich aber vorerst nicht verlieren, solange ich nicht sicher bin, das der Umzug komplett gelungen ist.
Also mache bei dem "bedenkenlosen" Vorhaben auf jeden Fall vorher ein Backup. Im Zweifel würde ich die betroffene Partition löschen und neu erstellen. Ist hier aber die Extended, damit fällt das flach. Probiers mit deiner Variante.
 
  • Gefällt mir
Reaktionen: 0815burner
Grimba schrieb:
Aber das Alignment sollte definitiv gefixt werden.
Ich sehe da eigentlich nix, was zu fixen wäre. Sämtliche Partitionen beginnen an einer Megabytegrenze (Startsektor * 512 / 1024^2 ist immer ganzzahlig). Ist die Lesegeschwindigkeit eigentlich auch so niedrig?

Ich schreibe gerade auf einem Surface Go in der SSD-Version, also mit NVMe. Aber auch die ist wahnsinnig lahm, selbst ein kürzliches Plattmachen, Partitionieren mit f2fs und Neubeschreiben hat nur wenig geholfen.

Und jetzt habe ich tatsächlich auch dumm geguckt:
Code:
$ fdisk -l /dev/nvme0n1
Festplatte /dev/nvme0n1: 119,24 GiB, 128035676160 Bytes, 250069680 Sektoren
[…]
Gerät            Anfang      Ende  Sektoren Größe Typ
/dev/nvme0n1p1     2048    534527    532480  260M EFI-System
/dev/nvme0n1p2   534528  59254783  58720256   28G Linux-Dateisystem
/dev/nvme0n1p3 59254784 250068991 190814208   91G Linux Home
$ hdparm -t /dev/nvme0n1

/dev/nvme0n1:
 Timing buffered disk reads: 414 MB in  3.02 seconds = 137.23 MB/sec

$ dd if=/dev/nvme0n1 of=/dev/null bs=1M count=1000
1000+0 Datensätze ein
1000+0 Datensätze aus
1048576000 Bytes (1,0 GB, 1000 MiB) kopiert, 11,6247 s, 90,2 MB/s

$ dd if=/dev/nvme0n1p2 of=/dev/null bs=64k count=50000
50000+0 Datensätze ein
50000+0 Datensätze aus
3276800000 Bytes (3,3 GB, 3,1 GiB) kopiert, 10,6271 s, 308 MB/s

0815burner schrieb:
Die Daten will ich aber vorerst nicht verlieren, solange ich nicht sicher bin, das der Umzug komplett gelungen ist.
Wenn man im Partitionierungsprogramm „Partition löschen“ klickt oder im Menü anwählt, wird sie ja nicht sofort gelöscht, sondern erst wenn man zum Schluss „Jetzt anwenden“ macht. Von daher kann man also in Ruhe herumexperimentieren, solange man nie auf „Anwenden“ geht.😁
 
Zurück
Oben