Vérifier la prise en charge de TRIM avec BtrFS sur SSD

Nous envisageons d'utiliser BtrFS sur un tableau de disques SSD et on m'a demandé de vérifier que BtrFS effectue effectivement des opérations TRIM lors de la suppression d'un fichier. Jusqu'à présent, je n'ai pas pu vérifier que la commande TRIM est envoyée aux disques.

Je sais que BtrFS n'est pas considéré comme prêt pour la production, mais nous aimons le bord de fuite, donc je le teste. Le serveur est une version 64 bits du serveur Ubuntu 11.04 (mkfs.btrfs version 0.19). J'ai installé le noyau Linux 3.0.0 car le journal des modifications BtrFS indique que TRIM en vrac n'est pas disponible dans le noyau livré avec Ubuntu 11.04 (2.6.38).

Voici ma méthodologie de test (initialement adoptée à partir de http://andyduffell.com/techblog/?p=852 , avec des modifications pour fonctionner avec BtrFS):

• TRIM manuellement les disques avant de commencer: for i in {0..10} ; do let A="$i * 65536" ; hdparm --trim-sector-ranges $A:65535 --please-destroy-my-drive /dev/sda ; done
• Vérifiez que le disque a été TRIM: ./sectors.pl |grep + | tee sectors-$(date +%s)
• Partitionnez le lecteur: fdisk /dev/sda
• Faites le système de fichiers: mkfs.btrfs /dev/sda1
• Monter: sudo mount -t btrfs -o ssd /dev/sda1 /mnt
• Créez un fichier: dd if=/dev/urandom of=/mnt/testfile bs=1k count=50000 oflag=direct
• Vérifiez que le fichier se trouve sur le disque: ./sectors.pl | tee sectors-$(date +%s)
• Supprimez le fichier de test: rm /mnt/testfile
• Vérifiez que le fichier de test est TRIM à partir du disque: ./sectors.pl | tee sectors-$(date +%s)
• Vérifiez les blocs TRIM'd: diffles deux sectors-*fichiers les plus récents

À ce stade, les vérifications pré-suppression et post-suppression affichent toujours les mêmes blocs de disque utilisés. Je devrais plutôt voir une réduction du nombre de blocs en cours d'utilisation. L'attente d'une heure (au cas où il faudrait un certain temps pour que la commande TRIM soit émise) après la suppression du fichier de test affiche toujours les mêmes blocs utilisés.

J'ai également essayé de monter avec les -o ssd,discardoptions, mais cela ne semble pas du tout aider.

Partition créée par le fdiskhaut (je garde la partition petite pour que la vérification puisse aller plus vite):

root@ubuntu:~# fdisk -l -u /dev/sda

Disk /dev/sda: 512.1 GB, 512110190592 bytes
255 heads, 63 sectors/track, 62260 cylinders, total 1000215216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x6bb7542b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63      546209      273073+  83  Linux

Mon sectors.plscript (je sais que c'est inefficace, mais il fait le travail):

#!/usr/bin/perl -w

use strict;

my $device = '/dev/sda';
my $start = 0;
my $limit = 655360;

foreach ($start..$limit) {
    printf "\n%6d ", $_ if !($_ % 50);
    my @sector = `/sbin/hdparm --read-sector $_ $device`;
    my $status = '.';
    foreach my $line (@sector) {
            chomp $line;
            next if $line eq '';
            next if $line =~ /$device/;
            next if $line =~ /^reading sector/;
            if ($line !~ /0000 0000 0000 0000 0000 0000 0000 0000/) {
                    $status = '+';
            }
    }
    print $status;
}
print "\n";

Ma méthodologie de test est-elle défectueuse? Est-ce que j'ai râté quelque chose?

Merci pour l'aide.

Donc, après plusieurs jours de travail, j'ai pu démontrer que BtrFS utilise TRIM. Je n'ai pas réussi à faire fonctionner TRIM sur le serveur sur lequel nous déploierons ces SSD. Cependant, lors des tests avec le même lecteur branché sur un ordinateur portable, les tests réussissent.

Matériel utilisé pour tous ces tests:

• Crucial m4 SSD 512GB
• HP DL160se G6
• LSI LSISAS9200-8e HBA
• boîtier SAS générique
• Ordinateur portable Dell XPS m1210

Après de nombreuses tentatives infructueuses de vérification de BtrFS sur le serveur, j'ai décidé d'essayer ce même test à l'aide d'un ancien ordinateur portable (supprimer la couche de carte RAID). Les premières tentatives de ce test en utilisant à la fois Ext4 et BtrFS sur l'ordinateur portable échouent (données non TRIM'd).

J'ai ensuite mis à niveau le micrologiciel du lecteur SSD de la version 0001 (telle que livrée hors de l'emballage) à la version 0009. Les tests ont été répétés avec Ext4 et BtrFS et les deux systèmes de fichiers ont TRIM réussi les données.

Pour m'assurer que la commande TRIM a eu le temps de s'exécuter, j'ai fait un rm /mnt/testfile && sync && sleep 120avant d'effectuer la validation.

