info507 : système d'exploitation

TP3 : systèmes de fichiers

Hivers 2020

• Consignes

• Liens utiles

• 1. Programmation et fichiers

  • Préliminaires (facultatif)

  • 1.1. Blocs

  • 1.2. Taille des répertoires

  • 1.3. Taille des liens symboliques

  • 1.4. Fichiers creux

• 2. Un système de fichiers tout simple (??)

  • 2.1. Petite visite guidé du code fourni

    • 2.1.1. Architecture du projet

    • 2.1.2. Inodes

    • 2.1.3. Blocs de données

    • 2.1.4. Fonctions importantes

    • 2.1.5. Utilisation "bas niveau"

    • 2.1.6. Utilisation "haut niveau", libfuse

  • 2.2. Un premier exercice

  • 2.3. Amélioration du système de fichiers

    • 2.3.1. Liens physiques (facile)

    • 2.3.2. Liens symboliques

    • 2.3.3. Blocs à accès indirect

    • 2.3.4. Fichiers creux

  • 2.4. Pour aller plus loin

Consignes

Le rendu de ce TP se fera uniquement par TPLab et consistera en une archive (zip, tar, etc.) contenant impérativement l'arborescence suivante :

      TP3-votre_login/
         ├─ Makefile
         ├─ copy.c
         ├─ fcopy.c
         ├─ README
         ├─ ...
         ├─ ...
         └─ sfs/
             ├─ RAPPORT
             ├─ Makefile
             ├─ ...
             └─ ...

Attention :

• Chaque fichier .c doit contenir une entête avec votre nom / prénom ainsi que les réponses aux questions et vos remarques pertinentes.

• Makefile doit compiler tous vos fichiers C (vous pouvez vous inspirer de ce fichier Makefile), (si vous ne connaissez pas les fichiers Makefile, je vous conseille de suivre ce tutoriel)

• votre Makefile doit compiler les programmes C avec les options --std=c99 -Wall -Wextra -pedantic -Werror,

• votre code pour la deuxième partie (SFS) doit compiler avec le fichier Makefile fourni (options --std=gnu99 -D_FILE_OFFSET_BITS=64 -Wall -Wextra -pedantic -Werror -Wno-unused-parameter)

• sfs/RAPPORT doit être un fichier texte contenant vos réponses et commentaires pertinents concernant la seconde partie du TP. Vous donnerez notamment l'état d'avancement de votre code par rapport aux questions du TP.

Liens utiles

• l'archive du TP : sfs.tar

• encadrant de TP : Pierre.Hyvernat@univ-smb.fr, Francois.Boussion@univ-smb.fr et Gerald.Cavallini@univ-smb.fr

1. Programmation et fichiers

Préliminaires (facultatif)

$ man 3 read
$ man 3 fwrite

Le langage C offre deux interfaces pour les fichiers :

• une interface bas niveau avec les fonctions open, close, write, read et lseek ;

• une interface haut niveau avec les fonctions fopen, fclose, fwrite, fread et fseek.

Dans le premier cas, les fichiers sont représentés par un entier appelé descripteur de fichiers, et dans le second cas, par un élément du type FILE.

  int fd = open(..., ... | O_CREAT, 0644);

$ man sys_stat.h

1.1. Blocs

Chaque partition d'un support de stockage utilise un système de fichiers. Sous Linux, le système de fichiers le plus courant est ext4 (successeur de ext2 et ext3).

Tous les systèmes de fichiers "interactifs" découpent les fichiers en blocs de taille fixe. La taille d'un fichier peut donc vouloir dire deux choses distinctes :

• le nombre d'octets de données du fichier : c'est ce qui est affiché par la commande ls -lh,

• le nombre d'octets occupés par le fichier sur le support : c'est ce qui est affiché par la commande ls -sh.

1.2. Taille des répertoires

1.3. Taille des liens symboliques

$ ln -s <CHEMIN> <LIEN>

1.4. Fichiers creux

En général, la taille des données est plus petite que la taille occupée sur le support, qui est toujours un multiple de la taille des blocs.

Les fichiers creux (sparse files en anglais) sont une exception. Un tel fichier peut contenir des trous. Le plus simple pour créer un fichier creux est de suivre la procédure suivante :

