Salut à tous !
 
Comme vous le savez certainement, Reiser4 est l?évolution du remarquable système de fichiers Reiser de Namesys, disponible sous Linux et réputé (entre autre) pour ses excellentes performances, en particulier sur les petits fichiers. Il existe actuellement des betas pour kernels 2.5, et le travail semble avoir porté ses fruits : Reiser4 est notablement plus rapide que ses concurrents sur les premiers tests officiels menés. Mais les évolutions sont loin de se limiter à un simple gain de performances, les concepts concrétisés dans cette nouvelle version veulent révolutionner non seulement le petit monde des filesystems, mais aussi renouer avec la sécurité et secouer le standard POSIX.
 
La release étant prévue pour cet été, et le sujet collant parfaitement avec mes instructions, j?ai choisi Reiser4 comme objet de mon TIPE pour l?année prochaine, tant dans sa conception globale que dans sa comparaison avec les systèmes de fichiers traditionnels (ext2 en particulier) et du point de vue des possibilités qu?il ouvre pour GNU/Linux et l?informatique en général, la sécurité en particulier.
 
J?ai donc lu la documentation de leur site officiel, mais elle reste assez incomplète sur certains points, et elle semble ancienne tant les imprécisions sur ce qui sera et ne sera pas effectivement inclus dans Reiser4 sont troublantes ? j?ai donc besoin de votre aide, mon expérience en filesystems se résumant aux notions d?utilisateur/administrateur Linux, en plus des quelques lectures de ces deux dernières semaines. Je ne vous demande évidement pas de me faire mon exposé, mais quelques point épineux subsistent, et j?aimerais vraiment que vous m?éclairiez ? pardon d?avance pour les éventuelles erreurs que mon exposé comportera, je vous demande simplement de les signaler et si possible, de les corriger en précisant les notions qui ont pu m?échapper.
Il est tout à fait clair que mes travaux seront accessibles en licence appropriée (FDL ?) à tous, dès que je jugerais l?exposé assez complet et ?propre? pour les futurs lecteurs. Merci d?avance de votre aide et de vos commentaires éventuels...
 
Commençons d?abord par ce que j?ai compris de Reiser4, je vais tenter ici un petit exposé des nouveautés de Reiser4 et de ses avantages/inconvénients vis à vis des filesystems ?traditionnels? :

