Dokuwiki

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== 1. Le jargon ======

Ce chapitre se propose de passer en revue une liste à la Prévert des différentes notions que l'on rencontre inévitablement en s'intéressant de près aux systèmes de fichiers.

===== VFS =====

Le //Virtual File System// est l'épine dorsale du système Unix. Il décrit une structure arborescente de fichiers et de répertoires qui est unique pour l'ensemble du sytème, et possède donc en particulier une seule racine dénommée **/** (slash).

Ce système de fichier est appelé //virtuel// car il repose en fait sur l'assemblage de système de fichiers réels ou physiques (basés sur des ressources locale - mémoire, disque - ou distantes - réseau), qui apportent chacun leur propre hiérarchie de fichiers via les //points de montage// (voir plus bas).

Certains systèmes (MS Windows et MacOS "Classic") possèdent des //VFS// avec plusieurs racines, dans ce cas il y a très peu de distinction entre le //VFS// et les systèmes de fichiers physiques (même si cette abstraction existe toujours dans un OS, même antédiluvien comme MS/PC-DOS).

===== Charset, locale, codepage =====

Ces notions recoupent les règles d'encodage des caractères symbolique en suite d'octet.

Un VFS Unix est agnostique vis-à-vis de cet encodage car il n'a pas besoin d'interpréter les symboles, il se contente de comparer ce qu'on lui demande à ce qui est sur le système de fichier physique correspondant. **Mais** il existe une exception de taille, il doit être capable de reconnaitre les symboles **/** et **.** qui ont une signification structurelle.

La vaste majorité des jeux de caractères utilisant un octet par symbole (ISO-8859-, CP-xxx) sont des sur-ensemble d'ASCII, et sont donc d'accord sur le codage de **/** et **.**. Mais pour les encodages multi-octets (UTF-x, SJIS, GB-2312) cette relation n'est plus triviale et le VFS doit savoir interpréter correctement les symboles. **Note**: le problème est éludé dans le cas d'encodage intelligents comme UTF-8 (exception: Windows).

Enfin, la notion d'encodage intervient si un système de fichier est dit "insensible à la casse". Dans ce cas les symboles doivent être explicitement interprétés par le système. Les mécanismes peuvent être complexes, l'interprétation de la casse étant variable suivant les nationalités (d'où la notion de //locale//). **Note**: cette notion peut intervenir pour les tris (alphabétiques), mais elle ne concerne pas le VFS mais les applications (exception: Windows).

===== Point de montage =====

Il s'agit d'un chemin dans le VFS (nécessairement un répetoire) auquel on "raccroche" un système de fichier réel. Comme le point de montage doit pré-exister au montage, on est obligé de monter en premier le système de fichier **racine** (point de montage **/**).