1. ouvrir un fichier en écriture

2. écrire quelques octets au début (facultatif)

3. se déplacer pour dépasser la fin du fichier (fonction lseek)

4. écrire quelques octets au nouvel emplacement

5. fermer le fichier

En C :

    int size = 1<<20;  // 1 Mio
    char* start = "start\n";
    char* end = "\nend";
    int fd = open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0644);
    write(fd, start, strlen(start));
    lseek(fd, size - strlen(end), SEEK_SET);
    write(fd, end, strlen(end));
    close(fd);

2. Un système de fichiers tout simple (??)

La seconde partie du TP consiste à regarder les sources d'un système de fichiers très simple, créé pour l'occasion, appelé SFS (Simple FileSystem). L'objectif est de rajouter quelques fonctionnalités à ce système de fichiers.

Il s'agit d'un système de fichiers basé sur une notion simplifiée d'inode. Les volumes SFS sont en fait simplement stockées dans des fichiers standards. Un volume SFS peut donc être vu comme une archive contenant une arborescence de fichiers / répertoires.

$ sudo apt install libfuse-dev rlwrap

2.1. Petite visite guidé du code fourni

L'archive contenant le code fourni se trouve ici.

2.1.1. Architecture du projet

Le répertoire sfs contient les fichiers suivants

Makefile

pour compiler les sources

sfs.h

contenant les définitions de types et macros globales

sfs_parameters.h

contenant les paramètres fixes des systèmes de fichiers SFS. Vous pouvez si vous le souhaitez changer les valeurs des trois paramètres de base.

sfs_log.[ch]

contenant une petite fonction de log pour enregistrer des informations de debug dans un fichier (sfs.log par défaut)

sfs_volume.[ch]

contenant la gestion de la partition SFS (contenue en fait dans un fichier Unix)

sfs_low_level.[ch]

pour le code bas niveau : manipulation des blocs et des inodes, écriture et lecture, etc.

sfs_posix.[ch]

contenant le code haut niveau : Autant que possible, les fonctions dans ces fichiers utilisent le même prototype que les appels système correspondant aux appels système POSIX usuels. Par exemple, la fonction sfs_write utilise le même prototype que la fonction write...

sfs_shell.[ch]

contenant un petit shell interactif pour manipuler les systèmes de fichiers SFS

sfs_fuse.[ch]

contenant les définitions nécessaires pour utiliser un système de fichiers SFS avec libfuse

Vous ne devez normalement modifier que le fichier sfs_low_level.c.

2.1.2. Inodes

SFS est basé sur le type d'inodes suivant (fichier sfs_volume.h):

  typedef struct inode {
      int type;                         // inode type: S_IFREG, S_IFDIR, S_IFLNK
      int size;                         // size of the corresponding file in bytes
      int nlinks;                       // number of hard links to this inode (0 means the inode is free)
      int blocks[NB_DIRECT_BLOCKS+2];   // blocks for the data (last 2 blocks for single / double indirection blocks)
  } inode_t;

Les constantes S_IFREG ("regular file"), S_IFDIR ("directory"), S_IFLNK ("symbolic link") et NB_DIRECT_BLOCKS sont définies dans le fichiers sfs_volume.h.

Chaque inode est représenté par son numéro (type int), avec les constantes suivantes :

• l'inode 0 n'est pas utilisé,

• l'inode 1 (constante BADBLOCKS_INODE) pourrait servir à référencer les blocs défectueux,

• l'inode 2 (constante ROOT_INODE) est l'inode de la racine de la partition.

2.1.3. Blocs de données

Les blocs de données sont représentés par des tableaux :

// size (in bytes) of blocks
#define BLOCK_SIZE 512

// type synonym for "raw" bytes
typedef unsigned char byte;

// type synonym for blocks
typedef byte block_t[BLOCK_SIZE];

2.1.4. Fonctions importantes

Les blocs et les inodes sont représentés par des entiers (positifs). Les fonctions sfs_get_inode / sfs_get_block prennent un argument entier et renvoient un pointeur vers l'inode / bloc correspondant.

Attention, ces fonctions ne font aucune vérification sur l'entier qui leur est fourni. Si vous les utilisez avec des entiers trop grands (ou négatifs), le résultat n'est pas spécifié et votre programme risque de provoquer une erreur de segmentation.

