IPB

Bienvenue invité ( Connexion | Inscription )

 
Reply to this topicStart new topic
> Linux: Un bug du Trim sur les SSD Samsung provoque une corruption des données, Réactions à la publication du 22/06/2015
Options
Lionel
posté 21 Jun 2015, 23:00
Message #1


BIDOUILLE Guru
*****

Groupe : Admin
Messages : 55 328
Inscrit : 14 Jan 2001
Lieu : Paris
Membre no 3



La société Algolia, spécialisée dans les moteurs de recherche, a publié un billet d'alerte après avoir constaté une corruption des données stockées sur les SSD de ses serveurs sous Linux.
Elle semble liée à un bug sur les SSD Samsung 840 Pro et 850 Pro, qu'ils utilisent et qui ont une incompatibilité avec la commande TRIM de Linux.
Le bug n'est pas lié au nouveau système de fil d'attente de la commande TRIM désactivée sur ces machines mais à un autre problème.
La société et Samsung travaillent activement à régler ce problème dans les plus brefs délais. Notez qu'on ignore s'il touche d'autres marques de SSD mais les modèles professionnels d'Intel ne sont pas concernés.
En attendant, il est probablement préférable de désactiver le TRIM sur les SSD Samsung fonctionnant sous Linux.

Cette nouvelle commande de mise en queue du TRIM (qui n'est pas la cause du problème ici) est apparue récemment. Elle permet de gagner en performances mais a posé des problèmes sur nombre de SSD. Ainsi, Crucial a dû mettre à jour le firmware de ses SSD récents pour échapper à cette corruption de données. On peut présumer qu'on a dû leur apprendre à prendre en compte le fait que la commande de TRIM d'une cellule pouvait arriver en retard et qu'il fallait en tenir compte si les données avaient été remaniées pendant ce court laps de temps.

[MàJ] Il semblerait finalement que le bug n'était pas situé au niveau des firmwares de ces SSD Samsung, mais bien au niveau du noyau Linux, pour lequel Samsung a proposé un correctif.


Lien vers le billet original



--------------------
C'est parce que la vitesse de la lumière est plus grande que celle du son que tant de gens paraissent brillants avant d'avoir l'air con
Go to the top of the page
 
+Quote Post
SonyTEL
posté 22 Jun 2015, 00:53
Message #2


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 526
Inscrit : 11 Nov 2003
Membre no 11 503




Les disques concernés sont "bien entendu" une fois encore des Samsung.

Go to the top of the page
 
+Quote Post
blacksmith
posté 22 Jun 2015, 02:21
Message #3


Adepte de Macbidouille
*

Groupe : Membres
Messages : 62
Inscrit : 5 Jun 2009
Lieu : YUL
Membre no 137 139



Samsung ont investi dans Seagate. Ils ont probablement aussi racheter ses équipes de développeurs de bugs et de corruption de disques. wink.gif

Ce message a été modifié par blacksmith - 22 Jun 2015, 02:22.
Go to the top of the page
 
+Quote Post
WipeOut
posté 22 Jun 2015, 05:49
Message #4


Macbidouilleur de vermeil !
****

Groupe : Membres
Messages : 848
Inscrit : 27 Jun 2004
Lieu : Suisse
Membre no 20 512



Voilà pourquoi Apple n'a pas de TRIM pour les autres constructeurs.

OK je sors biggrin.gif


--------------------
Mac Studio M1 / Mac OS X 10.14.x / 2x Asus PA278QV / 2x Airport Extreme AC Tower / iPhone SE 2022 / MacBook Pro 13" 2009 / Mac Mini alias MediaCenter

PC Gaming ONLY : Ryzen 7700X, Asus ROG Strix X670E-A Gaming WIFI Ram 32 GB, Asus TUF 3080Ti, Tour Pure Base 500DX White, Ventirad Be Quiet! Dark Rock Pro 4, Alim 750W CORSAIR HX750i, Ventilos : Be Quiet! & Noctua
Go to the top of the page
 
+Quote Post
Montréal
posté 22 Jun 2015, 06:27
Message #5


Macbidouilleur de vermeil !
****

Groupe : Membres
Messages : 1 139
Inscrit : 17 Sep 2010
Membre no 159 100



A l'heure où ne rate pas une occasion de se moquer de Seagate concernant les DD et de nous inciter à aller ailleurs, il serait bon d'en faire tout autant avec Samsung et ses SSD foireux…
Go to the top of the page
 
+Quote Post
cquest
posté 22 Jun 2015, 08:56
Message #6


Adepte de Macbidouille
*

Groupe : Membres
Messages : 137
Inscrit : 16 Feb 2005
Lieu : 94
Membre no 33 210



Ce bug du firmware des SSD Samsung, ne semble pas spécifiquement lié à Linux.

Le post d'origine montre la difficulté à cerner d'où venait le problème de corruption. Il est possible que ceci se produise sur d'autres OS sans qu'on soit remonté à un bug dans la gestion du TRIM dans le firmware de certains SSD...

La liste de problèmes avec les SSD Samsung commence à être longue. Entre les défauts des 840, 840 EVO (problème de maintien des niveaux électriques des cellules) et maintenant les séries "Pro" qui semblaient jusque à plus fiables ça fait beaucoup.


--------------------
MacBook Pro M1 14" 2021, MacPro 2009 4x2.93, MacBook 2010 Pro Unibody 15"... et plus d'une trentaine de Mac depuis mon Mac 512 ;-)
mais aussi... Apple IIe, IIe Platinum, IIc, IIgs, IIe dans Macintosh LC 475, Newton
Mes serveurs Minitel restaurés: COMPUTEL 01 8421 8116 (Apple II), et JCA 01 8421 8115 (Quadra 650)
Go to the top of the page
 
+Quote Post
pm13
posté 22 Jun 2015, 12:14
Message #7


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 341
Inscrit : 26 Jun 2004
Membre no 20 490



effacé

Ce message a été modifié par pm13 - 17 Jul 2015, 23:55.
Go to the top of the page
 
+Quote Post
iAPX
posté 22 Jun 2015, 12:19
Message #8


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 15 371
Inscrit : 4 Jan 2006
Lieu : dtq
Membre no 52 877



Cela explique la filosité d'Apple a proposer du TRIM autre que sur ses propres SSD, ou des SSD qu'ils ont validés.

La bug sous Linux, avec la commande TRIM standard (non-queued) démontre que ça peut arriver sur certains patterns d'utilisation, et donc qu'une modification des drivers des disques peuvent les faire apparaitre sous OS X (ou n'importe quel autre OS) même avec des disques qui précédemment n'exhibaient pas ce défaut. Idem pour le firmware des SSD, puisque suivant la version de celui-ci les réactions semblent différentes d'après les premiers retours d'utilisateurs des SSD touchés.

Samsung semble de moins en moins sérieux, avec des générations qui ont des problèmes différents et graves.


--------------------
Utilisateur de Mac depuis 1985 et possesseur de Mac depuis 2005. Utilisateur d'un PC Lenovo au travail, sous Windows, qui renforce ma passion pour les Mac!
Go to the top of the page
 
+Quote Post
Lionel
posté 22 Jun 2015, 15:34
Message #9


BIDOUILLE Guru
*****

Groupe : Admin
Messages : 55 328
Inscrit : 14 Jan 2001
Lieu : Paris
Membre no 3



Cette histoire de frilosité ne tient pas.
Est-ce que quelqu'un a accusé Linux d'être merdique ? Non, on parle bien de problèmes avec les SSD Samsung.
Si l'éditeur de l'OS a suivi à la lettre les spécifications et qu'il y a un problème, c'est la faute du fabricant de SSD, c'est tout sauf si l'éditeur n'a pas suivi les règles.


--------------------
C'est parce que la vitesse de la lumière est plus grande que celle du son que tant de gens paraissent brillants avant d'avoir l'air con
Go to the top of the page
 
+Quote Post
iAPX
posté 22 Jun 2015, 17:36
Message #10


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 15 371
Inscrit : 4 Jan 2006
Lieu : dtq
Membre no 52 877



Citation (Lionel @ 22 Jun 2015, 10:34) *
Cette histoire de frilosité ne tient pas.
Est-ce que quelqu'un a accusé Linux d'être merdique ? Non, on parle bien de problèmes avec les SSD Samsung.
Si l'éditeur de l'OS a suivi à la lettre les spécifications et qu'il y a un problème, c'est la faute du fabricant de SSD, c'est tout sauf si l'éditeur n'a pas suivi les règles.

Oui on est d'accord là-dessus, mais ce genre de problème peut justifier de se passer du Trim par défaut. On peut s'entendre que le proposer en option, via une ligne de commande ne demandant PAS de désactiver la sécurité par signature des extension au Kernel serait dans ce cas justifié. Je parlais bien de problème de Samsung même si c'est "sous Linux".

Mais par défaut, OS X est safe avec les SSD tierce-partie, même si leur firmware change, pour le TRIM. À choisir, pour tout un chacun dont moi, je pense que c'est une meilleure chose et que sur la durée ça limite considérablement les risques pour les utilisateurs.


--------------------
Utilisateur de Mac depuis 1985 et possesseur de Mac depuis 2005. Utilisateur d'un PC Lenovo au travail, sous Windows, qui renforce ma passion pour les Mac!
Go to the top of the page
 
+Quote Post
Kierkegaard
posté 22 Jun 2015, 19:10
Message #11


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 6 478
Inscrit : 11 Feb 2008
Lieu : Made in Quebec
Membre no 107 488



Citation (Montréal @ 22 Jun 2015, 01:27) *
A l'heure où ne rate pas une occasion de se moquer de Seagate concernant les DD et de nous inciter à aller ailleurs, il serait bon d'en faire tout autant avec Samsung et ses SSD foireux…

Tout le monde n'utilise pas un serveur sous Linux ( i.e. le grand public ) mais cette situation est fâcheuse, en effet, pour les personnes qui sont touchées par ce problème.

J'utilise un Samsung 840 Pro 256GB dans un Mac Pro 2010 et je n'ai jamais connu encore le moindre souci.

Edit: À propos, mon Samsung 840 Pro fonctionne tout aussi bien sous Windows 8.1

Ce message a été modifié par Kierkegaard - 22 Jun 2015, 19:18.


--------------------
« Ce n'est pas le doute, c'est la certitude qui rend fou. » Nietzsche
Go to the top of the page
 
+Quote Post
SartMatt
posté 22 Jun 2015, 19:31
Message #12


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 32 183
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (iAPX @ 22 Jun 2015, 18:36) *
Mais par défaut, OS X est safe avec les SSD tierce-partie, même si leur firmware change, pour le TRIM. À choisir, pour tout un chacun dont moi, je pense que c'est une meilleure chose et que sur la durée ça limite considérablement les risques pour les utilisateurs.
Le problème c'est qu'avec ce genre d'arguments, on fini par tout justifier...
Pour les mêmes raisons, on pourrait par exemple bloquer tous les SSD et disques durs tiers, au motif que leur implémentation du SATA pourrait être foireuse et mener à des corruption de données.
On pourrait aussi mettre des puces dans les câbles USB et bloquer ceux qui n'ont pas la puce au motif qu'un mauvais câble USB peut provoquer des corruptions de données.
On pourrait dire qu'un iPhone n'a le droit de se connecter qu'à un opérateur certifié Apple et à des bornes Wi-Fi Apple, au motif que d'autres réseaux pourraient être mal implémentés et mener à des corruption de données...
Bref, on pourrait justifier un écosystème toujours plus hermétique.

Alors que l'intérêt des protocoles standards, c'est justement de permettre à des appareils ne venant pas du même constructeur de communiquer entre eux, chacune des parties impliquées étant responsable de son côté de la bonne implémentation de ces standards.


--------------------

Go to the top of the page
 
+Quote Post
Kalm
posté 3 Jul 2015, 10:23
Message #13


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 5 195
Inscrit : 24 Aug 2010
Lieu : Saigon
Membre no 158 214



Citation (SartMatt @ 23 Jun 2015, 02:31) *
Citation (iAPX @ 22 Jun 2015, 18:36) *
Mais par défaut, OS X est safe avec les SSD tierce-partie, même si leur firmware change, pour le TRIM. À choisir, pour tout un chacun dont moi, je pense que c'est une meilleure chose et que sur la durée ça limite considérablement les risques pour les utilisateurs.
Le problème c'est qu'avec ce genre d'arguments, on fini par tout justifier...
Pour les mêmes raisons, on pourrait par exemple bloquer tous les SSD et disques durs tiers, au motif que leur implémentation du SATA pourrait être foireuse et mener à des corruption de données.
On pourrait aussi mettre des puces dans les câbles USB et bloquer ceux qui n'ont pas la puce au motif qu'un mauvais câble USB peut provoquer des corruptions de données.
On pourrait dire qu'un iPhone n'a le droit de se connecter qu'à un opérateur certifié Apple et à des bornes Wi-Fi Apple, au motif que d'autres réseaux pourraient être mal implémentés et mener à des corruption de données...
Bref, on pourrait justifier un écosystème toujours plus hermétique.

Alors que l'intérêt des protocoles standards, c'est justement de permettre à des appareils ne venant pas du même constructeur de communiquer entre eux, chacune des parties impliquées étant responsable de son côté de la bonne implémentation de ces standards.


iAPX n'a pas tout a fait tort.



Citation
The first issue is the queued TRIM implementation in Linux. It is the only operating system that tries to send FPDMA QUEUED TRIM (a new SATA II extension of NCQ, and therefore also called NCQ TRIM). The latest Samsung firmwares mistakenly set word 77 bit 6 to 1 in the ATA IDENTIFY flags, which tells the OS that they support FPDMA QUEUED operations, when they actually don't. If you try to send a FPDMA QUEUED TRIM, the latest Samsung drives spectacularly overwrite random data with zeroes. The Linux kernel now blacklists those drives from trying to use FPDMA QUEUED TRIM, since they're misbehaving with that command. The Samsung engineers are aware of it since the issue first surfaced a year ago, but a fix is not yet ready.

So if you've got a modern Samsung drive, it's important that your OS uses regular sequential TRIM. Linux is the only OS that uses queued. All versions of OS X (even El Capitan) and Windows (latest) still use sequential TRIM, and will continue to do so for the foreseeable future.

Next up... the article is actually about a bug in the Linux kernel's sequential ( non -queued) TRIM implementation.

You see... It's not just SSD firmwares that sometimes implement TRIM badly. The OS can do it wrong too, if it sends out incorrect TRIM commands that tell the SSD to delete data that's actually in use. You need the OS filesystem driver to understand the filesystem at a deep level so that it knows exactly how to properly TRIM it, and it also needs to be aware of what data is on the drive and what data is in the memory-buffered filesystem (which may be out of sync with what's on the drive), so that it knows exactly what data it will tell the SSD to delete. It's a very complex science and it even took Windows a while to get it right due to peculiarities in the NTFS filesystem. In the linked article's case, Linux is the culprit. They're talking to Linux kernel devs to get it fixed.

Since OS X and Windows use sequential TRIM, the followup questions become:

A) Does my drive implement sequential TRIM properly?
cool.gif Does the OS implement sequential TRIM properly?

For A, the answer is YES for all modern drives. But NO for *old* drives such as early SandForce controllers. *THAT* is why Apple displays the warning saying that you're enabling TRIM at your own peril. It's also the reason why Apple only allowed TRIM on their own drives initially; because back when they first implemented TRIM in OS X 10.6.8 (July of 2011), a lot of popular drives had buggy TRIM implementations - and it's better to have a slow untrimmed drive than a corrupt drive.

For B, we need to find out whether the OS sends out correct TRIM commands and doesn't send out anything that would tell the drive to delete valid data. To test this, I coded a benchmark that first writes a 50 GB verification-file (a very large file, covering a lot of SSD surface area, and whose contents can be verified to be intact later), and it then writes and deletes/TRIMS over 1000 gigabytes of data, and then pauses to let the drive perform its TRIM and garbage collection, to be sure that all the TRIM commands have been carried out. The test was executed several times on a Samsung 850 PRO SSD (same one used in the article you guys linked to), on OS X Yosemite and OS X El Capitan.

Every single bit of the 50 GB test file stayed intact, thus proving:
A) Yes, the Samsung 850 PRO with latest firmware implements old-school sequential TRIM properly.
cool.gif Yes, OS X (even El Capitan) uses *sequential* TRIM and has a proper TRIM implementation that doesn't* tell the drive to delete random valid data.

So as long as your SSD properly implements sequential TRIM (and all modern ones pretty much do, since TRIM is default in Windows and all drives want to support Windows), then you'll have zero issues with enabling TRIM in *any* version of OS X.

And do we need TRIM? Yes. The SATA TRIM command was invented to solve an extremely important need: It's the *only* way for an OS to tell an SSD to free up space from deleted files. Without TRIM, the SSD will think that *all* blocks are in use until the OS tries to overwrite them again. If all blocks are marked as in use, the SSD is literally *physically full*, and in that state it will be extremely difficult for the SSD's garbage collection to try to passively free up a bunch of empty space for new writes to take place. So all further writes will first go into the SSD's on-board buffer (that's fast), but then they'll sit there for a long time as the SSD reads, merges and re-writes data (that's extremely slow). A lack of TRIM also causes write amplification, as the SSD's garbage collection shuffles around all blocks of dead/old data from deleted files that the SSD still thinks are in use and thinks must be preserved. TRIM is the only command that can let an OS tell an SSD that the data from a deleted file is safe to delete during garbage collection. If the drive had been properly TRIM'd, the SSD would have known that most of the space is actually free, and its garbage collection would be allowed to free up those blocks in the background so that they're ready for new writes. Garbage collection is basically a process that does two things: Erase TRIM'd blocks (the primary source of freeing up space on the disk for new writes), and erase overwritten blocks that have been invalidated by new data (that's only responsible for freeing up a *tiny* amount of the storage space on an SSD). So garbage collection without TRIM is like a runner with one leg. It works (kinda), but it's crippled.


Ce message a été modifié par Kalm - 3 Jul 2015, 10:25.
Go to the top of the page
 
+Quote Post
pm13
posté 3 Jul 2015, 18:40
Message #14


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 341
Inscrit : 26 Jun 2004
Membre no 20 490



effacé

Ce message a été modifié par pm13 - 17 Jul 2015, 23:55.
Go to the top of the page
 
+Quote Post
SartMatt
posté 31 Jul 2015, 15:44
Message #15


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 32 183
Inscrit : 15 Nov 2005
Membre no 49 996



Finalement, le bug était côté noyau Linux : http://www.hardware.fr/news/14266/bug-trim...msung-html.html


--------------------

Go to the top of the page
 
+Quote Post
trouspinette
posté 31 Jul 2015, 16:00
Message #16


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 5 063
Inscrit : 19 Feb 2002
Lieu : BZH
Membre no 2 083



Tabernacle... Un drôle de sentiment quand même : depuis l’avènement des SSD, on a plus ou moins l'impression que ces ennuis étaient moins courants avec des disques "classiques".

Il convient donc d'être méga-prudent lors d'une MàJ de machines, en particulier un serveur !


--------------------
Quis custodiet ipsos custodes ? - Lorsqu'un sujet est résolu, merci d'indiquer [Résolu] dans le titre de votre post !

Luttons contre le style SMS !!!

iPhone 14Pro Max 256 Go iOS 17• MacBook Pro 16 2019 Core i9 - macOS 12.7.2 - 32 GB RAM - 2 TB • @Orange
Linux • OPNSense / pfSense • Une pointe de Windows aussi • Enfocus Switch Expert • callas pdfToolBox
Go to the top of the page
 
+Quote Post
macinoe
posté 31 Jul 2015, 17:46
Message #17


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 3 090
Inscrit : 13 Jul 2005
Membre no 42 327



Citation (SartMatt @ 22 Jun 2015, 19:31) *
Citation (iAPX @ 22 Jun 2015, 18:36) *
Mais par défaut, OS X est safe avec les SSD tierce-partie, même si leur firmware change, pour le TRIM. À choisir, pour tout un chacun dont moi, je pense que c'est une meilleure chose et que sur la durée ça limite considérablement les risques pour les utilisateurs.
Le problème c'est qu'avec ce genre d'arguments, on fini par tout justifier...



Oui, et c'est un aveux de faiblesse et d'incompétence.

On ne sait pas faire donc on ne fait pas.

En tout cas par rapport à windows et son support d'absolument tout les matériels possibles et imaginable.

Ce message a été modifié par macinoe - 31 Jul 2015, 17:47.
Go to the top of the page
 
+Quote Post
Kierkegaard
posté 31 Jul 2015, 21:00
Message #18


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 6 478
Inscrit : 11 Feb 2008
Lieu : Made in Quebec
Membre no 107 488



Citation (SartMatt @ 31 Jul 2015, 10:44) *
Finalement, le bug était côté noyau Linux : http://www.hardware.fr/news/14266/bug-trim...msung-html.html

On a donc faussement accusé et dénigré les SSD Samsung d'être responsables d'un bug du Trim alors que le vrai coupable était du côté du noyau Linux.

Ce message a été modifié par Kierkegaard - 31 Jul 2015, 21:08.


--------------------
« Ce n'est pas le doute, c'est la certitude qui rend fou. » Nietzsche
Go to the top of the page
 
+Quote Post
Kalm
posté 31 Jul 2015, 22:04
Message #19


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 5 195
Inscrit : 24 Aug 2010
Lieu : Saigon
Membre no 158 214



Citation (Kierkegaard @ 1 Aug 2015, 04:00) *
Citation (SartMatt @ 31 Jul 2015, 10:44) *
Finalement, le bug était côté noyau Linux : http://www.hardware.fr/news/14266/bug-trim...msung-html.html

On a donc faussement accusé et dénigré les SSD Samsung d'être responsables d'un bug du Trim alors que le vrai coupable était du côté du noyau Linux.


C'est pas suffisant pour se racheter une conduite.^^
Go to the top of the page
 
+Quote Post
Suricate15
posté 31 Jul 2015, 23:02
Message #20


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 302
Inscrit : 16 Dec 2013
Membre no 188 324



Citation (trouspinette @ 31 Jul 2015, 17:00) *
Tabernacle... Un drôle de sentiment quand même : depuis l’avènement des SSD, on a plus ou moins l'impression que ces ennuis étaient moins courants avec des disques "classiques".

Il convient donc d'être méga-prudent lors d'une MàJ de machines, en particulier un serveur !

Les technos des disques durs classiques ont plusieurs décennies d'expérience derrière elles.. les problèmes sont dans la quasi-totalité, d'ordre mécanique. Ce n'est pas le cas des SSD, techno nouvelle et prometteuse mais où les architectures et l'organisation des mémoires donc aussi les firmwares associés peuvent grandement varier d'un fabricant à l'autre. A la "sortie" ils semblent tous identiques, à l'intérieur ils ne le sont pas du tout. Ceci pourrait expliquer cela ?

En informatique il n'y a qu'une règle qui soit vraie dans tous les cas de figures : la fiabilité à 100% n'existe pas, il faut vraiment en avoir conscience et agir en conséquence.

Ce message a été modifié par Suricate15 - 31 Jul 2015, 23:03.


--------------------
« La perfection des moyens et la confusion des buts semblent caractériser notre époque. » A. Einstein.
Go to the top of the page
 
+Quote Post
iAPX
posté 31 Jul 2015, 23:11
Message #21


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 15 371
Inscrit : 4 Jan 2006
Lieu : dtq
Membre no 52 877



C'est une bonne nouvelle pour ceux sous Linux, enfin dès que le patch arrivera dans les distros utilisées!

C'est aussi une bonne nouvelle pour Samsung, avec les nombreux problèmes de certains de ces SSD, qui sont parmi les plus vendus, et avec une vitesse de réaction extrêmement mauvaise. Pour cela que ce mois-ci j'ai acheté un SSD 1To, mais pas chez Samsung!

Aussi une très bonne nouvelle pour ceux qui comme moi sont sous OS X, mais qui ont un SSD Samsung, et envie d'utiliser le TRIM, car là ça libère d'un poids, et ça va bien avec les nouvelles de ces dernières semaines permettant d'activer le TRIM sur les SSD tierce-partie sans désactiver les sécurités d'OS X. Carte blanche! wink.gif


--------------------
Utilisateur de Mac depuis 1985 et possesseur de Mac depuis 2005. Utilisateur d'un PC Lenovo au travail, sous Windows, qui renforce ma passion pour les Mac!
Go to the top of the page
 
+Quote Post
Kierkegaard
posté 1 Aug 2015, 00:04
Message #22


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 6 478
Inscrit : 11 Feb 2008
Lieu : Made in Quebec
Membre no 107 488



Citation (Kalm @ 31 Jul 2015, 17:04) *
Citation (Kierkegaard @ 1 Aug 2015, 04:00) *
Citation (SartMatt @ 31 Jul 2015, 10:44) *
Finalement, le bug était côté noyau Linux : http://www.hardware.fr/news/14266/bug-trim...msung-html.html

On a donc faussement accusé et dénigré les SSD Samsung d'être responsables d'un bug du Trim alors que le vrai coupable était du côté du noyau Linux.


C'est pas suffisant pour se racheter une conduite.^^

Si ça peut te consoler, j'ai reçu aujourd'hui par la poste un Crucial MX 200 1 To, tout ça pour dire que je ne suis pas un inconditionnel des produits Samsung. ;-)