• Reiser4 considère deux éléments principaux dans un système de fichiers : les fichiers et les dossiers. C?est à partir de ces deux notions qu?il construit toutes les données qu?un filesystem est censé garder et proposer, tout en sachant que ces deux notions sont ici étroitement liées : un fichier peut être accédé comme un dossier, notamment pour lire ses attributs. En effet, les attributs et autres propriétés d?un fichier ou d?un dossier, jusqu?alors dotés d?un statut bâtard dans l?entête, sont désormais considérés comme des fichiers, par exemple ?filename/..stat/owner? contient le propriétaire du fichier nommé filename. Il en va de même pour toutes les informations liées au fichier, que l?on peut étendre grâce à des plugins (pour des propriétés de sécurité étendues par exemple). Ceci permet de réduire le nombre d?éléments à manipuler, et un nouveau system call reiser4() permet de manipuler le fichier par des transactions, sur le même schéma.
• Ce nouveau Reiser4 est désormais basé sur les B+Trees, qui sont une variante des Btrees traditionnels. Chaque élément, fichier ou dossier, possède une clé unique indépendante de son chemin d?accès. L?arborescence telle qu?on a l?habitude de la voir, avec ses chemins d?accès et ses noms de fichiers, n?a pour ainsi dire rien à voir avec l?organisation réelle des ?objets? sur le disque. Lorsqu?un fichier ou un dossier doit être accédé, l?interface de résolution (semantic layer) va trouver la clé qui correspond au chemin d?accès, et une seconde interface (storage layer) chercher dans l?arborescence des clés le fameux fichier pour lire/écrire son contenu, ses propriétés ou toute information s?y rapportant. Ceci permet d?accélérer les opérations de lecture/écriture en séparant scrupuleusement les noms donnés par l?utilisateur, et l?organisation du système, bien mieux optimisée.
• Pour ne rien gâcher, les petits fichiers sont regroupés pour occuper moins d?espace disque. En effet, le disque est découpé en nodes, blocs élémentaires de 4ko, les gros fichiers étant découpés pour occuper un ensemble de ces blocs, les petits fichiers (de moins de 4ko) occupant tout de même un bloc à eux seuls, même si leur contenu est beaucoup plus petit que 4ko. Reiser regroupe les petits fichiers pour leur faire occuper moins de nodes, et les stocke dans des nodes dites formatées, capables de contenir plusieurs portions de fichiers appelés ?items?. Au-delà de 16ko, ces fichiers sont découpés stockés dans des nodes non formatées, qui offrent toute leur place. Ceci permet de gagner environ 20% d?espace disque sur les systèmes traditionnels, cette estimation pouvant grandement changer suivant l?utilisation à laquelle est destinée la station, et évite une fragmentation trop importante.
• Les wandering logs permettent, pour les opérations de journalisation, d?optimiser les performances et d?éviter une usure trop importante de la surface du disque, en écrivant les données destinées à être copiées directement à leur destination, évitant ainsi une copie inutile.
• Pour ce qui est de la sécurité, car il ne faut pas oublier que Reiser4 est sponsorisé par le département de la défense américain, Reiser4 implémente un système très performant de plugins qui permet non seulement une flexibilité plus importante, mais aussi une meilleure lisibilité du code. C?est ainsi que le cryptage peut être directement implémenté, notamment lors de l?opération de ?packing? qui s?occupe de regrouper dynamiquement les petits fichiers destinés à être écrits sur le disque, d?où un gain en performances important, sans compter que la technique de ?dancing trees? rendent les opérations de cryptage moins fréquentes (en n?écrivant sur le disque que lorsque la mémoire arrive à manquer), et donc moins gourmandes en puissance. Le système de transactions, similaires à une base de données, permet de garantir aux processus que l?information sera effectivement écrite comme il faut sans avoir besoin de logs de sécurité, ce dont de nombreuses applications bénéficierais en termes de sécurité et de performances. L?efficacité du système de fichiers dans la manipulation de petits fichiers permet une gestion plus fine de la sécurité, en n?obligeant pas à réunir toute l?information dans un fichier global. L?auteur cite notamment le fameux fichier /etc/passwd qui gagnerait à être divisé en plusieurs petits fichiers, afin de connaître par exemple la dernière date de modification du mot de passe de tel ou tel utilisateur, et de gérer plus finement les droits d?accès aux différents logins. De même, certains fichiers peuvent être liés pour profiter des mêmes propriétés, notamment des attributs de sécurité.
• De nombreuses autres astuces et concepts ont été intégrés à Reiser4, pour améliorer les performances, la flexibilité et la sécurité. Reste à savoir si tous ces changements, qui sont pour certains clairement au-delà de la frontière POSIX, seront adoptés par les développeurs. Avec de plus en plus d?opérations supportées par le filesystem, la question de la flexibilité et de l?implémentation se pose, même si les plugins viennent soutenir Reiser4. D?autant plus que ces derniers plugins doivent actuellement pour la plupart être compilés en dur avec le kernel, et recevoir un id unique ? tout ceci réclame une grande confiance en Reiser et son équipe, dont le filesystem semble évoluer continûment (la documentation parle déjà de la version 6 ?). Sa jeunesse et son ambition sans borne handicaperont certainement dans un premier temps Reiser4 qui devra prouver la réelle utilité des nouvelles possibilités qu?il apporte, tout en maintenant un haut niveau de performances. Reste un filesystem très prometteur, innovant et rafraîchissant, qui même s?il ne révolutionne pas aujourd?hui le petit monde Unix aura certainement un impact sur l?évolution des systèmes de fichiers.

Voilà pour le topo, maintenant les quelques interrogations. Les spécialistes auront observé quelques zones d?ombre que j?aimerais éclaircir, notamment sur les fonctionnements internes de Reiser4. Voici les premières questions :

• Tout d?abord la double arborescence. Pour celle ?derrière les fourneaux? ca a l?air d?aller, un balanced tree bien sympathique et performant, mais ? comment les données sont-elles finalement organisées ? Les fichiers et les dossiers sont-ils organisés de la même manière ? L?arbre ne pouvant naturellement être équilibré, a-t-on une profondeur constante, chaque branche se remplissant au fur et à mesure (adresses constantes, mais nombre total de fichiers limité), ou est-ce que le fanout est variable, l?arbre évoluant en profondeur au fur et à mesure que le nombre d?objet augmente (peu probable, les adresses changeant alors ?) ?
• Comment les adresses sont-elles calculées ? Admettons que l?on aie un fanout de 16, on code les adresses en hexa (totalement au pif ?), avec une adresse AB326?4 (incomplète, ceci serait le début d?une adresse à 16 caractères), est-ce que l?on prendrait la première entrée du root node, puis la seconde entrée du premier branch node, et au final la quatrième entrée du leaf node ?
• Pour ce qui est de la table de correspondance entre clés et dossiers, comment est-elle élaborée ? A-t-on un arbre ou un simple tableau ? Je n?ai vu aucune doc sur le site officiel qui renseigne sur ce petit détail qui s?avère être capital dans l?organisation des données ?
• Pour ce qui est du B+Tree, c?est bien un Btree dans blobs non ?
• Et les dancing trees, ce sont des balanced trees sur lesquels on n?écrit que lorsque la mémoire vient à manquer ?
• Quand il parle des ACLs propre à chaque ?field? des entrées du fichier /etc/passwd (cf doc officielle), de quoi parle-t-il effectivement ?
• Que pensez-vous de sa position vis à vis des standards POSIX ?
• On m?a souvent dit que les systèmes de fichiers de type fat ou ext2 étaient assez simples ? vous pourriez m?expliquer, basiquement ?
• Vous pensez que ce topic a sa place en section développeurs ?

Merci encore de votre aide,
 
Fred
 
