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

21

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.

Shane Meyers
la source
1
Je soutiens entièrement le test des choses de pointe, mais juste pour que vous sachiez, en ce moment, btrfs n'a pas de fsck qui, en fait, vous corrige les choses: btrfs.wiki.kernel.org/index.php/Main_Page - so faites juste attention à ça.
Matt Simmons
@Matt - Bon point sur le fsck manquant. Ma compréhension est que la première version d'un fsck devrait être livrée dans les prochaines semaines, donc nous devrions être couverts par le temps que nous passons à la production. De plus, nous aurons plusieurs copies de nos données, donc si nous perdons une copie, nous avons au moins deux autres copies à restaurer. Mais je suis entièrement d'accord que ce n'est pas le système de fichiers pour les personnes avec des données irremplaçables pour l'instant.
Shane Meyers le
1
Cela ne changera probablement rien, mais vous pourriez aussi bien essayer d'exécuter un syncaprès avoir rmé le fichier.
zebediah49
Je veux dire que j'ai essayé d'exécuter un syncaprès avoir supprimé le fichier et que les résultats étaient toujours les mêmes. Je vérifierai cela quand je serai de retour au bureau après la fin du week-end.
Shane Meyers
si cela ne vous dérange pas, avez-vous pensé à zfsonlinux.org ? natif (c'est-à-dire dans le noyau, pas fusionné) ZFS pour linux. ils sont proches d'une "version" officielle, et ont des RC disponibles (y compris un PPA pour Ubuntu - assez facile à reconstruire pour debian aussi)
cas

Réponses:

4

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

Shane Meyers
la source
Je pensais que toutes les commandes HW RAID mangeaient du trim, c'est agréable de voir que les choses changent lentement. D'un autre côté, avec de bons entraînements modernes, TRIM importe de moins en moins.
Ronald Pottol
4

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.

chrishiestand
la source
3

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.

Dave Veffer
la source
2
J'ai essayé de suivre les instructions de vérification du SSD Ext4, mais elles ne fonctionnent pas en raison des différences de fonctionnement de BtrFS par rapport aux autres systèmes de fichiers. D'où le workflow que j'ai trouvé. J'ai utilisé l' ssdoption de montage pour m'assurer que BtrFS savait utiliser son code spécifique au SSD même s'il devait détecter automatiquement. J'ai également essayé d'utiliser discard(comme indiqué ci-dessus) et cela n'a pas aidé.
Shane Meyers
Tant pis. Vaut le coup :)
Dave Veffer
1

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

Paweł Brodacki
la source
1
Comme je l'ai mentionné ci-dessus, j'ai essayé mes tests avec l' discardoption et l' ssdoption. Les documents BtrFS mentionnent souvent cette ssdoption, j'ai donc concentré mes tests là-bas, mais aucune des options n'a abouti au résultat que j'attendais. La plupart des pages Web qui montrent comment tester TRIM sont pour Ext4 et similaires. BtrFS ne peut pas être testé à l'aide de ces méthodologies en raison de la différence de conception du système de fichiers.
Shane Meyers le
hdparm --fibmapest FS agnostique. Un bloc à une adresse LBA donnée est remis à zéro ou non, que ce soit l'option extN, btrfs, xfs, jfs ... ssdn'est pas pertinente pour le trim, voir par exemple cette discussion sur la liste de diffusion btrfs: mail-archive.com/linux-btrfs @ vger.kernel.org / msg10932.html .
Paweł Brodacki
J'ai essayé d'utiliser hdparm --fibmapmais cela ne fonctionne pas sur BtrFS. Si vous regardez le fichier Wiper.sh README (distribué avec hdparm), ils indiquent explicitement que "les appels FIEMAP / FIBMAP ioctl () sont complètement dangereux lorsqu'ils sont utilisés sur un système de fichiers btrfs." Donc hdparm est sorti, ce qui est dommage car cela rendrait les tests beaucoup plus faciles. Je ne savais pas que l' ssdoption n'avait rien à voir avec TRIM car les documents ne sont pas très clairs sur l'utilité de l'option.
Shane Meyers
Merci pour les informations supplémentaires sur ioctls, je ne le savais pas. Je pense que le meilleur endroit pour demander des informations supplémentaires pourrait être la liste de diffusion btrfs. Vous obtiendrez des informations de première main à partir de là.
Paweł Brodacki
1

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?
cas
la source
1

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?

Joshua Hoblitt
la source