IT-202 Système de fichiers avec étiquettes - Réalisations
Transcription
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