Références :
Doc officielle -- http://www.namesys.com/v4/v4.html
L'explication "brutale" de Ping --  http://forum.hardware.fr/forum2.php3?post=9912&cat=11

 
 
rafraîchissent -> rafraîchissant
 
dsl j'y connait en file system, ca sera ma tres tres...maigre contribution  
 
PS : et puis c un beau    bien déguisé car c'est vrai que le sujet est plutot intéressant

Merci, l'erreur a été corrigée
 
Sinon, je me suis renseigné sur ext2, il y a une excellente doc sur le Kernel Hacker's guide, qui décrit non seulement les principes et l'implémentation de ext2, mais aussi les rudiments de VFS :
http://www.tldp.org/LDP/khg/HyperN [...] intro.html
 
En gros, c'est quand même assez basique, et même s'il a beaucoup évolué depuis, il descend de Minix dont les principes ne sont pas vraiment révolutionnaires...
Reste qu'ext2 est fiable et plutôt prévisible dans ses performances, sans surprises, et l'ext3 lui ajoute simplement la journalisation, ce qui en fait un filesystem relativement bien sécurisé, mais au niveau des performances c'est pas vraiment ca...
 
En gros, on a des fichiers et des dossiers (qui sont en fait des fichiers contenant une liste des fichiers/dossiers de son arborescence, avec un numéro d'inode), et lorsqu'on doit chercher quelque chose, il faut se taper toute l'arborescence sur tout le disque, avant d'arriver effectivement à l'objet désiré. C'est là que le balanced tree de Reiser est tout de même beaucoup plus efficace : lors de l'accès à un fichier, les performances sont meilleures parce que l'organisation est bien plus intelligente, et lors d'une recherche on n'a qu'à regarder dans le hashtable.
 
Sinon, moi aussi, Up
J'ai vu de superbes démonstrations de vos connaissances, faites pas vos timides

pas encore lu, mais tu peux faire des paragraphes dans le gros quote s'il-te-plait    

Bon, j'ai regardé de plus près l?architecture d'ext2, en fait c'est pas si bidon que ça
D'ailleurs, ext2 est considéré comme le plus performant des systèmes de fichiers à structure linéaire, c'est qu'il doit bien y avoir quelque chose d'intéressant . J'm'en vais vous l'conter :

• Ext2 divise ses partitions en entités appelées "block groups", qui contiennent chacun une copie du superblock, et du descripteur pour assurer une redondance de ces informations cruciales, ainsi qu'une partie de la table d'inodes, avec les données qui suivent. Cette dernière initiative permet de rapprocher la table d'inodes des données auxquelles elle se rapporte, d'où un gain en performances.
• Les répertoires ont une structure d'entrées à longueur variables : une entrée du répertoire (un fichier par exemple) dont le nom a 2 caractères n'occupera pas la place de 255 caractères, d'où un, gain en place, très utile pour mettre ces données en cache...
• Le cache d'ailleurs : VFS implémente un cache d'accès aux fichiers, à savoir que pour un fichier qui vient d'être accédé et auquel on voudrait accéder à nouveau, le filesystem ne va pas rechercher dans l'arborescence complète ce nouveau fichier, il prendra directement le numéro d'inode qui se trouve dans le cache.
• Ensuite, encore du cache, lorsque ext2 lit un fichier il lit toujours les quelques blocs supplémentaires qui suivent le fichier lu. Ceci s'est révélé assez intéressant en termes de performances (quitte à choisir des données à mettre en cache, autant choisir celles qui coûtent le moins en terme d'opérations I/O).
• Lorsque ext2 écrit un fichier, il laisse toujours un espace qui peut atteindre jusqu'à 8 blocks adjacents derrière ce dernier, ce que Reiser appelle les "air holes" et qu'il prévoit de proposer avec un défragmenteur (appelé par Reiser "packager" ), ext2 le fait à la volée, et il s'avère que dans 75% des cas cette opération est bénéfique pour éviter une fragmentation trop importante.
• VFS a profité d'un soin particulier, et même si le gros des opérations revient au véritable filesystem, VFS contribue à une optimisation des performances avec par exemple le système de cache de fichiers cité plus haut (également implémenté dans Reiser)

On peut finalement conclure que ext2 n'est pas le dernier des filesystems et que sa structure, même si elle souffre d'un passé lourd qui aura du mal à disparaître, profite d'optimisations intéressantes qui en font, outre la robustesse et la fiabilité qu'on lui connaît, un filesystem très intéressant et pas si archaïque que ça. D'ailleurs l'implémentation de la journalisation avec ext3 est très propre et peu gourmande en ressources. ext[2/3/...]fs est définitivement le système de fichier phare de Linux en conjuguant habillement performances, sécurité et robustesse, tout en inspirant la confiance que ces années de déboguage lui ont apportée. Espérons que Reiser saura être aussi fiable
 
Mais Reiser4 sait garder ses secrets, que j'ai décrit un peu plus haut, et votre aide sera certainement très précieuse pour m'en sortir et achever ma doc