--------------------
« Ce n'est pas le doute, c'est la certitude qui rend fou. » Nietzsche
Go to the top of the page
 
+Quote Post
blueG3
posté 1 Aug 2015, 11:48
Message #23


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 3 810
Inscrit : 20 Nov 2001
Lieu : vitry sur seine (94)
Membre no 1 346



Citation (Kierkegaard @ 31 Jul 2015, 22:00) *
Citation (SartMatt @ 31 Jul 2015, 10:44) *
Finalement, le bug était côté noyau Linux : http://www.hardware.fr/news/14266/bug-trim...msung-html.html

On a donc faussement accusé et dénigré les SSD Samsung d'être responsables d'un bug du Trim alors que le vrai coupable était du côté du noyau Linux.


bonjour ,
il faut je pense bien préciser les choses ,
les SSD Samsung serie 840 ont connu pas mal de déboire dans leur gestion firmware , au point que cela a débordé sur la partie Filesystem.
or je prends les paris que le FS utilisé est le F2FS pour les SSD provenant de Samsung.
si linux essaye au mieux d'exploiter le trim SSD ok , si par contre cela provient de séries SSD /Firmware peu fiable dans le temps , c'est pas la premiers fois que linux révèle les dysfonctionnements du matériel.
s'il y a un correctif linux c'est juste pour le materiel SSD de samsung ... car ils fonctionnent très bien avec tous les autres marques.

