Actu : Un bug de TRIM sous Linux pour les SSD Samsung ? [HFR] - HFR - Hardware
Marsh Posté le 20-06-2015 à 10:42:46 0
pourquoi sous linux uniquement ? que fait linux de si particulier avec le TRIM ?
Marsh Posté le 20-06-2015 à 11:05:33 0
Car Windows ne supporte pas le queued TRIM.
Le non-queued TRIM est fonctionnel par contre.
Marsh Posté le 20-06-2015 à 11:10:18 0
Gein a écrit : Car Windows ne supporte pas le queued TRIM. |
Pas de rapports avec la choucroute. Le qTrim était déjà banni sur les samsung. Là, on parle du Trim classique (discard). Imho, ça doit venir d'un problème de µC et/où de FS qui génère la commande discard et/ou du proto SCSI utilisé dernièrement qui foire.
Marsh Posté le 20-06-2015 à 11:14:37 0
A noter que Crucial a patché le bug dans son firmware MU02 pour tout ses SSD hormis le M500
https://lkml.org/lkml/2015/6/10/646
Marsh Posté le 20-06-2015 à 11:16:05 0
MysterieuseX a écrit : |
Mal lu
Marsh Posté le 20-06-2015 à 11:38:43 0
Je n'arrive pas à comprendre si le bug est spécifique Linux: il a été détecté sur Linux ok, mais rien ne dit qu'un autre OS n'a aucun risque d'avoir le même bug avec ces ssd?
Marsh Posté le 20-06-2015 à 11:49:24 0
Fanfan71 a écrit : Je n'arrive pas à comprendre si le bug est spécifique Linux: il a été détecté sur Linux ok, mais rien ne dit qu'un autre OS n'a aucun risque d'avoir le même bug avec ces ssd? |
Oupah, notion d'atomicité sous linux qu'il n'y a pas sous windows, par exemple.
Marsh Posté le 20-06-2015 à 11:52:13 0
On sait depuis le premier jour que le firmware EXT0DB6Q pète le TRIM en plus de ne pas régler le problème connu.
Marsh Posté le 20-06-2015 à 12:29:31 0
taz300 a écrit : A noter que Crucial a patché le bug dans son firmware MU02 pour tout ses SSD hormis le M500 |
précisé
Marsh Posté le 20-06-2015 à 13:21:18 0
Est-ce le même bug qui fait que les NAS Synology en DSM 5.2 ont perdu le TRIM ?
Marsh Posté le 20-06-2015 à 16:20:28 3
Décidément, ça va pas fort les SSD Samsung en ce moment...
Marsh Posté le 20-06-2015 à 19:53:33 0
Citation : les Crucial/Micron M500, M550 et MX100 faisant également partis de la liste des bannis sauf si ils sont en firmware MU02 pour les deux derniers. |
Bonjour, j'ai le MX100 avec le firmware MU01 (d'origine) : aucun probleme de mon coté (mode Enhanced IDE)
Marsh Posté le 20-06-2015 à 19:55:56 0
Normal, vu que le queued trim est désactivé si ce SSD est détecté
Marsh Posté le 21-06-2015 à 02:32:13 0
Citation : |
et/ou de bannir definitivement les SSD Samsung des serveurs....
Marsh Posté le 21-06-2015 à 15:45:02 1
En même temps si tu es en Enhanced IDE et pas en AHCI tu n'as pas le trim ni les autres options du sata d'activées ...
Marsh Posté le 21-06-2015 à 19:05:51 1
Le TRIM fonctionne en IDE, le AHCI n'est pas une obligation.
Marsh Posté le 21-06-2015 à 19:53:37 2
Marc a écrit : Le TRIM fonctionne en IDE, le AHCI n'est pas une obligation. |
J'apprends un truc ... Merci
Marsh Posté le 21-07-2015 à 23:03:42 0
Après analyse il n'y aurait pas de problème de Queued TRIM sur les SSD Samsung, ça serait un bug du kernel:
https://blog.algolia.com/when-solid [...] hat-solid/
Citation : UPDATE July 17: |
Ce n'est pas si étonnant que ça au final, car la blacklist grossissait régulièrement sur des modèles de différents constructeurs.
Marsh Posté le 22-07-2015 à 08:18:24 0
Mais le patch et la doc annoncé ne sont pas encore dispo alors que la date est dépassée, on mettra à jour quand ce sera le cas !
Marsh Posté le 24-07-2015 à 15:01:03 0
Marc a écrit : Mais le patch et la doc annoncé ne sont pas encore dispo alors que la date est dépassée, on mettra à jour quand ce sera le cas ! |
patch soumis ici:
http://www.spinics.net/lists/raid/msg49440.html
discussion qui se termine par:
Citation : I have tested the script from Algolia with your patch, I cannot see the same |
Citation : Thank you for your diligent work on this issue! I just submitted the |
ça a l'air de marcher
Marsh Posté le 31-07-2015 à 12:15:57 1
Le bug était donc dans l'interaction entre le RAID 0 logiciel Linux et sa gestion de la file de commandes ATA : une variable était partagée par les deux. La gestion de TRIM a introduit une modification extérieure de cette variable que le RAID0 ignorait et écrasait, changeant la zone à effacer par la commande TRIM.
Comme toujours, une solution est pensée, et 20 ans plus tard une nouveauté introduit un bug...
Marsh Posté le 31-07-2015 à 12:39:07 1
zezinho a écrit : |
Ca s'appelle l'informatique !
Marsh Posté le 31-07-2015 à 16:10:01 0
Et pour les perfs dégradées du 840, il fait quoi Samsung ?
Marsh Posté le 31-07-2015 à 16:44:53 0
ReplyMarsh Posté le 31-07-2015 à 16:46:16 0
ReplyMarsh Posté le 02-08-2015 à 12:00:07 0
zezinho a écrit : Le bug était donc dans l'interaction entre le RAID 0 logiciel Linux et sa gestion de la file de commandes ATA : une variable était partagée par les deux. La gestion de TRIM a introduit une modification extérieure de cette variable que le RAID0 ignorait et écrasait, changeant la zone à effacer par la commande TRIM. |
Vu la description, c'est bel et bien un bug noyau. C'est surement liés aux algo de gestion de la queue cotés SSD, cf les micron qui marche ou pas selon le firmware. Du coup je me demande qu'elle est la nature du changement du firmware MU02...
Marsh Posté le 03-08-2015 à 14:12:03 0
J'aimerais bien savoir si le vmkernel des esxi est concerné par ce bug... non pas que je sois inquiet de perdre toutes mes vm
Marsh Posté le 09-08-2015 à 09:04:55 0
Le bug ne touche que les config RAID 0.
Cet article aurait dû mettre en évidence ce point.
Marsh Posté le 11-08-2015 à 15:27:15 0
Ça a bashé Samsung, ça a poueté sur Windows qui sait pas faire ce que Linux sait faire, et au final... c'est un bug dans l'implémentation du raid 0 software côté linux. Ironique non ?
Marsh Posté le 20-06-2015 à 10:00:02 0
Spécialisée dans les moteurs de recherche, Algolia vient de publier un billet concernant une problématique qu'ils ont rencontré sur leurs serveurs tournant ...
Lire la suite ...