2.1.5. Utilisation "bas niveau"

La compilation produit un exécutable sfs_shell qui lance un interpréteur pour lancer des commandes sur les systèmes de fichiers SFS :

$ ./sfs_shell <FILE>

lance ce shell et monte automatiquement la "partition" SFS contenue dans le fichier FILE. (Il faut auparavant avoir créé la partition SFS dans le fichier FILE comme expliqué plus bas.)

Les commandes disponibles dans sfs_shell sont brièvement décrites par la commande help (ou ?). Il s'agit essentiellement des commandes du fichiers sfs_low_level.c. Vous pouvez par exemple :

• créer une partition

• afficher un inode

• afficher le contenu d'un bloc (en mode data, adresses ou entrées de répertoire)

• afficher la bitmap des blocs libres

• ...

$ rlwrap ./sfs_shell [FILE]

2.1.6. Utilisation "haut niveau", libfuse

La compilation produit également un exécutable sfs_fuse.

libfuse est une bibliothèque pour créer des systèmes de fichiers sans modifier le noyau Linux. Il suffit de programmer les fonctions de bases comme open, read, mkdir, (cf fichier sfs_posix.[ch]) etc. et il est possible de manipuler un système de fichiers "virtuel" (comme SFS) comme un système de fichiers réel. Par exemple, la commande cp sur un système monté avec libfuse utilisera automatiquement les fonctions fopen , fread et fwrite correspondantes...

$ tail -f ./sfs.log

Pour faciliter les tests, l'archive contient un script test-fuse.sh qui fait les choses suivantes :

1. compile SFS

2. créé un volume SFS dans le fichier TEST.sfs (avec la commande sfs_shell)

3. monte le volume TEST.sfs dans le répertoire TEST (avec la commande sfs_fuse)

4. démonte le répertoire TEST lorsque que le shell se termine (avec la commande fusermount -u ...)

2.2. Un premier exercice

2.3. Amélioration du système de fichiers

Pour la suite du TP, vous allez implanter des fonctionnalités manquantes au système de fichiers.

Les fonctionnalités à ajouter sont données par ordre croissant de difficulté mais sont indépendantes les unes des autres.

2.3.1. Liens physiques (facile)

Il s'agit d'ajouter la gestions des liens physiques sur les fichiers.

$ ln <TARGET> <LINK>

2.3.2. Liens symboliques

Il s'agit maintenant d'ajouter la gestions des liens symboliques sur les fichiers. Les liens symboliques sont représentés par des inodes de type S_IFLNK.

Un lien symbolique n'a pas de données réelles mais doit contenir un chemin d'accès cible.

$ ln -s <TARGET> <LINK>

2.3.3. Blocs à accès indirect

Actuellement, les blocs de données associés à un inode dans SFS sont tous à accès direct. Le tableau blocks d'un inode contient NB_DIRECT_BLOCKS cases référençant des blocs de données. La taille maximale d'un fichier est donc égale a NB_DIRECT_BLOCKS * BLOCK_SIZE, soit quelques kibioctets...

Pour augmenter légèrement la taille possible des fichiers, nous allons ajouter la gestion de blocs indirects. Le tableau blocks d'un inode contient une case supplémentaire, actuellement non utilisée. Lorsque cela est nécessaire, cette case sera utilisée pour référencer un bloc contenant BLOCK_SIZE / sizeof(int) blocs de données.

2.3.4. Fichiers creux

Les systèmes avec inodes permettent de créer des fichiers creux : il suffit de mettre un numéro de bloc spécial qui n'est pas alloué sur le support. Les opérations de lecture sur un tel bloc renvoient des 0, et les opérations d'écriture vont provoquer l'allocation d'un vrai bloc...

Pour SFS, nous allons utiliser le numéro de bloc ZERO_BLOCK (constante définie à 0) pour représenter un bloc de 0 non alloué... (Plus précisément, ce bloc est alloué mais en "lecture seule".

2.4. Pour aller plus loin

Remarques sur la page (ou le sujet) : contact.
mentions légales

,

Dernière révision: le 02-12-2020 à 09:14.