C'est évident qu'il y a un travail à faire, en particulier pour les entreprises qui manipulent des disques à très grande capacité...
Le fait que Google développe ses propres fs le montre bien (avec leur chunk de 64 Mo :p )
L'idée de stocker les méta-données dans le dirent est intéressante. Si le nom de fichier et ses métadonnées se trouvent côte à côte dans un dirent, aurons-nous encore besoin des numéros d'inode ? :)
Pour ce qui est de l'idée de plusieurs fs dans un fs principal je suis moins enthousiasme. Qui dis fs dis superblocks... dans la pratique combien de place devra-t-on sacrifier pour nos données ?
Même avis pour le principe de copie des métadonnées... mais j'en changerais peut-être (d'avis) si un jour j'ai un gros pb de fs (ce qui n'est encore jamais arrivé :) )
J'aurais bien aimmé qu'ils se penchent aussi sur le cryptage ou la compression des données ou encore la possibilité d'éffacer simplement ses données de façon sécurisée (j'entends un fichier)
# :-)
Posté par devloop . En réponse à la dépêche Le futur des systèmes de fichiers discuté au Linux Filesystems Workshop 2006. Évalué à 4.
Le fait que Google développe ses propres fs le montre bien (avec leur chunk de 64 Mo :p )
L'idée de stocker les méta-données dans le dirent est intéressante. Si le nom de fichier et ses métadonnées se trouvent côte à côte dans un dirent, aurons-nous encore besoin des numéros d'inode ? :)
Pour ce qui est de l'idée de plusieurs fs dans un fs principal je suis moins enthousiasme. Qui dis fs dis superblocks... dans la pratique combien de place devra-t-on sacrifier pour nos données ?
Même avis pour le principe de copie des métadonnées... mais j'en changerais peut-être (d'avis) si un jour j'ai un gros pb de fs (ce qui n'est encore jamais arrivé :) )
J'aurais bien aimmé qu'ils se penchent aussi sur le cryptage ou la compression des données ou encore la possibilité d'éffacer simplement ses données de façon sécurisée (j'entends un fichier)