Ce système de fichiers (GLS3) gère des fichiers « en vrac » : ils sont tous au même endroit. Il n'a pas besoin d'une structure hiérarchique de répertoires. Au contraire même, une telle structure lui compliquerait la construction de vues orthogonales.
Revenons à l'origine de la métaphore des documents, fichiers, répertoires, dossiers, classeurs. Nous avons des objets (feuilles volantes, livres ou autres) qui sont rangés, le terme est important, dans des structures contenantes, que ce soient des classeurs, des tiroirs, des caisses, etc., elles mêmes rangées dans d'autres structures contenantes.
Ces rangements sont faits suivant une certaine catégorisation (je mets mes livres dans la bibliothèque, mes copies de comptes dans mon classeur bancaire). Et cette catégorisation est hiérarchisée : mes copies de comptes sont dans une pochette, mes relevés EDF dans une autre, les deux pochettes sont dans un classeur, le classeur dans une armoire, à côté d'autres objets (vêtements, chaussures...).
Cette catégorisation hiérarchique, c'est moi qui l'ai décidée mais elle est figée. Cela n'est pas très gênant parce que je n'ai pas une quantité énorme d'objets à classer et que ceux-ci sont réels (ils prennent un certain espace).
Par contre, les objets sous forme informatique :
- sont beaucoup plus nombreux ;
- ne prennent pas de place dans un rangement : l'adresse (p.ex. i-node initial, nom de fichier...) prend une toute petite place et est décorrélée de l'objet lui-même ;
- peuvent vérifier plusieurs catégorisations hiérarchiques toutes aussi pertinentes les unes que les autres (p.ex. les photos classées par date, par lieu, par personnes, etc.).
Un ensemble d'objets peut donc être catégorisé hiérarchiquement de beaucoup de façons.
Si une catégorisation est utilisée et qu'elle est obligatoire (comme c'est le cas dans un système de fichiers à répertoires : pour atteindre un fichier, on est obligé de passer par les répertoires parents), utiliser une autre catégorisation est difficile et alourdi la gestion (p.ex. faire des hiérarchies parallèles avec des liens symboliques : les liens sont relatifs à la première catégorisation, si l'on modifie la catégorisation d'origine, on doit répercuter sur toutes les autres hiérarchies, si l'on efface dans une hiérarchie, doit-on effacer dans les autres, etc.).
Il vaut mieux donc ne pas utiliser de hiérarchisation primaire : tous les objets sont dans un dépôt et les catégorisations sont virtuelles. On peut p.ex. réaliser ceci sous la forme de répertoires et de liens symboliques mais ce n'est pas une bonne solution (voir p.ex. le problème de l'effacement).
Les systèmes de fichiers actuels (ext2, ext3, reiserfs, xfs, jfs...) sont fondés sur une hiérarchisation par répertoires. Ils sont étudiés pour. Ils sont donc optimisés pour gérer des fichiers, des répertoires et des liens (symboliques ou non). Cette hiérarchisation fixe est très utile dans de nombreux cas. En fait, la possibilité de hiérarchisations mobiles, virtuelles et parallèles de GLS3 ne sert quasiment que pour les données d'un utilisateur, pour son $HOME.
Comme on vient de le voir, GLS3 met tous ses fichiers dans un même dépôt et permet de construire des hiérarchies parallèles et très mobiles sur ces fichiers. Comme je l'ai aussi suggéré (voire montré), les hiérarchies de répertoires et les liens (symboliques ou non) des systèmes de fichiers classiques (sfc) ne sont ni utiles ni utilisables. Donc :
1. les sfc n'ont pas les structures et mécanismes nécessaires (même s'ils permettent les tags, ils n'ont pas les mécanismes de manipulation et de recherche nécessaires, non plus qu'ils n'ont les structures pour les méta-données des hiérarchies virtuelles) ;
2. les sfc ne sont absolument pas optimisés pour GLS3.
Vouloir intégrer GLS3 dans un sfc, disons ext4, signifierait refondre totalement le système de hiérarchisation par répertoires, (ré)optimiser le sfc pour la gestion des tags, des hiérarchies virtuelles et de la recherche dans les objets (dont je n'avais pas parlé jusque là). Au final, il ne resterait plus grand' chose du sfc et de tous ses avantages annexes.
Par contre, un système de fichiers optimisé pour gérer les fichiers « en vrac » serait plus utile, comme sous-couche à GLS3.
[^] # Re: systeme de fichier?
Posté par Sylvain Sauvage . En réponse au journal GLScube pour vous aider à organiser vos données. Évalué à 10.
Revenons à l'origine de la métaphore des documents, fichiers, répertoires, dossiers, classeurs. Nous avons des objets (feuilles volantes, livres ou autres) qui sont rangés, le terme est important, dans des structures contenantes, que ce soient des classeurs, des tiroirs, des caisses, etc., elles mêmes rangées dans d'autres structures contenantes.
Ces rangements sont faits suivant une certaine catégorisation (je mets mes livres dans la bibliothèque, mes copies de comptes dans mon classeur bancaire). Et cette catégorisation est hiérarchisée : mes copies de comptes sont dans une pochette, mes relevés EDF dans une autre, les deux pochettes sont dans un classeur, le classeur dans une armoire, à côté d'autres objets (vêtements, chaussures...).
Cette catégorisation hiérarchique, c'est moi qui l'ai décidée mais elle est figée. Cela n'est pas très gênant parce que je n'ai pas une quantité énorme d'objets à classer et que ceux-ci sont réels (ils prennent un certain espace).
Par contre, les objets sous forme informatique :
- sont beaucoup plus nombreux ;
- ne prennent pas de place dans un rangement : l'adresse (p.ex. i-node initial, nom de fichier...) prend une toute petite place et est décorrélée de l'objet lui-même ;
- peuvent vérifier plusieurs catégorisations hiérarchiques toutes aussi pertinentes les unes que les autres (p.ex. les photos classées par date, par lieu, par personnes, etc.).
Un ensemble d'objets peut donc être catégorisé hiérarchiquement de beaucoup de façons.
Si une catégorisation est utilisée et qu'elle est obligatoire (comme c'est le cas dans un système de fichiers à répertoires : pour atteindre un fichier, on est obligé de passer par les répertoires parents), utiliser une autre catégorisation est difficile et alourdi la gestion (p.ex. faire des hiérarchies parallèles avec des liens symboliques : les liens sont relatifs à la première catégorisation, si l'on modifie la catégorisation d'origine, on doit répercuter sur toutes les autres hiérarchies, si l'on efface dans une hiérarchie, doit-on effacer dans les autres, etc.).
Il vaut mieux donc ne pas utiliser de hiérarchisation primaire : tous les objets sont dans un dépôt et les catégorisations sont virtuelles. On peut p.ex. réaliser ceci sous la forme de répertoires et de liens symboliques mais ce n'est pas une bonne solution (voir p.ex. le problème de l'effacement).
Les systèmes de fichiers actuels (ext2, ext3, reiserfs, xfs, jfs...) sont fondés sur une hiérarchisation par répertoires. Ils sont étudiés pour. Ils sont donc optimisés pour gérer des fichiers, des répertoires et des liens (symboliques ou non). Cette hiérarchisation fixe est très utile dans de nombreux cas. En fait, la possibilité de hiérarchisations mobiles, virtuelles et parallèles de GLS3 ne sert quasiment que pour les données d'un utilisateur, pour son $HOME.
Comme on vient de le voir, GLS3 met tous ses fichiers dans un même dépôt et permet de construire des hiérarchies parallèles et très mobiles sur ces fichiers. Comme je l'ai aussi suggéré (voire montré), les hiérarchies de répertoires et les liens (symboliques ou non) des systèmes de fichiers classiques (sfc) ne sont ni utiles ni utilisables. Donc :
1. les sfc n'ont pas les structures et mécanismes nécessaires (même s'ils permettent les tags, ils n'ont pas les mécanismes de manipulation et de recherche nécessaires, non plus qu'ils n'ont les structures pour les méta-données des hiérarchies virtuelles) ;
2. les sfc ne sont absolument pas optimisés pour GLS3.
Vouloir intégrer GLS3 dans un sfc, disons ext4, signifierait refondre totalement le système de hiérarchisation par répertoires, (ré)optimiser le sfc pour la gestion des tags, des hiérarchies virtuelles et de la recherche dans les objets (dont je n'avais pas parlé jusque là). Au final, il ne resterait plus grand' chose du sfc et de tous ses avantages annexes.
Par contre, un système de fichiers optimisé pour gérer les fichiers « en vrac » serait plus utile, comme sous-couche à GLS3.