Verwerfen von Hintergrundinformationen auf Swap-Partitionen unter Linux + SSD

Problem

Ich möchte Hintergrund- TRIM-Operationen auf einer Swap-Partition auf einer SSD-Festplatte unter Linux aktivieren . Gemäß mehreren Artikeln, z. B. diesem , erkennt der Kernel diese Konfiguration und führt automatisch Verwerfungsvorgänge durch. Bei meinen Tests scheint dies jedoch nicht zu funktionieren, obwohl die Mount-Option "Verwerfen" verwendet wird, um dieses Verhalten zu erzwingen.

Szenario

• Debian Wheezy unter Linux 3.2.0
• SSD-Festplatte: 1 x 120 GB OCZ Vertex 3 MI
• 2 GB Swap-Partition ohne andere Schichten (LVM, RAID usw.)

Hintergrund

Dies sind die Schritte, die ich befolge, um zu überprüfen, ob Hintergrund-TRIM auf der Swap-Partition funktioniert:

1. TRIM-Unterstützung : Überprüfen Sie, ob die SSD-Festplatte TRIM-Befehle unterstützt und der Kernel das Gerät als nicht rotierend kennzeichnet:

   # hdparm -I /dev/sda | grep TRIM
    * Data Set Management TRIM supported (limit 1 block)
    * Deterministic read data after TRIM
   
   # cat /sys/block/sda/queue/rotational
   0
   

2. Swap-Fill-Up : Mounten Sie die Partition, bereinigen Sie alle VM-Caches und konfigurieren Sie Linux so, dass Swap aggressiv vm.swappiness auf 100 gesetzt wird. Führen Sie dann ein Skript aus, das den gesamten verfügbaren Speicher zuweist und den Kernel zum Swapping zwingt:

   # swapon [--discard] /dev/sda2
   # echo 3 > /proc/sys/vm/drop_caches
   # echo 100 > /proc/sys/vm/swappiness
   # ./fill-up-memory.up
   

   Das Skript führt einen On-Server mit 32 GB physischem Speicher + 2 GB Swap-Partition aus und erstellt ein ~ 33,8 GB großes Objekt im Speicher. Dies reicht aus, um den gesamten Speicher zu füllen und mit dem Swap zu beginnen. Dies ist ein Beispiel für ein Skript, das dieses Verhalten erreicht:

   #!/usr/bin/python
   
   mem = 33.8
   testing = 'A' * int(1024 * 1024 * 1024 * mem)
   raw_input()
   

3. Überprüfen Sie den Swap-Inhalt : "swapon -s" zeigt an, dass 100% des Swap-Speichers verwendet werden. Mit "hdparm --read -ector" überprüfe ich den Rohinhalt der Swap-Partitionssektoren und alle Bytes werden auf "4141" gesetzt, die entsprechende hexadezimale Notation für das "A" -Zeichen. Alles funktioniert wie erwartet. Dies ist ein Beispielskript zum sektorweisen Lesen des Inhalts der Swap-Partition:

   #!/bin/bash
   
   for sector in `seq 194560 4100095` ; do
       hdparm --read-sector $sector /dev/sda
   done
   

HINWEIS: Sie können den Start- / Endsektor der Swap-Partition mit parted, cfdisk usw. abrufen.

Wenn ich das Skript stoppe, gibt es den gesamten Speicher einschließlich der Swap-Zuordnungen frei. "Swapon -s" gibt keine Swap-Verwendung im System zurück. Zu diesem Zeitpunkt wird erwartet, dass Linux den Inhalt der Swap-Partition im Hintergrund verwirft, aber es funktioniert nicht . Der Inhalt der Sektoren ist auch einige Stunden später noch "4141".

Ich habe mehrere Tests durchgeführt und es scheint, dass Linux nur dann eine vollständige Verwerfung durchführt, wenn die Partition mithilfe eines swapon()Systemaufrufs aktiviert wird, jedoch niemals im Hintergrund, obwohl die Mount-Optionen "Verwerfen" in / etc / fstab aktiviert sind.

Weitere Forschung: blkdev_issue_discard () ist die Kernelfunktion, die für das Senden von TRIM-Befehlen an zugrunde liegende SSD-Geräte zuständig ist. Es gibt zwei eindeutige Verweise auf diese Funktion mm/swapfile.c:

• discard_swap() Es wird während des swapon () -Prozesses aufgerufen. Wenn die Mount-Option "Verwerfen" aktiviert ist, werden alle Inhalte verworfen. Dies funktioniert wie erwartet.
• discard_swap_cluster() Es sollte den Inhalt eines Cluster-Swaps verwerfen, scheint jedoch niemals einen TRIM-Befehl auszuführen.

Frage: Wie ist das erwartete Verhalten von Linux auf Swap + SSD-Geräten? Es sollte alle freien Sektoren / Seiten verwerfen oder nur dann eine erste vollständige Verwerfung ausgeben, wenn die Partition während des Startvorgangs aktiviert ist. Vielen Dank.

Es scheint, dass discard_swap_cluster nur von scan_swap_map aufgerufen wird, was wiederum von get_swap_page oder get_swap_page_of_type aufgerufen wird . Wenn ich richtig liege, erfolgt das Verwerfen nur, wenn eine neue Auslagerungsseite zugewiesen wird, nicht, wenn eine Seite freigegeben wird.

Möglicherweise hat Ihr System --discard=oncestandardmäßig. Haben Sie versucht, mit einer bestimmten Entsorgungsoption zu mounten?

# nano /etc/fstab
________________________________________________________________
...
/dev/sda2    none    swap    ..., --discard=pages,...    ...
...

und so zwingen:

# swapon --discard=pages /dev/sda2

Sie können auch versuchen, einen fstrimDienst zu erstellen oder ihn zu konfigurieren, wenn er bereits verfügbar ist.

Wenn ich das Skript stoppe, gibt es den gesamten Speicher einschließlich der Swap-Zuordnungen frei. "Swapon -s" gibt keine Swap-Verwendung im System zurück. Zu diesem Zeitpunkt wird erwartet, dass Linux den Inhalt der Swap-Partition im Hintergrund verwirft, aber es funktioniert nicht . Der Inhalt der Sektoren ist auch einige Stunden später noch "4141".

Der Inhalt des Swaps wird effektiv "verworfen", wenn swapon -s"kein Swap verwendet" zurückgegeben wird. Das System wird den Inhalt der Blöcke (gefüllt mit "4141") nicht überschreiben, da es sich um eine SSD handelt und übermäßige Schreibvorgänge die Lebensdauer des SSD. (Zumindest nehme ich das aus der Dokumentation heraus)