Il ne me semble pas que ce soit rédhibitoire: l'effacement d'un bloc ne nécessite pas de transmettre des données:
On lit et on écrit des blocs de taille fixe, par exemple 4Ko, les systèmes de fichier aiment bien ça (Un rapide parcours de la norme SATA 1 semble dire que l'on pourrait échanger des paquets jusqu'à 8Ko). Pour l'écriture, les CRCs des SSD ne sont probablement pas fait sur de plus gros blocs vu qu'ils travaillent déjà comme cela.
On envoi une commande d'effacement de macro-bloc lorsqu'on veut faire du ménage. Un peu comme la commande TRIM mais avec une grosse granularité.
Si on veut faire le wear leveling au niveau de l'OS, on peut aussi définir des commandes qui vont remonter le nombre d'usage de chaque cellule. Certains SSD le font déjà.
La question à laquelle je répondais portait sur le multiplexage des requêtes; en particulier pouvoir lancer un ordre d'effacement ou une écriture, opérations un peu lente, tout en continuant à faire des lectures. Et le NCQ permet déjà de lancer plusieurs requêtes en parallèle. (Au passage la norme 3.1 permet maintenant de faire un TRIM sans vider la queue).
[^] # Re: Bureau ok
Posté par Sébastien Koechlin . En réponse au journal Les SSD. Évalué à 4.
Il ne me semble pas que ce soit rédhibitoire: l'effacement d'un bloc ne nécessite pas de transmettre des données:
Si on veut faire le wear leveling au niveau de l'OS, on peut aussi définir des commandes qui vont remonter le nombre d'usage de chaque cellule. Certains SSD le font déjà.
La question à laquelle je répondais portait sur le multiplexage des requêtes; en particulier pouvoir lancer un ordre d'effacement ou une écriture, opérations un peu lente, tout en continuant à faire des lectures. Et le NCQ permet déjà de lancer plusieurs requêtes en parallèle. (Au passage la norme 3.1 permet maintenant de faire un TRIM sans vider la queue).