Bon, on y va pour les coléoptères. Du logiciel, y'en a partout, même dans ton CPU Intel, il y a du microcode, c'est à dire du logiciel. Reste qu'à un moment, il faut bien tracer des limites entre les composants "matériels" et "logiciels" d'un ordinateur.
Même si ton CPU contient du logiciel (le microcode), tu seras d'accord pour admettre qu'il est complètement distinct du code de l'OS. Je peux changer d'OS (par exemple passer de Linux à FreeBSD), sans toucher au microcode de mon CPU. Je peux même même coder un OS sans avoir conscience du fait que le CPU utilise du microcode, parce que les OS utilisent une interface, en l'occurence l'ISA x86 dans le cas des CPU Intel, avec le CPU. On utilise généralement cette interface pour tracer la limite entre le logiciel et le matériel. Ce qui implémente l'interface, ici l'ISA x86 (le CPU) c'est du matériel, et ce qui utilise l'interface (l'OS), c'est du logiciel.
Pour revenir aux cas des mémoires flash et SSD, tu mélanges tout, vraiment tout. Un SSD, d'un point de vue interface, ce n'est pas de la mémoire flash. Un SSD, ça répond à des commandes SATA (qui constituent son interface), comme un disque dur classique. Et quand une commande SATA te demande de stocker un cluster, t'es censé le stocker de manière à peu près fiable (c'est à dire pas sous une forme qui disparaisse en deux semaines). Pour reprendre les concepts du paragraphe précédent, l'interface entre matériel (le SSD) et le logiciel (le filesystem), c'est les commandes SATA. Les filesystem classiques (ext2-3-4, xfs etc.) utilisent les commandes SATA, et le SSD implémente les commandes SATA. Donc dans le cas d'un SSD, tout ce qui est "gestion de la flash" (wear-leveling, gestion des cellules de mémoire) c'est implémenté en matériel. Parler du filesystem d'un SSD, ça ne veut rien dire, parce qu'on peut utiliser n'importe quel filesystem sur un SSD. C'est un peu comme parler de l'OS d'un processeur, ça n'a pas de sens.
Pour ne rien simplifier, il existe d'autres périphériques de stockages basés sur de la mémoire flash que les SSD, les MTD. l'interface entre matériel (la MTD) et le logiciel (le filesystem), ce n'est pas les commandes SATA. Ils implémentent une interface plus bas niveau pour le logiciel, ils exposent quasiment directement leurs cellules mémoires. C'est au logiciel, donc au filesystem d'effectuer la "gestion de la flash" (wear-leveling, gestion des cellules de mémoire). Des filesystem spécifiques ont étés développés pour les MTD : jffs2, ubifs, yaffs etc. On ne peut pas les utiliser sur un disque dur ni sur un SSD, parce qu'ils n'utilisent pas l'interface SATA mais une interface plus bas niveau spécifique aux MTD.
Pour encore plus complexifier, l'interface SATA (donc celle dont je parle deux paragraphes plus haut) a été un peu modifiée pour répondre aux besoins spécifiques des SSD (ben oui, c'est pas exactement la même chose qu'un disque dur même si on a pas eu envie de changer d'interface), c'est notamment le cas de la commande TRIM. F2FS est un filesystem utilisant l'interface SATA ainsi que les extensions pour les SSD (notamment TRIM). Il essaye aussi d'utiliser l'interface SATA de manière "accomodante" pour un SSD. Mais ça reste un filesystem utilisant l'interface SATA, donc pas pour les MTD.
Tout ça étant dit, je ré-insiste sur ma conclusion, parler du système de fichiers d'un SSD, ça n'a pas de sens ni même de "le logiciel de gestion du filesystem". Et ici, on parle bien d'un problème matériel, c'est bien au SSD de s'arranger pour qu'un cluster stocké ne soit pas perdu (un SSD n'est pas une MTD).
[^] # Re: F2FS ?
Posté par X345 . En réponse au journal SSD Samsung 840: le fiasco annoncé du TLC ?. Évalué à 10.
Bon, on y va pour les coléoptères. Du logiciel, y'en a partout, même dans ton CPU Intel, il y a du microcode, c'est à dire du logiciel. Reste qu'à un moment, il faut bien tracer des limites entre les composants "matériels" et "logiciels" d'un ordinateur.
Même si ton CPU contient du logiciel (le microcode), tu seras d'accord pour admettre qu'il est complètement distinct du code de l'OS. Je peux changer d'OS (par exemple passer de Linux à FreeBSD), sans toucher au microcode de mon CPU. Je peux même même coder un OS sans avoir conscience du fait que le CPU utilise du microcode, parce que les OS utilisent une interface, en l'occurence l'ISA x86 dans le cas des CPU Intel, avec le CPU. On utilise généralement cette interface pour tracer la limite entre le logiciel et le matériel. Ce qui implémente l'interface, ici l'ISA x86 (le CPU) c'est du matériel, et ce qui utilise l'interface (l'OS), c'est du logiciel.
Pour revenir aux cas des mémoires flash et SSD, tu mélanges tout, vraiment tout. Un SSD, d'un point de vue interface, ce n'est pas de la mémoire flash. Un SSD, ça répond à des commandes SATA (qui constituent son interface), comme un disque dur classique. Et quand une commande SATA te demande de stocker un cluster, t'es censé le stocker de manière à peu près fiable (c'est à dire pas sous une forme qui disparaisse en deux semaines). Pour reprendre les concepts du paragraphe précédent, l'interface entre matériel (le SSD) et le logiciel (le filesystem), c'est les commandes SATA. Les filesystem classiques (ext2-3-4, xfs etc.) utilisent les commandes SATA, et le SSD implémente les commandes SATA. Donc dans le cas d'un SSD, tout ce qui est "gestion de la flash" (wear-leveling, gestion des cellules de mémoire) c'est implémenté en matériel. Parler du filesystem d'un SSD, ça ne veut rien dire, parce qu'on peut utiliser n'importe quel filesystem sur un SSD. C'est un peu comme parler de l'OS d'un processeur, ça n'a pas de sens.
Pour ne rien simplifier, il existe d'autres périphériques de stockages basés sur de la mémoire flash que les SSD, les MTD. l'interface entre matériel (la MTD) et le logiciel (le filesystem), ce n'est pas les commandes SATA. Ils implémentent une interface plus bas niveau pour le logiciel, ils exposent quasiment directement leurs cellules mémoires. C'est au logiciel, donc au filesystem d'effectuer la "gestion de la flash" (wear-leveling, gestion des cellules de mémoire). Des filesystem spécifiques ont étés développés pour les MTD : jffs2, ubifs, yaffs etc. On ne peut pas les utiliser sur un disque dur ni sur un SSD, parce qu'ils n'utilisent pas l'interface SATA mais une interface plus bas niveau spécifique aux MTD.
Pour encore plus complexifier, l'interface SATA (donc celle dont je parle deux paragraphes plus haut) a été un peu modifiée pour répondre aux besoins spécifiques des SSD (ben oui, c'est pas exactement la même chose qu'un disque dur même si on a pas eu envie de changer d'interface), c'est notamment le cas de la commande TRIM. F2FS est un filesystem utilisant l'interface SATA ainsi que les extensions pour les SSD (notamment TRIM). Il essaye aussi d'utiliser l'interface SATA de manière "accomodante" pour un SSD. Mais ça reste un filesystem utilisant l'interface SATA, donc pas pour les MTD.
Tout ça étant dit, je ré-insiste sur ma conclusion, parler du système de fichiers d'un SSD, ça n'a pas de sens ni même de "le logiciel de gestion du filesystem". Et ici, on parle bien d'un problème matériel, c'est bien au SSD de s'arranger pour qu'un cluster stocké ne soit pas perdu (un SSD n'est pas une MTD).