Ca y est, j?ai mis des petits paragraphes dans le premier post, et j?ai corrigé toutes mes vilaines fautes, mon sujet est tout propre, maintenant j?attend vos réponses
 
? et merci à vous lecteurs qui vous intéressez à ce texte

Je connais rien en FS donc juste quelques remarques "esthétiques" :
 - 3ème ligne : "entre haute" => "entre autre"
 - début 3ème § : "il semble ancien" => "elle semble ancienne"
 - Pour la licence, la FDL est plus appropriée pour un exposé non ?
 
Très intérressant en tout cas tout ça
 

Voilà, c'est corrigé
Effectivement, c'est bien la FDL à laquelle je pensais
 
J'espère que d'ici ce soir les spécialistes viendront agrémenter la topic, en attendant merci de vos retours qui me permettent d'améliorer mon texte

Après de nombreuses recherches, voici enfin à quoi ressemble une clé ReiserFS (v3, j'imagine que rien n'a changé pour la v4) :
<locality_id, object_id, offset, uniqueness>
 
Le locality_id étant l'identifiant unique du dossier parent de l'objet en question, object_id représentant l'identifiant unique de l'objet, offset représentant le point de départ de l'objet dans l'item et uniqueness étant certainement un petit coup de poudre magique pour être sûr que la clé est vraiment unique (vive la parano ).
 
Reste que je me demande à quoi sert ce fameux locality_id, certainement une astuce pour la résolution par le storage layer ... l'emplacement dans l'arbre du fichier et de son dossier parent seraient donc liés ?
Et la question originelle demeure : comment est organisée la correspondance entre le path et la clé, comment fonctionne le semantic layer ?

http://www.linuxgazette.com/issue55/florido.html

Sorry, we could not find the file you requested ...

fonctionne tres bien chez moi
bon, ben LG issue#55

C'est curieux, je n'arrive à l'avoir qu'avec lecache Google ... mais c'est très intéressant qd même
 
... et c'est marrant, il n'y a pas grand monde qui semble s'intéresser au fonctionnement des filesystems, mes posts sont mal faits ou c'est le sujet qui ne plaît pas ?!?

 
Mauvais souvenirs de ReiserFS, je pars donc avec un à priori négatif sur Reiser4  

SI ça m'intéresse énormément, mais comme j'y connais que dalle...
 
tout au plus puis je te donner ces quelques liens :
http://forum.hardware.fr/forum2.ph [...] h=&subcat=
http://forum.hardware.fr/forum2.ph [...] &owntopic=

Tu peux préciser ? Il est à noter que Reiser4 a fait d'énormes progrès en termes de performances (c'est peut-être de ce côté que tu as été déçu), et pour ce qui est de la fiabilité, normalement ca devrait être testé ... reste à attendre la sortie officielle, mais avec les nouveaux sponsors ca s'annonce très bien, d'autant qu'ils avancent vraiment pas à pas : les features sont fixées jusqu'à la v6 !
 
Sinon Mjules, je vais vraiment faire tout mon possible pour vous amener à tous un exposé clair et précis sur Reiser4, avec quelques annexes notamment sur les filesystems en général.
 
Du côté des newsgroup, bah les américains ont pas l'air super intéressés, et sur fr.comp.os.linux.debats ils sont partis sur un streetfight entre UTF-8 et ISO-8859-1 bref, j'ai laissé tomber. J'attend donc febrillement votre aide

je sais que reiserfs avait pas mal de pb avec le noyau 2.4.10 (et les précédents il me semble).

Bon, on va essayer de ressusciter les souvenirs de licence sur les systèmes de fichiers.
 

À mon avis il parle de couper passwd en plein de petits fichiers, un par utilisateur, avec des permissions spécifiques.

Ça ressemble à de l'esbrouffe. Ce système permet d'améliorer les performances dans certaines conditions, ce n'est pas pour autant la peine de forcer ces conditions là où il n'y a pas de problèmes de performances particuliers. À mon avis, la vraie différence va se faire sur le stockage et l'accès aux données, où on aura tendance à utiliser certains types de stockages qu'on hésitait parfois à utiliser (enfin, moins depuis l'avènement de reiser 3).  
 

De ce que j'en sais, ext2 est dérivé de minix, lui-même dérivé du bon vieux système de fichiers System V. Des principes simples, mais efficaces (un bitmap et des i-n?uds), donc c'est plutôt rapide dans pas mal de circonstances.
La FAT mérite tout juste le nom de système de fichiers selon moi. On devrait plutôt parler de « tas de fichiers » dans ce cas

Merci beaucoup JarJar
 
J'aîmerais juste savoir à quoi correspondent les bitmap et i-noeuds. Et pour ce qui est du respect de POSIX, notamment en ce qui concerne les propriétés et attributs de certains fichiers, n'est-il pas plus judicieux de les stocker dans des petits fichiers plutôt que de les considérer comme un troisième type d'information, au moins pour la clarté du code ?
... bon, perso, je pense aussi qu'il s'arrête à des points de détails (au fond, les attributs sont très bien gérés comme ca et les systèmes de metadonnées ne sont pas si mal non plus), mais ca peut aider à uniformiser l'exploitation du filesystem, à simplifier l'API, non ?
 
Sinon, pour Mjules, ces problèmes ont été réglé depuis la v2.4.18, et Reiser4 se fonde sur le code "propre" de Reiser3. Bien sûr, les nouveautés demanderont une periode de tests importante, mais globalement ca devrait se passer plutôt bien.

Eh bien tout d'abord, le disque est découpé en blocs (en général de 1 ou 4 Ko). Au début du disque (après le secteur de boot, dans ce qu'on appelle le superbloc), il y a un bitmap qui représente la cartographie des blocs occupés ; ça permet d'allouer intelligemment les blocs pour mettre des fichiers dedans (c'est grâce à ça qu'ext2 peut faire la défragmentation en temps réel dont tu as parlé).
 
