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

 

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

 

Bonsoir,

Cela fait maintenant plus d'un mois que je dissimule a la plupart d'entre vous, lecteur, le projet sur le quel je concentre toute mon attention depuis septembre.

Ce projet, est un projet plain de rebond, et je crains avoir a plusieurs reprise sous estimer le travaille nécessaire. Je suis toute fois heureux de vous annoncer que je suis en possession d'une implémentation qui, bien qu'instable, s'avère déjà partiellement fonctionnelle.

Je travaille actuellement sur un FileSystem et son implémentation dans le kernel Linux. Plus qu'un system de fichier, SFS seras avant tout un exemple claire et concis de filesystem, une sorte de journal de bord d'un voyageur qui tenta de traverser la jungle des filesystem et qui du affronter les plantes carnivores mangeuses d'inodes, les dangereux marais aux mémoires mouvantes, les lianes empoisonnés des dentries... bref, un périple qui pourrais presque donner lieux à une nouvelle.

Mais commençons par l'origine, le point de départ de ce projet, qui bien que n'aillant jusque la jamais été rédiger, est rester a chaque instant dans mon esprit :

Qu'est ce que SFS?

Simple File System : Simple système de fichier.

SFS se veut une implémentation d'un système de fichier élémentaire, baser sur une logique simple, une approche simpliste dans le but de réduire un maximum la complexité de l'implémentation pour une meilleur compréhension des couches d'abstraction du kernel linux.

Ainsi, il est de mon devoir, avant de publier une quelconque implémentation, d'établir les Specs de ce filesystem.

Le SuperBlock

Mais il y a tellement a dire, tellement de détaille indispensable a la bonne compréhension d'un filesystem. Tellement que je ne peux tout ecrire en une soirée. Alors, je vous propose le premiers chapitre des Specs de SFS : Le SuperBlock. C'est très certainement le plus court de tous les chapitres, étant donner que - selon moi - le superblock est au filesystem ce qu'est le préface à un roman.

Voici donc la première révision des specs de SFS : SFS.pdf

Je suis ouvert a tout commentaire :)

 

Utiliser goto, ou ne pas l'utiliser?

Voila une question qui déchaine les programmeurs de tout âge et de toutes philosophies.

Code plus crade, code plus propre. Code plus optimisé, code moins performant... Perte/Gain sémantique... Ce sont à la fois les arguments et contre arguments des deux camps.

Peut-être êtes vous surement de l'avis de nombre d'étudiants et de professeurs qui considèrent goto comme un reste d'une instruction passé, n'aillant plus la moindre utilité dans un langage comme le C, qui se veut un peu plus éloigné de la machine que l'ASM. Ou êtes vous alors de ces gens perplexes qui ne font que constater que le code du kernel linux en est truffé, et que ce ne doit pas être sans raisons?

Et bien, à moins que vous ne soyez un fervent partisan du goto, je vous conseille de lire cette article :  Le code et ses raisons: Goto en C

Voila de quoi méditer sur ce petit mot qui a fait couler tant d'encre.

 

Le profilage de code est l' operation qui consiste a analyser un programme affin de repérer les portions qui prennent le plus de temps et de les refactoriser pour en améliorer les performances.

Il existe trois diferentes methodes :

  • - Par echantillonage :
    On mesure tout les n instants la fonction courante. Ainsi on peu aproximativement en deduire le temps passer dans chaque fonctions.
  • - Par instrumentation :
    En modifiant le code du programme pour remplacer chaque apelle par une fonction d' instrumentation qui mesureras divers valeurs en utilisant des compteurs interne au processeur.
  • - Par émulation :
    Le programme est exécute sur un processeur virtuel. Tout est alors mesurable pour le processeur émuler. (Mais le processeur émuler n'est pas celui de la machine hôte)

La premiere methode est asse aproximative. La seconde modifi le code et fausse donc les resultats, mais ils sont bien plus precis.

La troisime donne des resultats parfais, mais pour le processeur emuler, et non le processeur de la machine ou le programme devrais tourner. De plus cette methode est extremement lente (Il est difficile d' imaginer emuler un processeur plus rapide que le processeur qui effectue cette amulation)

Visual studio permet des mesures par echantillonage et instrumentation.
Sous *nix, valgrind est une suite d'outils capable d'effectuer de nombreuses mesures et pouvant aller jusqu'a l'emulation de processeur.

Ressource : http://matthieu-brucher.developpez.com/tutoriels/cpp/profil-valgrind-visual-studio/?page=visual_studio

© 2012 Zenol's Blog Suffusion theme by Sayontan Sinha