Linux: Un bug du Trim sur les SSD Samsung provoque une corruption des données, Réactions à la publication du 22/06/2015 |
Bienvenue invité ( Connexion | Inscription )
Linux: Un bug du Trim sur les SSD Samsung provoque une corruption des données, Réactions à la publication du 22/06/2015 |
21 Jun 2015, 23:00
Message
#1
|
|
BIDOUILLE Guru Groupe : Admin Messages : 55 352 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
|
|
|
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. |
|
|
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.
Ce message a été modifié par blacksmith - 22 Jun 2015, 02:22. |
|
|
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 -------------------- 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 |
|
|
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…
|
|
|
22 Jun 2015, 08:56
Message
#6
|
|
Adepte de Macbidouille Groupe : Membres Messages : 138 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) |
|
|
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. |
|
|
22 Jun 2015, 12:19
Message
#8
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 15 386 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!
|
|
|
22 Jun 2015, 15:34
Message
#9
|
|
BIDOUILLE Guru Groupe : Admin Messages : 55 352 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
|
|
|
22 Jun 2015, 17:36
Message
#10
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 15 386 Inscrit : 4 Jan 2006 Lieu : dtq Membre no 52 877 |
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!
|
|
|
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 |
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
|
|
|
22 Jun 2015, 19:31
Message
#12
|
|
Macbidouilleur d'Or ! Groupe : Rédacteurs Messages : 32 193 Inscrit : 15 Nov 2005 Membre no 49 996 |
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. -------------------- |
|
|
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 |
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? 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. 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. |
|
|
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. |
|
|
31 Jul 2015, 15:44
Message
#15
|
|
Macbidouilleur d'Or ! Groupe : Rédacteurs Messages : 32 193 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
-------------------- |
|
|
31 Jul 2015, 16:00
Message
#16
|
|
Macbidouilleur d'Or ! Groupe : Rédacteurs Messages : 5 064 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 |
|
|
31 Jul 2015, 17:46
Message
#17
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 3 090 Inscrit : 13 Jul 2005 Membre no 42 327 |
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. |
|
|
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 |
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
|
|
|
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 |
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.^^ |
|
|
31 Jul 2015, 23:02
Message
#20
|
|
Macbidouilleur de bronze ! Groupe : Membres Messages : 302 Inscrit : 16 Dec 2013 Membre no 188 324 |
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.
|
|
|
31 Jul 2015, 23:11
Message
#21
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 15 386 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! -------------------- 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!
|
|
|
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 |
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
|
|
|
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 |
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 +
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) |
|
|
1 Aug 2015, 12:00
Message
#24
|
|
Macbidouilleur d'Or ! Groupe : Rédacteurs Messages : 32 193 Inscrit : 15 Nov 2005 Membre no 49 996 |
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/ -------------------- |
|
|
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 |
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
|
|
|
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 |
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 +
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) |
|
|
1 Aug 2015, 15:36
Message
#27
|
|
Macbidouilleur d'Or ! Groupe : Rédacteurs Messages : 32 193 Inscrit : 15 Nov 2005 Membre no 49 996 |
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).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.htmlSi 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...). -------------------- |
|
|
Nous sommes le : 13th May 2024 - 11:08 |