Ensuite, à chaque fichier sur le disque sont associés : un numéro d'i-n?ud (inode) unique, ainsi que le nombre de liens physiques associés et les droits... mais pas le nom. Ensuite, un système intelligent décrit les blocs occupés par ce fichier sur le disque (en allant utiliser des blocs d'index sur le disque si le fichier est gros, histoire de ne pas encombrer la table). Tout ceci est répertorié dans la table des i-n?uds au début du disque (après le superbloc). Ensuite, quand un répertoire est stocké sur le disque, il contient la liste des noms de fichiers avec les i-n?uds associés. C'est ce mécanisme qui permet l'existence de liens physiques, un même i-n?ud pouvant être référencé plusieurs fois.
 
Globalement, c'est fiable, rapide, et facile à réparer => une bonne recette qui marche depuis 20 ans.
 

Comme ce sont des métainformations, ce n'est pas forcément un mal d'y accéder séparément, mais évidemment c'est clairement plus extensible comme ça.  
 

Bien entendu, mais au lieu de faire ça dans leur coin, ils auraient pu s'entendre avec les développeurs des autres implémentations et les organismes de normalisation.
 

Bof, ne présmons pas trop vite. C'est vrai que s'ils ont compris la leçon de reiser 3, ils devraient tester ça un peu mieux.

Curieusement je n'avais pas fait le rapprochement entre inode et i-noeuds . Dans mon exposé, je parle d'inode ou de i-noeuds ? Le terme i-noeuds est-il réellement employé en cours d'info ?
 
Sinon, pour le bitmap, en gros ca répertorie les blocs occupé et les blocs non occupés non ? D'ailleurs, lorsque ext2 utilise des "air holes", les blocs aloués en plus le sont-ils réellement ou ont-ils un statut spécial dans le bitmap, de sorte qu'ils puissent être libérés si l'espace disque venait à manquer ?
 
Enfin, pour l'histoire des "blocs d'index", ca veut dire que si je demande à occuper les inodes 1,2,3,4 et 5, je vais dire "j'occupe les inodes de 1 à 5" plutôt que "j'occupe les inodes 1,2,3,4 et 5", pour gagner de l'espace dans le bitmap, non ?
 
Pour ce qui est des standards, effectivement la véritable voie à suivre aurait été de parler avec les organismes de standardisation. Mais leur choix est si radical qu'il a tout de même peu de chance d'être accepté ...
 
Pour ce qui est de la FAT, ca marche comme ext1 non ? Un superblock, un bitmap et un bordel de dossiers listant des numéros d'inode et gardant les noms de fichiers, et des fichiers épararpillés à la va-vite sur le disque sans organisation particulière non ? En même temps, c'est du closed-source ... mais les principes de FAT sont connus non (ne serait-ce que pour écrire le driver fat pour Linux) ?
Et pour NTFS, c'est du FAT avec des droits d'accès et un système de cryptage et de flux intégrés, ou ils ont amélioré la structure en attendant ?
D'ailleurs, cette histoire de flux que Reiser voulait résoudre avec sa non distinction de dossiers et des fichiers, qu'est-ce que c'est exactement ? On envoye un paquet de dossiers et fichiers en vrac au lieu de les envoyer un par un par un protocole réseau ? Les flux ne servent-ils que pour les transferts réseau ?
 
Merci de ton attentionet de ton aide qui m'a déjà permis de bien avancer

tu devrais jeter un oeil sur ce site, il y a peut-être quelques infos intéressantes sur FAT/NTFS
http://bellamyjc.net/fr/multiboot.html

Il semblerait bien, oui.
 

C'est exactement ça.
 

Là je n'en sais tro rien. À mon avis c'est fait en interne dans le driver sans être écrit sur le disque, mais faudrait vérifier.
 

Tu ne mélangerais pas blocs et i-n?uds ? Chaque i-n?ud contient la liste des blocs utilisés par le fichier. Quand le fichier est de petite taille, ça s'arrête là. Quand il est plus grand, à la place de la liste des blocs utilisés par le fichier, on met une liste de blocs d'indirection, alloués exprès, qui contiennent à leur tour l'index des blocs utilisés par le fichier. Si ça ne suffit pas, on rajoute encore des indirections (jusqu'à 3 niveaux) histoire de pouvoir stocker des très gros fichiers. La notion de "blocs tant à tant" n'existe pas vraiment.
 

