Imprimer Envoyer 6 Réactions 368 Approbations 

SSD Intel : retour du firmware "TRIM" mais pas de la SSD Toolbox

Publié le 02 décembre 2009 , par Florian Vieru - mis à jour le 02 décembre 2009 à 10h - dans Hardware, Stockage - Mots clés : Intel, X25-M, 34 nm, MLC, NAND, mémoire flash, firmware, Disque flash

Intel vient de publier un nouveau firmware pour son disque flash X25-M Postville, avec de la NAND MLC gravée à 34 nanomètres...

>> Retour à l'article <<

Comparer les prix de

Réactions


alphaonex86 - le 02/12/09 à 10:20
Moi je dit, vive linux, on as même des fs spécialisé pour le flash :)
Elbereth - le 02/12/09 à 10:40
Bon bah je suis en plein dans les 4 critères... J'install ce firmware direct ce soir. J'ai pas encore eu de problèmes mais je préfère pas tenter le diable.

alphaonex86> Qu'il ne faut absolument pas utilisé sur un SSD... Les FS pour flash comme JFFS sont prévu pour fonctionné directement sur la flash. Le SSD emule un bloc device et s'occupe de tout ce qui est wear leveling, etc...
Farfy - le 02/12/09 à 11:54
Tu peux développer Elbereth SVP? Ca a l'air super intéressant ton discours sur les FS pour flash utilisé par Linux (en privé, à moins que cela intéresse aussi d'autres personnes).
k stor - le 02/12/09 à 12:53
ça intéresse d'autres personnes
fitfat - le 02/12/09 à 13:34
En gros, les SSD gèrent en interne toutes les fonctionnalités offertes par les FS spécialisés.
En fait, les seuls FS "optimisés" pour les SSD sont ceux qui n'offre pas de journalisation et qui limitent les données statistiques au strict minimum.
Elbereth - le 03/12/09 à 13:51
Je ne suis pas un expert, mais j'avais un peu regardé avant de me lancer dans les SSD.

Comme le dit fitfat, les FS spécialisés pour la flash (UBIFS, JFFS2, etc..) sont fait pour fonctionner directement sur de la flash (donc des blocs de 16ko à 128Ko par ex). C'est alors le File System qui va gérer le wear leveling, le fait d'éviter d'écrire de trop petites quantités de données, l'organisation des données dans la flash, etc...

Alors qu'un SSD est détecté par l'OS comme un disque dur standard. Le controleur du SSD gère alors tout ce qui est en rapport avec la Flash tout seul (agencement des données, wear leveling, etc..). Ce n'est dailleurs pas parce qu'on "voit" les données toujours au même endroit (MFT, Journal, etc..) que les données sont toujours dans les mêmes cellules flash...

Petite précision, il me semble dailleurs que les FS pour Flash ne sont pas utilisable sur un bloc device il faut forcement que le controleur flash soit accessible. Ce qui est rarement/jamais le cas sur les clés USB/SSD. Même si c'était possible se serais assez dangereux puisque accéder directement à la flash condamnerais à ne plus jamais utiliser l'accès via bloc device sous peine de foutre un bordel monstre.

Concernant les FS optimisés SSD, le fait d'avoir un journal n'est pas très grave pour un SSD et ça augmente quand même fortement la fiabilité d'un FS (c'est pas pour rien que tous les FS modernes sont journalisés). Par contre sous Linux désactivez le access time (noatime dans fstab), sinon a chaque accès de fichier on fait une écriture sur le SSD. C'était déjà conseillé de le désactivé sur les HDD pour des questions de perfs, mais pour les SSD c'est aussi pour éviter trop d'écritures.

J'espère que je n'ai pas dit trop de conneries... wink
Les commentaires sur ce document sont clos.
  • Tout
  • Hi-Tech
  • Matériel
  • Mac
  • Jeux
Participez !