a l'heure actuelle , je ne recommanderai pas les Samsung serie 840 et 850 , car batis tous sur la meme technologie.
le firmware fera sont possibe avec , mais quand les problèmes d'erreurs de lectures / écritures reviendront en cascade , cela va être bien compliqué a géré par la suite pour Samsung


--------------------
macpro 2008 quad core +8Go + 8800GT merci Nvidia & Apple pour la qualité et le choix de la carte! => ATI 5770 Apple + 2 DD WD 640Go + 2 SSD M4 Crucial 512Go(Raid 0) et Snow Leopard 10.6.8 + LG IPS235 flatron + Manjaro Linux sur DD interne - 23.1 Maté
Desktop - CPU : AMD Ryzen 3600XT@4,6Ghz - RAM 16 Go - CM: Gygabyte X570-Aorus Pro CG : GeForce GTX 970- Audio: AMD Starship/Matisse HD Manjaro 23.1 xfce (testing)
Go to the top of the page
 
+Quote Post
SartMatt
posté 1 Aug 2015, 12:00
Message #24


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 32 183
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (blueG3 @ 1 Aug 2015, 12:48) *
s'il y a un correctif linux c'est juste pour le materiel SSD de samsung ... car ils fonctionnent très bien avec tous les autres marques.
Non. Pour ce problème de TRIM le correctif fourni par Samsung concerne un bug dans la gestion du TRIM dans le cas d'un RAID soft, et ça concerne tous les SSD, pas seulement les SSD Samsung.

