Un truc qui m'a frappé, c'est que certaines potentialités du nouveau design sont «mis de côté» pour rester compatible avec l'interface standard VFS (Virtual File System) du kernel Linux.
Après, il faudra espérer que l'espace utilisateur saura prendre parti des nouvelles possibilités en terme d'extension (les extensions sont au niveau système, mais c'est bien à condition d'être utilisé, et l'utilisation c'est direction l'espace utilisateur).
Ainsi, mettez ensemble ces quatres possibilités :
- les fichiers peuvent être en même temps un répertoire (voir «Files That Are Also Directories»)
- ainsi, il n'y a plus vraiment d'attributs, mais des fichiers accessibles quand on voit un fichier sous son aspect répertoire (ex: fichier.txt/owner)
- il existe toujours la possibilité de faire des «pseudo files» (ou fichiers spéciaux en français)
- reiserfs4 est construit sur l'usage de plugin, et pensé pour que chacun puisse proposer ses plugins pour étendre les possibilités.
Vous ne voyez pas ? Moi, je vois plein d'utilisations possibles en l'état (là tout de suite avec reiserfs4 sur un kernel 2.6):
- un «attribut» md5sum (implémenté sous forme d'un fichier spécial), accessible via un simple fichier.txt/md5sum. Rien à voir avec ce qu'ils veulent faire avec l'ext3, où il serait question d'un attribut supplémentaire où on pourrait stocker le md5sum, alors que là, ça n'occuperai pas de place disque supplémentaire.
- pour un fichier ogg par exemple, cela permettrait d'accéder très facilement aux tags sous forme d'«attributs», et quand je dis facilement, ça serait tellement simple que n'importe qui pourrait écrire son petit fichier bash. Tout nouvel «attribut» pourrait être exploitable sans nécessiter la réécriture des programmes, ce serait juste un fichier quand on regarderait fichier.ogg en tant que répertoire.
- etc...
D'ailleurs, avec un tel système, on aurait intérêt à «exporter» les méta-informations non calculées (je pense à la longueur d'un morceau en ogg, c'est une méta-information calculée, et non pas une «vraie» méta-information éditable) en dehors du fichier.ogg vu comme fichier (en tant que suite d'octets), pour les placer dans des fichiers accessibles via fichier.ogg/ vu comme un répertoire. Et ainsi, inutile de réinventer la roue pour l'optimisation, puisque quelquesoit le type de fichier et de méta-données, ce sont les algorithmes du système de fichier, hyper-optimisés, qui seront utilisés.
Dernière petite remarque : on m'a fait remarqué que placer les attributs dans des fichiers devaient perdre énormément de place puisqu'un fichier fait au moins 4 Ko... Je rappelle donc cette fonctionnalité : «Wastes less space: no static inode space allocation, small files packed together». Et voilà ! :)
[^] # Re: FOSDEM à Bruxelles, premières interviews
Posté par JSL . En réponse à la dépêche FOSDEM à Bruxelles, premières interviews. Évalué à 9.
http://www.namesys.com/v4/v4.html(...) (Pour avoir un bref aperçu, lire 2.4(directories) et 2.5)
Un truc qui m'a frappé, c'est que certaines potentialités du nouveau design sont «mis de côté» pour rester compatible avec l'interface standard VFS (Virtual File System) du kernel Linux.
Après, il faudra espérer que l'espace utilisateur saura prendre parti des nouvelles possibilités en terme d'extension (les extensions sont au niveau système, mais c'est bien à condition d'être utilisé, et l'utilisation c'est direction l'espace utilisateur).
Ainsi, mettez ensemble ces quatres possibilités :
- les fichiers peuvent être en même temps un répertoire (voir «Files That Are Also Directories»)
- ainsi, il n'y a plus vraiment d'attributs, mais des fichiers accessibles quand on voit un fichier sous son aspect répertoire (ex: fichier.txt/owner)
- il existe toujours la possibilité de faire des «pseudo files» (ou fichiers spéciaux en français)
- reiserfs4 est construit sur l'usage de plugin, et pensé pour que chacun puisse proposer ses plugins pour étendre les possibilités.
Vous ne voyez pas ? Moi, je vois plein d'utilisations possibles en l'état (là tout de suite avec reiserfs4 sur un kernel 2.6):
- un «attribut» md5sum (implémenté sous forme d'un fichier spécial), accessible via un simple fichier.txt/md5sum. Rien à voir avec ce qu'ils veulent faire avec l'ext3, où il serait question d'un attribut supplémentaire où on pourrait stocker le md5sum, alors que là, ça n'occuperai pas de place disque supplémentaire.
- pour un fichier ogg par exemple, cela permettrait d'accéder très facilement aux tags sous forme d'«attributs», et quand je dis facilement, ça serait tellement simple que n'importe qui pourrait écrire son petit fichier bash. Tout nouvel «attribut» pourrait être exploitable sans nécessiter la réécriture des programmes, ce serait juste un fichier quand on regarderait fichier.ogg en tant que répertoire.
- etc...
D'ailleurs, avec un tel système, on aurait intérêt à «exporter» les méta-informations non calculées (je pense à la longueur d'un morceau en ogg, c'est une méta-information calculée, et non pas une «vraie» méta-information éditable) en dehors du fichier.ogg vu comme fichier (en tant que suite d'octets), pour les placer dans des fichiers accessibles via fichier.ogg/ vu comme un répertoire. Et ainsi, inutile de réinventer la roue pour l'optimisation, puisque quelquesoit le type de fichier et de méta-données, ce sont les algorithmes du système de fichier, hyper-optimisés, qui seront utilisés.
Dernière petite remarque : on m'a fait remarqué que placer les attributs dans des fichiers devaient perdre énormément de place puisqu'un fichier fait au moins 4 Ko... Je rappelle donc cette fonctionnalité : «Wastes less space: no static inode space allocation, small files packed together». Et voilà ! :)