IT-202 Système de fichiers avec étiquettes - Réalisations

ENSEIRB-MATMECA
Filière informatique, 2ème année
Projet de Système d’exploitation
IT-202
Système de fichiers avec étiquettes
Bastien COEURET
Mohammed RIHANI
Maxence RONZIÉ
Vincenzo SCALZI
Eya WESLATI
Encadrant Marc Sergent
Mai 2016
Systèmes d’exploitation
Enseirb-Matmeca
Table des matières
1 Introduction
3
2 Les fonctionnalités implémentées
2.1 Base de données . . . . . . . .
2.1.1 Implémentation . . . . .
2.1.2 Performances . . . . . .
2.2 Fonctions FUSE implémentées .
.
.
.
.
3
3
3
4
5
3 Tests
3.1 Tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Tests de performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
6
7
4 Conclusion
7
.
.
.
.
.
.
.
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Systèmes d’exploitation
Enseirb-Matmeca
1 Introduction
Les systèmes d’exploitation sont des éléments primordiaux de l’environnement informatique. Ils représentent une couche de base au-dessus de laquelle fonctionne l’environnement logiciel de la machine et en-deçà de laquelle agit l’environnement matériel de la
machine. Un problème dans cette couche peut être critique pour l’intégralité du système,
c’est pourquoi un grand soin doit y être porté.
L’intérêt de ce projet est avant tout de mettre en pratique les connaissances acquises
dans le domaine des systèmes d’exploitation, en plus de sensibiliser au travail dans un
environnement de développement instable et prendre conscience de l’impact de la solution
par rapport à l’utilisation qui en résulte.
Ce rapport met en lumière le déroulement de ce projet de systèmes d’exploitation.
Dans un premier temps, il sera question de l’implémentation. Ensuite, nous parlerons
des tests (unitaires et de performances).
2 Les fonctionnalités implémentées
2.1 Base de données
L’objectif de la base de données implémentée est la gestion des fichiers et des tags qui
leur sont attribué. Lors du montage des fichiers virtuels, un fichier de données du contenu
des répertoires est parsé et les informations récupérées sont stockées dans cette base de
données. Après utilisation, la base de données est stockée dans un fichier sous le format
imposé.
2.1.1 Implémentation
Comme déjà mentionné dans le rapport intermédiaire, il a été question d’implémenter
la base de données avec des opérations se faisant en complexité raisonnable, notamment
en tirant profit de la table de hachage recommandée par le sujet : uthash.
Nous avons donc utlisé plusieurs tables de hachage afin de pouvoir avoir des traitements, d’une part équivalents dans les deux sens, de tag et de f ile, et d’autre part avec
des complexité en temps optimales.
De plus, nous avons aussi utilisé utlist, une implémentation de liste chainée fournie
dans la bibliothèque uthash, pour stocker les tag et les f ile permanents.
Note Il est à noter la distinctions qui est faite entre un tag (resp. un fichier) général, qui
est appliqué à tous les fichiers (resp. tags) existants, et un tag (resp. fichier) permanent,
qui est non seulement appliqué à tous les fichiers (resp. tags) existants, mais aussi à ceux
qui seront crées (tant que ce tag (resp. fichier) permanent n’est pas retiré).
3
Systèmes d’exploitation
Enseirb-Matmeca
Figure 1 – Diagramme UML de la base de données
2.1.2 Performances
Nous avons fait le choix de représenter les fichiers avec leurs tags parallèlement aux
tags avec leurs fichiers. Ce choix est justifié bien qu’il cause des redondances mémoire ; il
assure un gain de performances pour une consommation mémoire légèrement plus grande.
Ainsi, en utilisant exclusivement des tables de hachage dans le stockage des fichiers
et de leurs tags, et inversement des tags et de leurs fichiers, on a reussi à atteindre
des compléxité en temps intéréssantes. Et notamment, en tirant profit des fonctions de
recherche, d’ajout et de suppression de uthash. En effet, ceux-ci se font en temps constant.
Comme mentionné plus haut, les traitements des tag et des f ile sont similaires, entre
autre au niveau de la compléxité en temps dans le pire des cas.
Ci-dessous une liste non exhausive des traitements des tag et de leur compléxité en
temps dans le pire des cas.
— ajouter un tag, O(nombre_de_f ichiers_permanents).
— ajouter un tag permanents, O(M ax(nombre_de_f ichiers, nombre_de_tags_permanents)).
— ajouter un tag général (appliqué à tous les fichiers existants), 0(nombre_de_f ichiers).
— ajouter un fichier relatif à un tag, O(1).
4
Systèmes d’exploitation
Enseirb-Matmeca
savoir si un tag est général (appliqué à tous les fichiers existants), O(1).
savoir si un fichier est relatif à un tag, O(1).
rechercher d’un tag, O(1).
rechercher d’un fichier relatif à un tag, O(1).
rechercher les fichiers en communs relatifs à n tags,
O(minn (nombre_de_f ichiers_relatif s_tagn )).
— supprimer un tag, O(nombre_de_f ichiers_relatif s).
— supprimer un tag permanent, O(nombre_de_tags_permanents).
— supprimer un fichier relatif à un tag, O(1).
—
—
—
—
—
Les traitements sur les fichiers sont analogues.
2.2 Fonctions FUSE implémentées
Dans le but de pouvoir manipuler la base de données et de mettre en place le système
de fichier souhaité, nous avons implémenté les fonctions suivantes en les renommant :
— getattr : qui est la fonction la plus appelé du système de ficher pour récupérer des
informations sur les fichiers
— mkdir : pour créer un nouveau tag dans la base de données
— rmdir : pour supprimer un tag dans la base de données
— readdir : est appelé quand on fait appelle à la commande ls pour afficher les résultats
— unlink : la fonction pour supprimer un lien entre le tag et le fichier
— rename : est appelée quand on souhaite remplécer un tag sur un fichier par un autre
Parmi ces fonctions, celle que nous avons eu le plus besoin de remanipuler fut la fonction getattr car à chaque fois que nous implémentions une des autres fonctions, il fallait
que getattr puisse faire des vérifications supplémentaires et complémentaires.
Pour plus de facilité lors du développement de ces fonctions, nous avons écrit trois
autres fonctions communes. La première permet de décomposer les tags dans une chaine
de caractère et de les stocker dans une structure, qui est un tableau de chaînes de caractères de la bonne taille alloué dans cette fonction (la structure à remplir étant passée
en paramètre). La seconde fonction est celle qui permet de libérer la mémoire allouée
pour la structure précédente. La dernière est en fait un test pour savoir si une chaine de
caractère est composée d’un seul tag ou pas.
Nous avons passé beaucoup de temps pour analyser les appels aux fonctions que fait
FUSE quand nous entrons telle ou telle commande. Un autre point qui nous a donné
5
Systèmes d’exploitation
Enseirb-Matmeca
du fil à retordre est le développement de la fonction getattr car il a fallu l’adapter à
chaque étape de l’avancement du projet. Une autre fonction qui a nécessité un temps
de développement conséquent est la fonction readdir qui est appelée quand nous lançons
la commande ls. Cette fonction doit pouvoir faire une sélection dans les informations
fournies par la base de données pour les analyser et les afficher dans un certain ordre
pour respecter les conventions.
Le problème principal est qu’une telle application est très gourmande en bases de données. Un appel à readdir provoque des éventuels appels à la base de données pour savoir si
chaque étiquette existe, puis pour récupérer les fichiers communs à toutes les étiquettes et
faire l’union des étiquettes en commun sur les fichiers restants et retirer les étiquettes de
la requête. L’affichage consiste uniquement à afficher les fichiers et tags des listes générées.
Malgré des idées très claires et un code prêt à accueillir les dernières fonctions de la
base de données, nous n’avons pas réussi à implémenter ls comme il se doit. Ce qui n’est
pas le cas pour les autres fonctions, beaucoup plus simples à développer.
En effet, les possibilités offertes par la base de données, qui n’ont pas toutes été exploitées pour laisser des ouvertures au sujet, ont permis de très rapidement construire les
appels demandant des vérifications très simples comme mkdir et rmdir, qui ajoutent et
suppriment des étiquettes. Ces fonctions peuvent facilement être étendues pour permettre
la création ou suppression de plusieurs étiquettes. Cela n’a pas été fait car cette fonctionnalité est déjà offerte par FUSE. Il suffit en effet de séparer les noms des étiquettes
à créer par des espaces pour en créer plusieurs.
3 Tests
3.1 Tests unitaires
Au même rythme que l’écriture des traitements, on a écrits des tests unitaires fonctionnels afin de vérifier notre réalisation.
Nous avons implémenté les tests pour plusieurs fonctions importantes. Les tests réalisés
sont solides. Nous avons traité tous les cas d’erreurs possibles liées à la base de données.
Parmi ces tests on peut citer quelques uns que nous avons estimé pertinents :
— Les fonctions de bases telles que add_new_g_tag qui ajoute un tag général i.e
qui ajoute un tag à tous les fichiers, existants et futurs. Similairement à ceci, la
fonction add_new_g_file. Nous testons bien que le tag ou le fichier ajouté existe
une seule fois dans la base et non pas autant de fois que le nombre de fichier ou de
tag.
— dans la fonction add_tag_to_file et similairement add_file_to_tag, nous testons
que ce fichier ou ce tag n’est appliqué qu’au fichier ou tag indiqué et non pas à tous
les autres fichiers et tags.
6
Systèmes d’exploitation
Enseirb-Matmeca
— Quand on applique un tag à un fichier qui n’existe pas ou un fichier à un tag qui
n’existe pas, on vérifie bien que ce tag ou ce fichier appliqué n’est pas rajouté à la
base puisque il est appliqué à quelque chose qui n’existe pas.
— quand on a des tags appliqués à plusieurs fichiers et qu’on supprime ce tag d’un
des fichiers, on vérifie que le tag a été retiré juste au fichier bien précis et non pas à
tous les fichiers auxquels il est appliqué. La même chose a été faite pour les fichiers
appliqués au tag.
De plus, une interface à été developpée pour la base de données, qui complète les tests
unitaires, et sert pour le debogage.
3.2 Tests de performances
Pour mesurer les performances, nous avons utiliser les programmes fournis :
— perf s_1tag_N f ichier qui tag, change le tag et dé-tague N fichier.
— perf s_N tags_1f ichier qui créer N tags, taguer un même fichier avec ces N tags,
puis qui supprime les tags.
Constats
La création de tag est linéaire en fonction du nombre de tag permanent, et donc dans
le cas où il n’y a pas de tag permanent, l’opération se fait en temps constant. L’opération
de suppression est linéaire en fonction du nombre de fichiers relatifs au tag à retirer.
Parmi les opérations où on se distingue :
— l’ajout de tags qui se fait en temps linéaire par rapport au nombre de fichiers
permanents, indépendemment du nombre de tags.
— l’ajout de tags à un même fichier qui se fait en temps constant indépendemment
du nombre de tags.
— la suppression de tags relatifs à un fichier qui se fait en temps constant indépendemment du nombre de tags.
4 Conclusion
Ce projet nous a permis de travailler en équipe sur un système permettant à un utilisateur sans privilèges particuliers d’accéder à un système de fichiers sans modifier les
sources du noyau. Le début a consisté en une période de recherche et de documentation,
et notamment sur FUSE, puis nous avons réparti le travail à effectuer parmi les membres
de l’équipe, avec deux tandems, pour evoluer en parallèle sur l’implémentation de la base
de données et sur la prise en main de FUSE.
Chacun a pu profiter du savoir des autres membres du groupe. Nous avions tous une
expérience du C différente, il était intéressant de chercher à accorder nos notations et
nos méthodes.
7
Systèmes d’exploitation
Enseirb-Matmeca
Nous avons réalisé une base de données avec des traitements optimisant la mémoire et
la complexité en temps, qui nous fournissent des solutions acceptables.
En effet, la majorité des accès/manipulations avec notre base se font soit en temps
constant soit en linéaire, et ce grâce aux tables de Hachage mises en place dans les deux
sens (tags et fichiers).
De plus, toutes les commandes ont été implémentés.
Finalement, malgré une forte contrainte de temps, nous avons réussi à faire une partie
essentielle du projet. Et ceci en le rendant assez général, et en ne n’ayant à l’idée aucune
contrainte telles que le nombre de tags, le nombre de fichiers ou le nombre de fichiers
relatifs à un tag...
8