Cf les explications et le code du correctif ici : http://www.spinics.net/lists/raid/msg49440.html (on voit notamment que dans le code du correctif il n'y a nulle part de test sur la marque ou le modèle du SSD).

Algolia, qui avait détecté le problème et avait initialement mis en cause Samsung a collaboré avec Samsung pour identifier le problème, et a depuis mis à jour son article en reconnaissant que ce n'est pas spécifiquement les SSD Samsung qui posent problème : https://blog.algolia.com/when-solid-state-d...not-that-solid/


--------------------

Go to the top of the page
 
+Quote Post
Kierkegaard
posté 1 Aug 2015, 14:20
Message #25


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 6 478
Inscrit : 11 Feb 2008
Lieu : Made in Quebec
Membre no 107 488



Citation (blueG3 @ 1 Aug 2015, 06:48) *
Citation (Kierkegaard @ 31 Jul 2015, 22:00) *
Citation (SartMatt @ 31 Jul 2015, 10:44) *
Finalement, le bug était côté noyau Linux : http://www.hardware.fr/news/14266/bug-trim...msung-html.html

On a donc faussement accusé et dénigré les SSD Samsung d'être responsables d'un bug du Trim alors que le vrai coupable était du côté du noyau Linux.

bonjour ,
il faut je pense bien préciser les choses ,
les SSD Samsung serie 840 ont connu pas mal de déboire dans leur gestion firmware , au point que cela a débordé sur la partie Filesystem.
or je prends les paris que le FS utilisé est le F2FS pour les SSD provenant de Samsung.
si linux essaye au mieux d'exploiter le trim SSD ok , si par contre cela provient de séries SSD /Firmware peu fiable dans le temps , c'est pas la premiers fois que linux révèle les dysfonctionnements du matériel.
s'il y a un correctif linux c'est juste pour le materiel SSD de samsung ... car ils fonctionnent très bien avec tous les autres marques.