Une chose à noter si vous tentez ce même test: les SSD ont des blocs d'effacement sur lesquels ils fonctionnent (je ne connais pas la taille des blocs d'effacement Crucial m4). Lorsque le système de fichiers envoie la commande TRIM au lecteur, le lecteur n'effacera qu'un bloc complet; si la commande TRIM est spécifiée pour une partie d'un bloc, ce bloc ne sera pas TRIM en raison des données valides restantes dans le bloc d'effacement.

Donc pour démontrer de quoi je parle (sortie du sectors.plscript ci-dessus). C'est avec le fichier de test sur le SSD. Les périodes sont des secteurs qui ne contiennent que des zéros. Les avantages ont un ou plusieurs octets non nuls.

Fichier de test sur le lecteur:

24600 .......................................+++++++++++
24650 ++++++++++++++++++++++++++++++++++++++++++++++++++
24700 ++++++++++++++++++++++++++++++++++++++++++++++++++
    -- cut --
34750 ++++++++++++++++++++++++++++++++++++++++++++++++++
34800 ++++++++++++++++++++++++++++++++++++++++++++++++++
34850 +++++++++++++++++++++++++++++.....................

Fichier de test supprimé du lecteur (après a sync && sleep 120):

24600 .......................................+..........
24650 ..................................................
24700 ..................................................
    -- cut --
34750 ..................................................
34800 ..................................................
34850 ......................+++++++.....................

Il semble que les premier et dernier secteurs du fichier se trouvent dans des blocs d'effacement différents du reste du fichier. Par conséquent, certains secteurs n'ont pas été touchés.

Un exemple à retenir: certaines instructions de test TRIM Ext4 demandent à l'utilisateur de vérifier uniquement que le premier secteur a été TRIM du fichier. Le testeur doit afficher une plus grande partie du fichier de test pour vraiment voir si le TRIM a réussi ou non.

Maintenant, pour comprendre pourquoi les commandes TRIM émises manuellement envoyées au SSD via la carte RAID fonctionnent, mais les commandes TRIM automatiques pour ne pas ...

D'après ce que j'ai lu, il peut y avoir une faille dans votre méthodologie.

Vous supposez que TRIM entraînera la remise à zéro de votre SSD des blocs qui ont été supprimés. Cependant ce n'est pas souvent le cas.

Ce n'est que si le SSD implémente TRIM pour qu'il remette à zéro les blocs supprimés. Vous pouvez vérifier si l'appareil en sait au moins suffisamment pour signaler discard_zeroes_data:

cat / sys / block / sda / queue / discard_zeroes_data

De plus, même si le SSD fait zéro, cela peut prendre un certain temps - bien après la fin de l'élimination - pour que le SSD remette à zéro les blocs (c'est le cas pour certains SSD de moindre qualité).

http://www.redhat.com/archives/linux-lvm/2011-April/msg00048.html

BTW Je cherchais un moyen fiable de vérifier TRIM et je n'en ai pas encore trouvé. J'adorerais savoir si quelqu'un trouve un moyen.

Voici la méthodologie de test pour 10.10 et EXT4. Ça va peut-être aider.

/ubuntu/18903/how-to-enable-trim

Oh et je pense que vous avez besoin du paramètre discard sur la monture fstab. Je ne sais pas si le paramètre SSD est nécessaire car je pense qu'il devrait détecter automatiquement le SSD.

Pour btrfs, vous avez besoin d'une discardoption pour activer le support TRIM.

Un test très simple mais fonctionnel pour TRIM fonctionnel est ici: http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2

Quelques éléments à considérer (pour répondre à votre question «Suis-je en train de manquer quelque chose?»):

• qu'est-ce que / dev / sda exactement? un seul SSD? ou une matrice RAID (matérielle?) de SSD?

• si ce dernier alors quel type de contrôleur RAID?

• et votre contrôleur de raid prend-il en charge TRIM?

et enfin,

• votre méthode de test vous donne-t-elle les résultats que vous attendez si vous formatez / dev / sda1 avec autre chose que btrfs?

Presque tous les SSD avec une interface SATA exécutent une sorte de système de fichiers de structure de journal qui vous est complètement caché. La commande SATA 'trim' indique au périphérique que le bloc n'est plus utilisé et que le système de fichiers sous-jacent de la structure du journal peut le flasher / si / le bloc d'effacement correspondant (qui pourrait être sensiblement plus grand) / uniquement / contient des blocs marqués avec trim.

Je n'ai pas lu les documents standard, qui sont ici: http://t13.org/Documents/MinutesDefault.aspx?keyword=trim , mais je ne sais pas s'il existe une garantie de niveau standard que vous seriez en mesure de voir les résultats d'une commande de trim. Si vous pouvez voir quelque chose changer, comme les premiers octets mis à zéro au début d'un bloc d'effacement, je ne pense pas qu'il y ait de garantie que cela s'applique à différents appareils ou peut-être même à la version du firmware.

Si vous réfléchissez à la façon dont l'abstraction pourrait être implémentée, il devrait être possible de rendre le résultat de la commande trim complètement invisible pour celui qui ne fait que lire / écrire des blocs. De plus, il peut être difficile de dire quels blocs se trouvent dans le même bloc d'effacement, car seule la couche de traduction flash doit le savoir et peut les avoir réorganisés logiquement.

Peut-être existe-t-il une commande SATA (commande OEM peut-être?) Pour récupérer les métadonnées liées à la couche de traduction flash des SSD?