Il y a aussi les "log-structured filesystems". L'idée est simple : toutes les écritures (data et metadata) sont faites dans un flux ininterrompu. L'effort est reporté sur la lecture, car trouver une donnée peut être assez compliqué dans un tel schéma. Il faut par ailleurs garbage-collecter en arrière-plan le flux (le log) pour retrouver de la place. Il existe des implémentations plus ou moins prototypales pour BSD et Linux, sous le nom de LFS (cf http://collective.cpoint.net/prof/lfs/(...) pour Linux). D'habitude, on lit plus souvent qu'on écrit sur un filesystem, mais ce n'est pas le cas de ce qui est dans /var/log/, où les LFS peuvent être pratiques. L'usage des LFS est quand même marginal.
(c'est moi qui souligne).
On peut donc considérer que LFS est plus une curiosité qu'un vrai FS robuste utilisable en prod.
[^] # Re: utilitaire de partionnement à revoir
Posté par patrick_g (site web personnel) . En réponse au journal A la découverte de NetBSD/i386. Évalué à 3.
Il y a aussi les "log-structured filesystems". L'idée est simple : toutes les écritures (data et metadata) sont faites dans un flux ininterrompu. L'effort est reporté sur la lecture, car trouver une donnée peut être assez compliqué dans un tel schéma. Il faut par ailleurs garbage-collecter en arrière-plan le flux (le log) pour retrouver de la place. Il existe des implémentations plus ou moins prototypales pour BSD et Linux, sous le nom de LFS (cf http://collective.cpoint.net/prof/lfs/(...) pour Linux). D'habitude, on lit plus souvent qu'on écrit sur un filesystem, mais ce n'est pas le cas de ce qui est dans /var/log/, où les LFS peuvent être pratiques. L'usage des LFS est quand même marginal.
(c'est moi qui souligne).
On peut donc considérer que LFS est plus une curiosité qu'un vrai FS robuste utilisable en prod.