a l'heure actuelle , je ne recommanderai pas les Samsung serie 840 et 850 , car batis tous sur la meme technologie.
le firmware fera sont possibe avec , mais quand les problèmes d'erreurs de lectures / écritures reviendront en cascade , cela va être bien compliqué a géré par la suite pour Samsung

Je pense avoir bien précisé que les SSD Samsung ont été faussement accusés d'être à l'origine d'un bug du Trim. Quant aux soucis qu'ils ont rencontrés avec la gestion de leur firmware, c'est une autre histoire.


--------------------
« Ce n'est pas le doute, c'est la certitude qui rend fou. » Nietzsche
Go to the top of the page
 
+Quote Post
blueG3
posté 1 Aug 2015, 15:08
Message #26


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 3 810
Inscrit : 20 Nov 2001
Lieu : vitry sur seine (94)
Membre no 1 346



Citation (SartMatt @ 1 Aug 2015, 13:00) *
Citation (blueG3 @ 1 Aug 2015, 12:48) *
s'il y a un correctif linux c'est juste pour le matériel SSD de samsung ... car ils fonctionnent très bien avec tous les autres marques.
Non. Pour ce problème de TRIM le correctif fourni par Samsung concerne un bug dans la gestion du TRIM dans le cas d'un RAID soft, et ça concerne tous les SSD, pas seulement les SSD Samsung.

