Nov 162009
 

Bonjour,

Et bien, voici enfin la dernière release des specs de SFS, qui s'avère complète.

Plus qu'une simple specs, il s'agit d'une initiation a la structure d'un filesystem. Voici donc un bref résumé.

Inode Table

La table des inodes, où sont stocker toute les métadonnées des fichiers. On trouveras les valeurs particulières correspondant au mode ainsi que divers détaille sur son allocation etc...

Directories

La structure des dossiers, qui permettent de stocker des noms de fichier de taille variable et leur lien avec les inodes. La pluspart des filesystem sont construit sur le même modelé mais avec des noms de fichier a taille fixe.

Bref, sans plus attendre, voici le pdf : sfs.pdf

Nov 102009
 

Bonsoir,

Comme promis, je publie ce soir ces quelques pages fraichement rédigées, agrémentées de deux schémas dont je suis plutôt fier, car représentatifs à la fois des données physiquement présentes (de simples bits), et de toute la portée sémantique qui leurs sont associé.

Un petit résumé sur les :

Inode/Block BitMap

Comme leurs nom l'indiquent, et on ne le répètera jamais assez, ce sont de simples cartes où chaque inode/block est représenté par un bit, actif ou inactif selon si l'inode ou le block est actif/inactif. Le bit n est associé au block/inode n. La forte quantité d'informations stockée dans peut d'espace permet une recherche rapide du prochain block/inode libre et est donc capital pour ne pas dégrader les performances.

SFS? Pas seulement!

Le concept de bitmap n'est pas nouveau, ni déprécié. Il était déjà employé dans minix et on le retrouve dans ext2/ext3 qui sont, pour ceux qui l'ignorerai encore, les systèmes de fichier de prédilection des distributions linux. (A vrais dire, a part cramfs, qui sert à monter une image en lecture d'une archive compressée, je ne connais pas de filesystem sans bitmap)

Je vous remet donc,  la seconde révision des specs de SFS : SFS.pdf