Suivant les systèmes d'exploitations, on peut combiner les systèmes de fichiers dans le VFS de façons variées et complexes. Quelques "trucs":
  * **root pivot**: en général un système boote d'abord sur un système de fichier racine minimaliste seulement présent en mémoire assurant l'initialisation des périphériques. Une fois le disque physique détecté et le système de fichier adéquat repéré, il remplace de manière immédiate le système monté à la racine (par mesure de sécurité ceci ne peut être fait qu'une fois).
  * **bind mount**: avec ce mécanisme il est possible de monter un système de fichiers plusieurs fois et à des endroits divers du VFS, y compris sur lui-même
  * **user mount**: un point de montage prédéfini qui peut être monté et démonté par n'importe quel utilisateur, en général utilisé en combinaison avec un mécanisme de type //automount//.

===== Liens hard et symboliques =====

Un lien est un fichier (au sens large: fichier ou répertoire) qui en désigne un autre, et peut être utiliisé de manière transparente comme si l'on manipulait ce fichier cible.

Un lien symbolique est un lien qui référence sa cible par son chemin dans le VFS. Si le système de fichier sous-jacent le supporte, il est possible d'établir un lien symbolique vers n'importe quelle cible, y compris si celle-ci n'existe pas à la création du lien.

Un lien hard est une copie "bas niveau" (voir **inode** plus loin) de la référence du système de fichier (on peut l'assimilier à un pointeur). Une fois créé, on **ne peut pas distinguer** le fichier de son lien hard. Intérêt: on peut faire des copies "légères" (structure uniquement) d'arborescences complètes. Inconvénient: ne fonctionne que pour des références à l'intérieur d'un même système de fichiers, traçabilité délicate, sémantique délicate.

===== Méta-données =====

Toutes les données autre que celles stockées explicitement dans le fichier sont appelées méta-données. Leur distinction est importante pour la plupart des systèmes de fichiers, et celles-ci concentrent tous les problèmes d'interopérabilité. Exemple:
  * Nom du fichier
  * Taille du fichier
  * Type (fichier, répertoire, lien, device, ...)
  * Dates d'accès, de modification, d'écriture
  * ...

**Note**: sous Unix on obtient la plupart des métadonnées (sauf ACL et attributs étendus) avec stat. Voir aussi lsattr.

===== Block =====

L'unité d'adressage de base d'un système de fichier est le "bloc" (en anglais avec un **k** final). Cela signifie que l'allocation, la lecture et l'écriture ne pourront se faire que par blocs entiers. Il s'agit en définitif d'un compromis entre granularité et optimisation de l'espace disque.

Sur un système dont le bloc fait 4096 octets, stocker 20,000 fichiers de moins de 4KB occupera indifférement 20,000 * 4B = 80 MB. On obtient l'espace disque utilisé avec **du** (chiffre qui majore donc toujours la taille des fichiers stockés).

Cette unité à également un impact sur l'espace disque adressable sur les systèmes traditionnels 32bits (qui utilisent en général des entiers signés). En effet, on pourra adresser **2^31 * taille bloc**, par exemple 2TB pour un bloc de 1KB.

===== Superblock =====

Il s'agit d'un bloc spécial réservé par le système de fichiers et qui contient des données globales et vitales, notamment le point de départ de la structure arborescente du système de fichier. Ce bloc est en particulier lu lors du montage du système de fichier en question. En général, un système de fichier en maintient plusieurs copies et est capable de détecter la corruption de l'une d'elle.

**Note**: ceci est appelé //FAT// (File Allocation Table) dans le monde DOS/Windows.

**Note**: à ne pas confondre avec les superblocks RAID et LVM, qui remplissent des fonctions similaires (stocker des informations globales décrivant un espace de stockage) mais à leur niveau.

===== Inode =====

Ce terme désigne l'adresse (en général le numéro du bloc) de "stockage" d'un fichier (au sens large) dans un système de fichiers. En conséquence, un "hard link" vers un fichier A et le fichier A lui-même sont associés au même //inode//.

En des termes réseau, il s'agit d'une adresse numérique, qui peut être associée à plusieurs adresses alphanumériques (des noms de fichiers, établis à la création ou par link hard et symbolique). Quelques applications utilisent cette information pour savoir si un nom de fichier correspond toujours au même fichier sous-jacent (ex: analyse de logs et détection de rotation, détection d'intrusion, etc.).

===== FSCK =====

"File System ChecK". Chaque système de fichier est toujours accompagné d'un outil permettant de vérifier l'intégrité du système de fichier, et le cas échéant effectuer d'éventuelles réparations. C'est souvent un élément majeur à considérer dans la robustesse d'un système de fichier.

FSCK contribue aux tâches de maintenance d'une part, et à la récupération lors de crashes ou coupures d'alimentation impromptues. Il peut donc parfois pallier les propres déficiences du système de fichier (fuites d'allocations d'inodes, inconsistences locales dans la structure arborescentes, etc), et surtout restaurer un état fiable à partir d'un état inconnu après un crash.

L'utilisation de cet outil est en général assez délicat: quand une erreur est détectée, on peut l'ignorer et s'exposer à des surprises plus tard (corruption de données, kernel panic, etc), ou demander une réparation immédiate mais sans savoir exactement quelle information a été perdue ou récupérée.

**Note**: voir la fameuse option FSCKFIX dans **/etc/default/rcS** chez Debian.

===== Journal =====

Les sytèmes de fichiers journalisés empruntent l'approche "transactionnelle" classiquement utilisée par les bases de données. L'idée est de garantir que le système de fichier soit toujours dans un état connu et stable meme si une opération n'a été effectuée que partiellement (crash, panne de courant, etc).

Le principe consiste à modifier le chemin d'écriture: toute opération de modification est d'abord écrite dans un journal (une liste d'opérations, comme "modifier l'attribut du fichier X en 355", "ajouter le bloc suivant au fichier Y: blabla...", etc). Quand l'écriture dans le journal a été complètement effectuée, le système signifie à l'application que les données sont bien écrites physiquement sur le disque. Mais l'écriture dans le système de fichier lui-même est effectuée plus tard, de manière asynchrone, et de telle façon que si celle-ci échoue avant complétion, elle pourra être retentée autant de fois que l'on veut (en relisant le journal).

Il existe deux types de journalisation:
  * journalisation des méta-données: c'est le mode le plus classique, où seule les méta-données sont journalisées. Ce mécanisme garantit l'intégrité de la structure arborescente et de ses informations, mais pas celle des données des des fichiers.
  * journalisation des données: elle implique la journalisation des méta-données, et garantit l'intégrité complète des données du système de fichier

La journalisation possède donc les avantages suivants:
  * intégrité constante des méta-données et/ou des données
  * récupération rapide en cas de crash (il suffit de partir du dernier "bon état" et relire le journal), souvent considéré plus important que l'intégrité elle-même (un fsck de 10h par TB n'est pas rare).

Mais elle possède aussi un inconvénient majeur, celui de provoquer une double écriture. Dans le cas des méta-données, ceci peut avoir un impact léger. Dans le cas de la journalisation des données, ceci peut être très important. La plupart des systèmes de fichier proposent de déporter le journal sur un autre périphérique (comme par exemple une FLASH rapide), même si ceci laisse dépendre l'intégrité globale des données du taux de panne cumulé de deux périphériques distincts.

===== Atomicité =====

Une opération est dite atomique si elle a lieu soit intégralement, soi pas du tout. Cette propriété est très souvent vraie pour des opérations triviales sur un système de fichier, comme //effacer// ou //renommer//. Elle l'est toutefois rarement pour l'écriture: quand une application demande l'écriture d'une certaine quantité de donnée, seulement une partie de celle-ci peut être réellement écrite sur le disque avant qu'une erreur ou un crash ne se produise.

Cette notion est très importante pour les besoins de (non-)synchronisation, comme l'accès exclusif à un fichier ou la création d'un fichier temporaire unique.

**Exemples**:
  * NFS est connu pour n'offrir très peu d'opérations atomiques (à part //mkdir//), et fait souvent l'objet d'un traitement spécial (typiquement un serveur IMAP/SMTP)
  * Il existe une attaque connue à l'aide de lien symbolique permettant d'intercepter des fichiers temporaires (et donc leur contenu, parfois sensible) quand un programme, de façon incorrecte, vérifie la présence d'un fichier avant de le créer.

===== Sparse (trous) =====

Certains de systèmes de fichiers sont capables de traiter de manière optimisée des fichiers dont seules certaines portions contiennent effectivement des données. Si à l'écriture une application décide d'écrire explicitement à certaines adresses d'un fichier, le système de fichier peut décider de ne stocker qu'effectivement ces portions de données. Dans ce cas la taille du fichier affichée est sans relation avec la taille occupée sur le disque.

Certaines applications peuvent gérer également de manière intelligente ces fichiers à trous, notamment celles de copie et d'archivage (//cp// et //tar//).

**Exemple**: une image disque QEMU est créée immédiatement car elle est "à trou", en fait elle ne possède qu'un bloc d'information à la fin du fichier et occupe initialement et invariablement un bloc.

**Note**: la copie d'un fichier à trou vers un système de fichiers qui ne les supporte pas peut être "suprenante" (le système devant alors physiquement écrire les trous: occupation disque et temps de copie sans relation avec l'original).

===== Attributs étendus =====

La plupart des systèmes de fichiers étendent légèrement le champ de bit "standard" des fichiers Unix (masque octal 02777) pour apporter quelques fonctionnalités supplémentaires. Ces propriétés dépendent du système de fichier et ne sont pas normalisées.

**Exemple**: **chattr** et **lsattr** sous Linux.

===== ACL =====

Les //Access Control List// représentent un mécanisme étendu de gestion des droits, souvent bien plus sophistiqué et fin que le champ de bits classique d'Unix. Malheureusement la notion d'ACL n'est pas unifiée et dépend de chaque système de fichier.

Ceci implique souvent des outils spécifiques pour l'archivage et la manipulation de données.

===== POSIX =====

Une implémentation de système de fichier propose en générale une interface standard (open, read, write, close, etc.), dont la //sémantique// doit en principe respecter celle décrite par la norme **POSIX**. Décrire précisément les exigences d'un système de fichier compatible POSIX sort largement du cadre de ce cours, mais il est important de savoir que la vaste majorité des applications Unix reposent implicitement sur cette norme.

En conséquence, la plupart des systèmes de fichier de "haut niveau" (permettant l'intégration de FTP, DAV ou SSH dans le VFS) ou en forte contrainte d'interopérabilité (Samba) ne sont pas utilisables de manière transparente par les applications standards.