Les principes de la FAT sont bien connus, et n'ont pas grand chose à voir avec les systèmes de fichiers unix. En gros, tu as un compteur de la place libre sur le disque et une FAT (écrite en double), qui décrit l'emplacement des fichiers sur le disque avec  une liste chaînée : si mes souvenirs sont bons (je ne sais plus très bien si les listes chaînées sont au niveau de la FAT ou directement mélangées aux données), tu as une cartographie du disque avec pour chaque bloc, le nom du fichier contenu (même si ce n'est pas le début !) et l'emplacement du bloc suivant. Un système lourd, très lent (surtout sur les gros fichiers), et qui se fragmente très vite (quand on cherche un bloc libre, c'est le premier trouvé qui est utilisé).
 

Vu que c'est journalisé, ils ont du changer pas mal de choses quand même.
 

Hmmm, je ne sais pas exactement à quoi ça fait référence. Tu aurais un lien qui en parle ?

J'ai en effet mélangé node et inode ... mais dans la Doc de Reiser4, qui était la première que je lisais sur les filesystems, il n'était question que de nodes, d'où la confusion
Rassures-moi : block et nodes, c'est bien la même chose non ?
 
Sinon, même à la lecture de la doc de ext2, effectivement, je n'avais pas trop compris ces "blocks d'indirection". Voici ma petite théorie, tu me diras si elle est juste :
Le fait est qu'un bloc de la table peut contenir plusieurs références différentes à des fichiers (plusieurs inodes quoi), par exemple le bloc 'a' peut contenir les numéro de blocs occupés par les fichiers x, y et z s'ils sont assez petits pour que leurs adresses tiennent dans un bloc. Si le fichier x par exemple est gros, et donc que la liste des références aux blocs qu'il occupe ne tiennent pas dans un seul bloc, on insère dans la table, comme une inode simple, une inode de type indirection qui pointe vers une liste de blocs isolés qui contiennent, eux, la liste des références des blocs occupés par le gros fichier x (j'espère que je suis clair ...). Si le fichier y par contre est vraiment très gros, et donc que l'inode de redirection ne tient elle même plus dans un bloc avec un seul niveau de redirection, on utilise un second niveau de redirection, l'inode de redirection première prend le plus de place possible (un bloc ...), et elle redirige donc vers un maximum d'inodes de seconde redirection qui pointent, elles, vers des blocs finaux qui contiendront enfin les blocs alloués au fichier. Arf, c'est fini .
Et ceci serait probablement la limitation de taille d'un fichier : il n'a pas "le droit" de dépasser deux niveaux de redirection, soit 4Go pour ext2. Ce sont vraiment des suppositions ... d'ailleurs, si la taille d'un bloc changeait, la taille maximale d'un fichier changerait, donc ma théorie tombe par terre puisque la taille maximale d'un fichier est renseignée dans les specs de ext2, donc il y a certainement quelques trucs à rectifier .
 
Une petite question d'ailleurs : le bitmap doit occuper une sacré place qd même, s'il n'utilise pas la concaténation de blocs (les blocs tant à tant sont occupés) non ?
 
 
Pour la FAT, c'est vraiment de la sauvagerie leur truc ... m'enfin, ca vient de DOS aussi, c'était pas vraiment destiné à gérer de gros volumes, et c'est pas un changement de 8 en 16 puis 32 à la fin de 'FAT' qui change quelque chose ...
Et cette histoire de chaîne, c'est vraiment risible
D'ailleurs, quand on compare l'évolution d'ext2, qui dérive tout de même de Minix, un filesystem somme toute assez basique, et celle de la FAT32 qui dérive de FAT8, on peut se sontir heureux
 
 
... journalisé, NTFS ?!?? En tout cas, il paraît qu'il est plus performant que FAT, même avec toutes les nouvelles fonctions implémentées
 
 
Quand je parlais de flux, je fais référence aux 'flux' de NTFS, dont j'ai entendu parlé mais qu'il ne m'a jamais été donné d'utiliser (ou tout du moins explicitement), bref je sais que ca vient de NTFS, que ca sert notamment pour Samba, et que c'était assez demandé ... pas vraiment plus, je vais essayer de me documenter avec comme mot clé 'NTFS streams'.

NTFS c plus lent que FAT...
 
les blocs sont plus petit, y'a plus d'accès en écriture...si t'active les sécurités, c pire...

si tu veux lancer le troll, c'est pas la bonne cat

je troll pas...je suis sous XP, et mes DD sont en FAT...
 
en plus, y'a des bugs avec la NTFS et le CDFS :  
 
exemple : je backup sur cd des fichiers qui étaient sur un dd en ntfs
je restore le cd sur une nouvelle partition NTFS
 
et pof, je perds les privilèges sur mes fichiers : le user qui les possède porte un nom généré automatiquement, une suite alphanumérique...bilan, faut se loguer en admin, se réapproprier tt les fichiers (ca peut prendre du temps), et redonner l'usage aux users concernés...
 
je trouve ca relou
 
Quant à la vitesse, c prouvé : regarde n'importe quel test de DD qui fait le même bench sur fat32 et NTFS : le NTFS est plus lent d'environ 15%...
 
Maintenant je dis pas que c mal le NTFS, je dis juste que si tu cherches la rapidité, c pas le bon FS sous win...maintenant, si t'a des contraintes de sécurité, etc, c le bon FS...
 
Je ne trolle pas du tout là, je suis très sérieux

Bon, pour les streams NTFS, je crois que j'ai trouvé : ce sont des propriétés de fichiers, des attributs, sous forme de fichiers qui ne sont pas directement accessibles dans l'arborescence. Des métadonnées en quelque sorte, mais je ne sais pas si ces streams sont propre à chaque fichier (je crois que si en fait ). Plus d'infos ici (le site ntfs.com est assez intéressant) :
http://www.ntfs.com/ntfs-multiple.htm
 
Sinon, j'ai lu sur ce site que NTFS supportait , outre les privilèges et autres restriction d'accès, le cryptage et la compression de fichiers, les quotas, les liens, et des optimisation pour le stockage de gros fichiers (d'après JarJar un gros pb pour FAT par ex), et effectivement également le journalising :
http://www.ntfs.com/ntfs_basics.htm
http://www.ntfs.com/ntfs_vs_fat.htm
 
Après cette petite parenthèse NTFSiène, les questions précédentes restent toujours d'actualité

http://www.admin-sys.org/astuces/d [...] n=dossiers
 

J'ai beau chercher, je ne vois pas à quoi ça peut servir. Ce sont des fichiers dans le fichier ? Ça change quoi par rapport à un répertoire ?
 

C'est impressionnant le nombre de trucs qu'ils ont mis dans un FS particulier au lieu de les mettre dans le VFS. J'ose pas imaginer la gueule du VFS en question, pour qu'ils n'osent même pas y toucher

C'est ça, sauf que tu mélanges blocs et i-n?uds. Quand le peu de place disponible dans un i-n?ud n'est pas suffisant pour stocker toutes les adresses de blocs, ce n'est pas un nouvel i-n?ud qu'il va chercher, mais carrément un bloc dans la surface des données sur le disque.
 

UFS permettait 3 indirections soit déjà 16 Go. À mon avis ça a plutôt augmenté, en fait je ne vois pas de raison de limiter le nombre d'indirections... La limite vient bêtement de la description de la taille du fichier et des adresses des blocs : maintenant on utilise des entiers de 64 bits au lieu de 32, ce qui a fait sauter la limite de 2 Go.
 

Pour une partition de 20 Go, ça fait 5242880 blocs, soit 655360 octets pour le bitmap. Pas si énorme...

Juste une question (c'est de là que vient ma confusion blocs/inodes) : comment un inode est-il limité en taille ? Je suis parti du principe qu'un inode faisait un bloc, mais c'est un peu con puisqu'il n'y a pas grand intérêt à faire une structure de blocs pour l'espace réservé aux inodes. Par contre, dès le second niveau d'indirection, c'est un bloc entier qui est adressé, et "l'inode de second niveau" (si on peut l'appeler comme ça) utilise effectivement un bloc ... non ?

A mon avis, la limite d'indirection est purement pratique, pour éviter une trop grande complexité dans le code (le récursif c'est toujours un peu dangereux, surtout pour un filesystem ) ... d'ailleurs, la doc Reiser4 n'en parle presque pas, il y est plutôt question de performances sur petits fichiers, partant du principe qu'un gros fichier gagne a être découpé en petit morceaux.

Effectivement ca fait peu
8 octets par bloc ... mais qu'est-ce qui nous bouffe toute la place sur le disque au formatage ? J'imagine le superblock et le bitmap (1Mo au plus ), mais surtout la table et les entêtes de fichiers non ?
 
 
Ce qui est sympa, c'est que ces infos vont pouvoir reservir pour le prochain fs d'Apple et de Microsoft, qui partiront semble-t-il aussi sur des principes similaires à ceux de Reiser4.
 
Pour les streams NTFS, ils doivent ressemble au format d'attributs de Reiser4 : chaque attribut se trouve dans un petit fichier accessible en utilisant le fichier comme un dossier (filename/..stat/owner par ex), et les plugins peuvent créer des attributs spécifiques avec des droits spéciaux, de même que d'autres programme peuvent y insérer des métadonnées. En gros ca doit être ça
 
... à ton avis, notre topic utilise les inodes étendus ?

Je crois que l'inode a une taille fixe ; d'ailleurs le nombre d'inodes est fixé au formatage.
 

C'est vrai que ça peut amener de sales trucs. Faudrait vérifier, mais je ne pense pas que ce soit un problème primordial dans la conception du FS.
 

C'est la table des inodes qui prend beaucoup de place, oui. En plus, il y a en général une portion du disque réservée au super-utilisateur, 5 % par défaut.

Mais ... les inodes d'indirection sont-elles d'une taille fixe, ou est-ce qu'on leur alloue tout seulement un bloc ?
 
Sinon, dans FAT, ce que l'on appelle véritablement FAT (la table quoi) est-elle comparable à la table d'inodes ? Je veux dire, est-ce que c'est si mal fait que la FAT soit simplement le bitmap, et qu'un fichier soit référencé par son premier bloc par un dossier, puis la fin de ce premier bloc pointe vers le second bloc occupé, et ainsi de suite jusqu'à la fin du fichier ... non ?
 
Et c'est pas con ça, les 5% au root

Bin ce sont des blocs de 4 Ko sur la surface du disque, et on en alloue autant que nécessaire.
 

Je ne me souviens plus exactement. En tout cas il n'y a pas de bitmap en tant que tel, et il me semble que toutes les métadonnées sont quand même regroupées dans la FAT, mais sous forme de listes chaînées.

Fred, pour la FAT, il me semble que le post de tetedeiench sur hardware (un des liesn + haut) la décrivait + précisement.

Bon, on a vraiment bien avancé sur le topic, merci à tous
 
Reste l'organisation des tables de correspondance path/clés et le balancing pour Reiser4 qui est encore un peu mystèrieuse, si vous avez une idée je suis vraiment preneur, sinon je vais poster sur la mailing list de Reiser4 ...
 
Je vais me matter le topic de tetedeiench ... mais je sais que dans mon exposé, je vais prendre ext comme exemple de fs de type blocs et non FAT

son 2° topic (toujours dans les liens que j'ai mis un peu plus haut) décrit justement (mais peut-être un peu succintement) l'ext2fs. avec la différence entre bloc, inode, vecteurs d'indirection etc.

btw, merci pour ta contribution, Mjules
 
Bon, j'ai relu avec attention et toute l'expérience que j'ai acquis (notamment dans ce forum, merci ) et voici les quelques nouvelles informations mais aussi questions qui me sont venues :
 

• Qu'est-ce que signifie "default tail policy" dans le début du document (c'est le terme 'tail' qui est mysterieux) ?
• Quel est le statut des dossiers, puisqu'ils sont référencés comme fichiers (pour les propriétés) et l'information qu'ils détiennent ne sont pas gardés dans l'arbre puisque tout les fichiers sont résolus avant de trouver leurs données dans l'arbre ?!?
• J'ai trouvé que le 'semantic layer', qui s'occupe de la résolution des paths en renvoyant les clés correspondantes, utilise un 'graph' plutôt qu'un arbre : qu'est-ce qu'un graph ?
• J'avais lu que Reiser sait très bien gérer les bad blocks, pourtant la doc officielle n'y fait pas référence ... si vous aviez des précisions
• Il est écrit que l'arbre qui renferme les clés 'grandit par le haut', c'est pourquoi on commence à numéroter par le bas. Par contre, lorsqu'on efface un ou plusieurs fichiers, l'arbre n'est plus équilibré non ?
• Pour l'histoire des extended pointers qui pointe vers un ensemble contigu de blocs, comment peut-on référencer un fichier qui ne tient pas sur une série contigue de blocs ?
• Est-ce que la vitesse de lecture/ecriture est différente suivant la position des têtes sur le disque (comme sur le CDRom) ?
• Les blobs sont bien une sorte de blocs d'indirection non ?
• J'ai lu sur le topic de tetedeiench que la FAT devait être lue entièrement pour lire un fichier, c'est à dire que la fin d'une série de blocs affectés à un fichier pointe directement vers la séquence suivante ? Il n'existe pas de système d'indoes sous FAT ?
• Qu'en est-il de XFS, JFS et tout ces autres systèmes de fichiers connus : quelles sont exactement leurs avantages ?

Ne vous inquietez pas, je vais également poser ces questions sur la devlist de Namesys, et j'espère qu'ils sauront me répondre
Dès que j'ai d'autres infos, je vous les poste.

Bon, pour les différences entre filesystems, j'ai trouvé :
http://www.osnews.com/story.php?news_id=69
 
Un beau clash en chief programmer ... m'enfin ca date de 2001.
 
Sinon, j'ai réussi à avoir le responsable release de Reiser4 (en une matinnée, incroyable ) sur la mailing list, voici les quelques infos que j'ai eu :

• Reiser4 ne sortira probablement que pour les kernels 2.5 et 2.6 (trop de changements entre 2.4 et 2.5, et Reiser4 est dev sur la 2.5). Ils feront un backport si nécessaire, mais ca demandera probablement pas mal de boulot ...
• Reiser4 sera probablement dans le kernel avec Reiser3, d'abord pour des raisons de compatibilité en lecture, et ensuite parce que Reiser4 doit se stabiliser un peu (souvenirs, souvenirs ...)
• En ce moment le dev est assez actif, ils sont en train de tunner l'algo d'alocation, donc pas trop de benchs en ce moment, et encore moins de release ... d'ailleurs les derniers patchs pour la 2.5.68 tarde à venir parce qu'ils ont l'air d'avoir quelques soucis de stabilité

Pour le reste, les dev devraient refaire leur apparition lundi, donc pour les questions plus techniques ca attendra encore un peu