Suppression en arrière-plan des partitions d'échange sur Linux + SSD

11

Problème

Je souhaite activer les opérations TRIM en arrière-plan sur une partition de swap dans un disque SSD sous Linux. Selon plusieurs articles, par exemple celui-ci , le noyau détecte cette configuration et effectue automatiquement les opérations de suppression, mais mes tests semblent ne pas fonctionner bien que l'option de montage «discard» soit utilisée pour forcer ce comportement.

Scénario

  • Debian Wheezy exécutant Linux 3.2.0
  • Disque SSD: 1 x 120 Go OCZ Vertex 3 MI
  • 2 Go de partition «plate» d'échange, sans autres couches (LVM, RAID, etc.)

Contexte

Voici les étapes que je suis pour vérifier si TRIM en arrière-plan fonctionne sur la partition de swap:

  1. Prise en charge de TRIM : vérifiez si le disque SSD prend en charge les commandes TRIM et si le noyau marque le périphérique comme non rotatif:

    # 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. Remplissage d'échange : montez la partition, nettoyez tous les caches de VM et configurez Linux pour permuter de manière agressive en définissant vm.swappiness à 100. Ensuite, exécutez un script qui alloue toute la mémoire disponible et force le noyau à commencer à échanger:

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

    Le script exécute un serveur avec 32 Go de mémoire physique + une partition de swap de 2 Go et crée un objet de ~ 33,8 Go en mémoire, ce qui est suffisant pour remplir toute la mémoire et commencer à échanger. Voici un exemple de script qui réalise ce comportement:

    #!/usr/bin/python
    
    mem = 33.8
    testing = 'A' * int(1024 * 1024 * 1024 * mem)
    raw_input()
    
  3. Vérifiez le contenu du swap : «swapon -s» indique que 100% de la mémoire de swap est utilisée. En utilisant «hdparm --read-sector», je vérifie le contenu brut des secteurs de partition de swap et tous les octets sont définis sur «4141», la notation hexadécimale correspondante pour le caractère «A», tout fonctionne comme prévu. Voici un exemple de script pour lire secteur par secteur le contenu de la partition de swap:

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

REMARQUE: vous pouvez obtenir le secteur de début / fin de la partition de swap en utilisant parted, cfdisk, etc.

Lorsque j'arrête le script, il libère toute la mémoire, y compris les allocations de swap, «swapon -s» ne renvoie aucune utilisation de swap dans le système. À ce stade, il est prévu que Linux commence à supprimer le contenu de la partition de swap en arrière-plan, mais cela ne fonctionne pas , le contenu des secteurs est toujours «4141», même plusieurs heures plus tard.

J'ai fait plusieurs tests et il semble que Linux n'effectue un rejet complet que lorsque la partition est activée à l'aide d' swapon()un appel système, mais jamais en arrière-plan, bien que les options de montage «discard» soient activées sur / etc / fstab.

Recherches complémentaires: blkdev_issue_discard () est la fonction du noyau chargée d'envoyer des commandes TRIM aux périphériques SSD sous-jacents, il existe deux références uniques à cette fonction sur mm/swapfile.c:

  • discard_swap() il est appelé pendant le processus swapon (), si l'option de montage «discard» est activée, elle rejette tout le contenu, cela fonctionne comme prévu.
  • discard_swap_cluster() il doit supprimer le contenu d'un échange de cluster, mais semble ne jamais exécuter de commande TRIM.

Question: quel est le comportement attendu de Linux sur les périphériques swap + SSD? Il doit supprimer tous les secteurs / pages libres ou uniquement émettre un rejet complet initial lorsque la partition est activée pendant le processus de démarrage? Merci.

santisaez
la source
4
À quoi ça sert? La RAM est bon marché, comme vous le prouvez adéquatement en ayant 32 gros dans votre serveur. Désactivez Swap, utilisez votre SSD pour quelque chose d'utile et arrêtez le bitfricking.
Tom O'Connor
3
Le swap ne peut pas être désactivé sur ces serveurs et ils ont un disque SSD unique, il n'y a pas d'option pour héberger la partition de swap sur un disque dur traditionnel. Je suis conscient que mettre swap sur un disque SSD n'est pas la meilleure option, mais je me demandais si je pouvais obtenir le même comportement extard "discard" sur les partitions swap, pour améliorer les performances du disque autant que possible.
santisaez
2
Cela ressemble vraiment à un cas d'optimisation prématurée.
MikeyB
"Les commentaires ne peuvent être modifiés que pendant 5 minutes" - me sert bien d'être sur SF au travail .... comme je le disais; @MikeyB En fait, j'ai lu à ce sujet. L'article de Wikipédia a mentionné quelque chose que je ne savais pas. "En raison de la nature du fonctionnement de la mémoire flash, les données ne peuvent pas être écrasées directement comme elles le peuvent dans un lecteur de disque dur." Il serait donc logique que les blocs précédemment utilisés dans le swap soient vides ... mais ceux-ci ressembleront-ils à "0000" lorsque santisaez vérifie le contenu du swap?
Signal15
Tout cela se passe à une couche sous le système d'exploitation. En ce qui concerne le système d'exploitation, les données d'un bloc sont là jusqu'à ce qu'elles soient réécrites. Il incombe au lecteur de gérer le cycle de lecture-effacement-écriture.
MikeyB

Réponses:

1

Il semble que discard_swap_cluster soit uniquement appelé à partir de scan_swap_map qui à son tour est appelé à partir de get_swap_page ou get_swap_page_of_type . Donc, si je ne me trompe pas, l'élimination ne se produit que lorsqu'une nouvelle page de swap va être allouée, pas lorsqu'une page est libérée.

lav
la source
Cela ressemble à un bug.
kasperd
2
Ce n'est peut-être pas un bug. De cette façon, Linux peut supprimer plusieurs pages à la fois au lieu de le faire une par une.
lav
1

Il se peut que votre système ait --discard=oncepar défaut. Avez-vous essayé de monter avec une option de suppression spécifique?

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

et forcer comme ça:

# swapon --discard=pages /dev/sda2

Vous pouvez également essayer de créer un fstrimservice ou le configurer s'il est déjà disponible.

kgizdov
la source
-1

Lorsque j'arrête le script, il libère toute la mémoire, y compris les allocations de swap, «swapon -s» ne renvoie aucune utilisation de swap dans le système. À ce stade, il est prévu que Linux commence à supprimer le contenu de la partition de swap en arrière-plan, mais cela ne fonctionne pas , le contenu des secteurs est toujours «4141», même plusieurs heures plus tard.

Le contenu du swap est effectivement «jeté» lorsque swapon -srenvoie «aucun swap utilisé». Le système ne va pas écraser le contenu des blocs (rempli avec «4141») car il s'agit d'un SSD et des écritures excessives raccourciraient la durée de vie du SSD. (Du moins, c'est ce que je retiens de la documentation)

Signal15
la source
5
Si l' discardoption de montage est utilisée, les commandes TRIM doivent être envoyées au disque SSD sous-jacent pour éviter un problème d' amplification d'écriture sur les disques SSD. Du moins, c'est la façon dont d'autres systèmes de fichiers, comme ext4.
santisaez
Pour être clair, cela entraînerait en effet de lire uniquement des zéros avec cette commande hdparm, mais seulement après que le garbage collector du SSD ait eu la chance de s'exécuter.
Halfgaar