Holala, je n'ai pas de document "sérieux" à te fournir, mais c'est justement le manque de documents sur tous les périphériques de type bloc (Clés USB, carte SD, disque SSD) et puis pleins d'articles que j'ai lu qui me font dire que ça ne sert absolument à rien de vouloir contrer ce que fait la FTL. UBI et consort sont faits pour des périphériques MTD, et c'est tout.
Un périphérique bloc sous linux apparaît comme ayant des secteurs de 512 octets, ce n'est pas pour être "vaguement compatible" (comme écrit en dessous), c'est parce que c'est le _fondement_ même d'un périphérique de type bloc ! Tout le système des block io de linux et des autres OS est basé sur cette assomption.
Ensuite, tu n'as aucun contrôle sur comment est géré le cache, l'écriture, etc. de tes blocs derrière, à moins de tripatouiller dans le système de gestion de périphs bloc du kernel.
Pour tes valeurs d'erase block, de taille de page et autre, tu dis du "vachement souvent" ou "normalement" : déjà, la quasi totalité des constructeurs ne communiquent pas dessus, et les seuls que j'ai pu voir étaient tous différents.
Et de toute façon, comment sais-tu de quelle façon va gérer la FTL derrière ? Peut-être qu'elle flush tout à chaque écriture d'un bloc (= effacement d'un erase block qqpart, récriture du contenu en entier + tes nouvelles données .... super efficace ; je soupçonne les clés USB de faire ça, vu leur durée de vie), ou alors peut-être est-elle plus "intelligente", mais comment va se comporter ton algo avec ça ?
Bref, je ne comprend pas vraiment l'utilité du truc si vous (j'ai cru comprendre que tu faisais également partie du projet) n'avez pas au moins une connaissance solide de ce sur quoi vous bossez.
Voilà, tout ça sans parler du "problème", si votre objectif est de faire quelque chose qui marche partout (vu que vous faites du windows aussi, je suppose que c'est un peu votre objectif) d'arriver à avoir un format assez répandu pour être lu de manière pratique sur beaucoup de machines ...
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par benoar . En réponse au journal Unified Flash File System. Évalué à 4.
Un périphérique bloc sous linux apparaît comme ayant des secteurs de 512 octets, ce n'est pas pour être "vaguement compatible" (comme écrit en dessous), c'est parce que c'est le _fondement_ même d'un périphérique de type bloc ! Tout le système des block io de linux et des autres OS est basé sur cette assomption.
Ensuite, tu n'as aucun contrôle sur comment est géré le cache, l'écriture, etc. de tes blocs derrière, à moins de tripatouiller dans le système de gestion de périphs bloc du kernel.
Pour tes valeurs d'erase block, de taille de page et autre, tu dis du "vachement souvent" ou "normalement" : déjà, la quasi totalité des constructeurs ne communiquent pas dessus, et les seuls que j'ai pu voir étaient tous différents.
Et de toute façon, comment sais-tu de quelle façon va gérer la FTL derrière ? Peut-être qu'elle flush tout à chaque écriture d'un bloc (= effacement d'un erase block qqpart, récriture du contenu en entier + tes nouvelles données .... super efficace ; je soupçonne les clés USB de faire ça, vu leur durée de vie), ou alors peut-être est-elle plus "intelligente", mais comment va se comporter ton algo avec ça ?
Bref, je ne comprend pas vraiment l'utilité du truc si vous (j'ai cru comprendre que tu faisais également partie du projet) n'avez pas au moins une connaissance solide de ce sur quoi vous bossez.
Voilà, tout ça sans parler du "problème", si votre objectif est de faire quelque chose qui marche partout (vu que vous faites du windows aussi, je suppose que c'est un peu votre objectif) d'arriver à avoir un format assez répandu pour être lu de manière pratique sur beaucoup de machines ...