Oui .. en effet, sauf que ... On se base sur le format on-flash de UBIFS (et pas forcément avec UBI en dessous, mais la conversion est triviale avec EBM).
Donc, il y'aura de quoi lire.
En fait, pour faire un peu plus technique, uffs c'est:
- Un port de UBIFS en userspace sous linux, avec fuse
- Un port de UBIFS en userspace sous windows avec dokan
- Un futur port sous WinCE (kernelspace)
- Un futur port sous Windows (kernelspace)
L'intérêt ? UBIFS est fait pour être conscient des caractéristiques de la mémoire flash: taille minimale d'IO, taille d'un erase block, limitation des écritures/effacements, wear leveling (via UBI en fait).
Du coups, on fait une couche plus générique qu'UBI, qui peut gérer aussi les périphériques (sans wear leveling, ou avec, au choix). Mais on conserve les bonnes pratiques imposées par UBIFS (pas d'écritures plus petites que la taille d'io minimale, on essait d'écrire erase block par erase block).
Voila, pour plus de détails, allez faire un tour sur le site web !
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par Corentin Chary . En réponse au journal Unified Flash File System. Évalué à 9.
Donc, il y'aura de quoi lire.
En fait, pour faire un peu plus technique, uffs c'est:
- Un port de UBIFS en userspace sous linux, avec fuse
- Un port de UBIFS en userspace sous windows avec dokan
- Un futur port sous WinCE (kernelspace)
- Un futur port sous Windows (kernelspace)
L'intérêt ? UBIFS est fait pour être conscient des caractéristiques de la mémoire flash: taille minimale d'IO, taille d'un erase block, limitation des écritures/effacements, wear leveling (via UBI en fait).
Du coups, on fait une couche plus générique qu'UBI, qui peut gérer aussi les périphériques (sans wear leveling, ou avec, au choix). Mais on conserve les bonnes pratiques imposées par UBIFS (pas d'écritures plus petites que la taille d'io minimale, on essait d'écrire erase block par erase block).
Voila, pour plus de détails, allez faire un tour sur le site web !