Cf les explications et le code du correctif ici : http://www.spinics.net/lists/raid/msg49440.html (on voit notamment que dans le code du correctif il n'y a nulle part de test sur la marque ou le modèle du SSD).

Algolia, qui avait détecté le problème et avait initialement mis en cause Samsung a collaboré avec Samsung pour identifier le problème, et a depuis mis à jour son article en reconnaissant que ce n'est pas spécifiquement les SSD Samsung qui posent problème : https://blog.algolia.com/when-solid-state-d...not-that-solid/


alors en plus des SSD , c'est surtout raid0 et combinaison raid 10 qui ont sont concernés uniquement pour les SSD ( pas les DD ni SCSI)

de plus Aloglia avait bien indiqué que cela ne s’était pas produit pour les autres modèles SSD, ce qui pouvait laisser penser que seuls les modeles 840/850 Samsung étaient concernés.


--------------------
macpro 2008 quad core +8Go + 8800GT merci Nvidia & Apple pour la qualité et le choix de la carte! => ATI 5770 Apple + 2 DD WD 640Go + 2 SSD M4 Crucial 512Go(Raid 0) et Snow Leopard 10.6.8 + LG IPS235 flatron + Manjaro Linux sur DD interne - 23.1 Maté
Desktop - CPU : AMD Ryzen 3600XT@4,6Ghz - RAM 16 Go - CM: Gygabyte X570-Aorus Pro CG : GeForce GTX 970- Audio: AMD Starship/Matisse HD Manjaro 23.1 xfce (testing)
Go to the top of the page
 
