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

840/850 pro, a préciser, les 830 n'ont aucuns soucis.

pourquoi sous linux uniquement ? que fait linux de si particulier avec le TRIM ?

Car Windows ne supporte pas le queued TRIM.
Le non-queued TRIM est fonctionnel par contre.

 
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.

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

 
Mal lu  

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.

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.

précisé

Est-ce le même bug qui fait que les NAS Synology en DSM 5.2 ont perdu le TRIM ?

Décidément, ça va pas fort les SSD Samsung en ce moment...

 
Bonjour, j'ai le MX100 avec le firmware MU01 (d'origine) : aucun probleme de mon coté (mode Enhanced IDE)

Normal, vu que le queued trim est désactivé si ce SSD est détecté

 
et/ou de bannir definitivement les SSD Samsung des serveurs....

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

Le TRIM fonctionne en IDE, le AHCI n'est pas une obligation.

J'apprends un truc ... Merci

ça concerne aussi les EVO ?

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/

 
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.

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:

ça a l'air de marcher

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

Ca s'appelle l'informatique !

Et pour les perfs dégradées du 840, il fait quoi Samsung ?

il attend que vous en ayez marre d'en parler.

Il attend aussi leurs billets  

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

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

Le bug ne touche que les config RAID 0.
 
Cet article aurait dû mettre en évidence ce point.

Ç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 ?