SanDisk SSD Plus: Deux fois moins performant sous Linux que sous Windows?
J'ai deux disques SSD sur mon ordinateur portable:
- Crucial MX300 725GB ->/dev/sda
- SanDisk SSD Plus 240 Go ->/dev/sdb
Leurs performances se lisent sous Linux et Windows comme ceci:
Crucial MX300 -> identique sur les deux systèmes d'exploitation
Sudo hdparm -tT /dev/sda # Crucial
Timing cached reads: 13700 MB in 2.00 seconds = 6854.30 MB/sec
Timing buffered disk reads: 1440 MB in 3.00 seconds = 479.58 MB/sec
SanDisk Plus -> beaucoup plus vite sous Windows!
Sudo hdparm -tT /dev/sdb # SanDisk
Timing cached reads: 7668 MB in 2.00 seconds = 3834.92 MB/sec
Timing buffered disk reads: 798 MB in 3.00 seconds = 265.78 MB/sec # TOO LOW !!
Les performances de lecture séquentielle du SanDisk sous Linux représentent environ la moitié de ses performances sous Windows!
Ma question est bien sûr: Pourquoi et cela peut-il être corrigé? Cela est-il dû au fait que le SanDisk SSD Plus est traité comme un lecteur SCSI?
De syslog:
~$ grep SDSSD /var/log/syslog
systemd[1]: Found device SanDisk_SDSSDA240G
kernel: [ 2.152138] ata2.00: ATA-9: SanDisk SDSSDA240G, Z32070RL, max UDMA/133
kernel: [ 2.174689] scsi 1:0:0:0: Direct-Access ATA SanDisk SDSSDA24 70RL PQ: 0 ANSI: 5
smartd[1035]: Device: /dev/sdb [SAT], SanDisk SDSSDA240G, S/N:162783441004, WWN:5-001b44-4a404e4f0, FW:Z32070RL, 240 GB
smartd[1035]: Device: /dev/sdb [SAT], state read from /var/lib/smartmontools/smartd.SanDisk_SDSSDA240G-162783441004.ata.state
smartd[1035]: Device: /dev/sdb [SAT], state written to /var/lib/smartmontools/smartd.SanDisk_SDSSDA240G-162783441004.ata.state
Par rapport au Crucial MX300 qui a sur Linux les mêmes performances que sur Windows:
~$ grep MX300 /var/log/syslog
systemd[1]: Found device Crucial_CT750MX300SSD1
kernel: [ 1.775520] ata1.00: ATA-10: Crucial_CT750MX300SSD1, M0CR050, max UDMA/133
smartd[1035]: Device: /dev/sda [SAT], Crucial_CT750MX300SSD1, S/N:16251486AC40, WWN:5-00a075-11486ac40, FW:M0CR050, 750 GB
smartd[1035]: Device: /dev/sda [SAT], state read from /var/lib/smartmontools/smartd.Crucial_CT750MX300SSD1-16251486AC40.ata.state
smartd[1035]: Device: /dev/sda [SAT], state written to /var/lib/smartmontools/smartd.Crucial_CT750MX300SSD1-16251486AC40.ata.state
Toute aide est la bienvenue!
Modifier:
La différence que hdparm montre sous Linux est très réelle. J'ai créé deux répertoires identiques, un dans chacun des deux lecteurs, chaque répertoire contenant environ 25 Go de fichiers (36395 fichiers) et exécuté le même script de création de somme de contrôle hashdeep dans les deux répertoires (le script crée simplement une somme de contrôle md5 pour chaque fichier). dans les répertoires de test et stocke toutes les sommes de contrôle dans un seul fichier). Ce sont les résultats:
test-sandisk# time create-file-integrity-md5sums.sh .
real 1m49.000s
user 1m24.868s
sys 0m15.808s
test-mx300# time create-file-integrity-md5sums.sh .
real 0m54.180s
user 1m4.628s
sys 0m11.640s
Même test avec un seul fichier 7Gb:
test-sandisk# time create-file-integrity-md5sums.sh .
real 0m26.986s
user 0m19.168s
sys 0m3.232s
test-mx300# time create-file-integrity-md5sums.sh .
real 0m17.285s
user 0m16.248s
sys 0m1.368s
Éditer 2:
Les partitions sont "optimales" alignées et la seule différence entre/sys/block/$ disk/queue est discard_zeroes_data (1 sur Crucial, 0 sur SanDisk). Système de fichiers et options de montage utilisés: type ext4 (rw, nosuid, nodev, relatime, données = ordonné, uhelper = udisks2)
dmesg | grep -i sata | grep 'link up'
[ 1.936764] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2.304548] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Comparaison avec les clés USB
Les clés USB simples ralentissent progressivement après une utilisation prolongée. Ces disques n'ont pas de fonction de mise au rebut (pour autant que je sache, je ne parle pas de clés USB avancées et très chères). Effacer tous les disques en écrasant des zéros (ou en interne) rétablira la vitesse. De ma propre expérience, je sais que cela s'applique aux clés USB Sandisk Extreme, qui sont rapides lorsqu'elles sont neuves (par rapport à d'autres clés USB simples).
Je pense donc que la méthode de mise au rebut (ou son absence) peut également être responsable de la baisse des performances de votre Sandisk SSD. Je pense que la réponse de @ Starman ajoute des informations précieuses pour résoudre votre problème.
Vous pouvez
essayez de laisser le système en veille pendant la nuit et vérifiez s’il a utilisé le temps d’inactivité pour rattraper le temps perdu. Si pas de chance, vous pouvez
essuyez l'espace libre du lecteur et vérifiez si cela améliore les performances,
essayez de trouver une option de montage sous linux, ou une configuration du SSD, qui améliorera les performances.
Outils
zerofreeest un outil efficace pour les systèmes de fichiersext. Voir ce lien,Sinon (si vous cochez et vérifiez que tout est correct), vous pouvez utiliser
ddpour créer un fichier volumineuxblankcontenant des zéros, puis l'effacer (lentement, mais cela fonctionne dans tous les systèmes de fichiers).Démarrer à partir d'un autre lecteur, par exemple un lecteur USB actif
cd <mountpoint-of-the-target-partition> # for example: cd /mnt Sudo dd if=/dev/zero of=blank bs=4096Laissez-le fonctionner jusqu'à ce qu'il s'arrête car le lecteur est plein, puis supprimez le fichier
blank. Cela suppose qu’il n’existe déjà aucun fichier utile portant le nomblank.Sudo rm blankAvertissement:
ddest un outil puissant mais dangereux. Vérifiez et vérifiez de nouveau que vous ne détruirez pas de données de valeur. Dans ce cas, jouer en toute sécurité consiste à sauvegarder tout ce qui a de la valeur sur les lecteurs connectés vers un autre emplacement (par exemple, sur un lecteur externe déconnecté par la suite).
Essuyer tout l'appareil
Ma méthode pour les clés USB consiste à effacer tout le périphérique (pas seulement l'espace libre entre les fichiers d'une partition partiellement remplie). Je pense que c'est la méthode la plus efficace pour les clés USB, mais je pense qu'il devrait exister un paramètre de mise au rebut qui fonctionne efficacement dans un SSD sans effacer tout le périphérique. Quoi qu'il en soit, si vous souhaitez tester, vous pouvez l'essayer, puis créer une nouvelle table de partition et une partition ext4. Voir ce lien
Je voulais ajouter un commentaire en réponse à l'excellent message de @sudodus, mais je suis toujours à 4 points de rep à ce que je sois autorisé à le commenter, alors collez-le ici:
Pour ce qui est de laisser les choses en veille - avec la technologie eMMC sur laquelle j'ai travaillé (encore une fois, elle devrait être semblable mais pas identique à la vôtre), cela n'aurait pas fonctionné, car l'appareil devait supposer que les concepteurs de système pourraient couper l'alimentation principale et ne laisser que le IO pouvoir est vivant.
Il existe en fait un mode de veille permettant de coordonner les économies d’énergie, mais je me souviens que les fournisseurs eMMC ont déclaré ne pas vouloir commencer à effectuer des opérations en arrière-plan au milieu de l’instant, mais qu’elles n’exécutaient ces opérations que lorsqu’elles acceptaient une commande. vous l'envoyez, et avant de renvoyer le statut (résultat).
Il est possible que les disques SSD soient différents, grâce à un contrôleur qui, spécifiquement, pendant le temps d'inactivité, envoie des commandes au back-end flash NAND, ce qui conduit au nettoyage et à la réorganisation des blocs de données qu'il contient. Mais je ne m'attendrais pas nécessairement à ce que cela se produise, en fonction de mon expérience.
Ce n'est peut-être pas une assez bonne réponse, mais je suis nouveau et je ne peux pas "commenter", et je voulais le partager avec vous au cas où cela vous aiderait:
J'avais l'habitude de travailler avec des mémoires flash eMMC, bases matérielles similaires à celles du SSD. discard_zeroes_data semble pouvoir compter. Il y avait des fonctionnalités très lentes appelées Erase et particulièrement Trim (comme Erase, mais sur une base de 4 ko en lecture-bloc au lieu du beaucoup plus grand Erase Group Block nécessaire à la performance. Plus tard, une fonctionnalité "Élimination" a été introduite qui n'a pas effacé les données. tous les zéros (vraiment tous les uns sous le capot, mais inversés pour votre commodité), mais vient de changer l'état des données à "ne pas s'en soucier".
Ainsi, si vous supprimez 4 ko de données, la procédure est plus rapide car elle ne supprime pas, mais indique au micrologiciel que vous n’avez plus besoin de ces données et garde la trace de cette zone physique dans une table. Cela a permis au type de mécanisme de récupération de place de récupérer cet emplacement de données (probablement de le mapper à une adresse différente) plus tard, lorsque suffisamment de voisins pourraient être effacés, en copiant les données nécessaires dans un autre domaine selon les besoins, puis en effectuant le coûteux "Erase". "opération en arrière-plan.
TBH, nous avons fini par désactiver la suppression au début, car cela ne fonctionnait pas très bien et nous posait des problèmes de performances lorsque trop de données étaient laissées en mode de suppression et que la suppression physique ne s’est jamais produite.
Donc, je ne peux pas dire ce que "discard_zeros_data" signifie exactement, mais si j'étais vous, j'essaierais certainement de passer de l'état opposé à l'autre et de voir ce qui se passe. S'il se lit comme "objet du verbe sujet", il peut s'agir d'une fonctionnalité de sécurité dans laquelle il faut du temps pour effacer de force même de petits morceaux de données (coûteux), de sorte qu'il n'y ait aucune chance que quelqu'un puisse récupérer vos anciens fichiers après vous avoir pensé. " les ai supprimés. Je pense que définir ce paramètre sur "zéro" augmenterait les performances, si c'est ce que vous lisez, mais vous constatez le contraire.
Essayez également de faire le plus grand "effacement" possible, que vous utilisiez des outils SSD spéciaux, un format complet ou quelque chose du genre, et voyez si les performances sont meilleures juste après cet effacement. Cela vous donnera au moins des informations sur le problème.
Le type de système de fichiers devrait certainement aussi être important, mais je pense que c'est une constante dans vos deux expériences.