+Quote Post
SartMatt
posté 1 Aug 2015, 15:36
Message #27


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 32 183
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (blueG3 @ 1 Aug 2015, 16:08) *
alors en plus des SSD , c'est surtout raid0 et combinaison raid 10 qui ont sont concernés uniquement pour les SSD ( pas les DD ni SCSI)
Les grappes SCSI sont également concernés, quand la commande UNMAP est utilisée (l'équivalent du TRIM en SCSI).

Citation (blueG3 @ 1 Aug 2015, 16:08) *
de plus Aloglia avait bien indiqué que cela ne s’était pas produit pour les autres modèles SSD, ce qui pouvait laisser penser que seuls les modeles 840/850 Samsung étaient concernés.
Sur le fil de discussion de la mailing-list linux-raid, il y a une explication au fait que certains SSD ne soient pas concernés : http://www.spinics.net/lists/raid/msg49488.html

Si j'ai bien compris, le problème se produit quand au moins trois TRIM sont traités à la suite et que l'OS commence à traiter le troisième alors que le SSD n'a pas encore reçu le second : le traitement du troisième TRIM au niveau de l'OS va aller écraser une partie des paramètres du second, et donc ce ne sont pas les bons paramètres qui vont être envoyés au second. Et du coup, selon la vitesse à laquelle le SSD traite les TRIM, le problème peut ne pas se produire, car la seconde requête est alors envoyée au SSD avant que l'OS commence à traiter la troisième.

On peut d'ailleurs voir que les trois SSD sur lesquels Algolia n'a pas reproduit le problème sont des SSD pour datacenter, qui sont probablement capables de traiter ces opérations plus rapidement que des SSD grand public (parce que bon, les Samsung 840 Pro/850 Pro, même s'il y a Pro dans le nom, ça reste des modèles grand public et éventuellement station de travail, pas datacenter...).


--------------------

Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 utilisateur(s) sur ce sujet (1 invité(s) et 0 utilisateur(s) anonyme(s))
0 membre(s) :

 



Nous sommes le : 29th March 2024 - 02:40