Filesystems

Systèmes de fichiers (ou filesystems)

Un système de fichiers ou FS (File System) désigne soit l’organisation des fichiers au sein d’un OS (comme Linux avec ses /, /etc, etc) soit l’organisation des données au sein d’un support de stockage (NTFS, FAT32, ext3fs, ext4fs…) : il peut alors avoir une ou plusieurs racines, soit pour faire des snapshots soit pour faire des volumes logiques comme avec zfs. Un tel système permet d’organiser les données et d’y donner accès à différentes applications : on en a une vue abstraite et on peut y avoir accès à partir d’un chemin d’accès.  En effet ils fonctionnent en arborescence.
Différents principes de stockage : FAT utilise une table associant la taille du fichier à son nom et pointe vers une table donnant les emplacements de blocs contenant le fichier. Les systèmes Unix fonctionne avec un inode : chaque fichier a un numéro unique d’inode, et l’inode lui-même est regroupant toutes les informations sur un fichier à l'exception du nom, notamment la protection d'accès en lecture, en écriture ou des listes de dates, ainsi que le moyen d'en retrouver le contenu. Le nom est stocké dans le répertoire associé à un numéro d'inode. Cette organisation présente l'avantage qu'un fichier unique sur disque peut être connu du système sous plusieurs noms.

Métadonnées

Le nom chez Unix est généralement connu comme une suite d’octet par l’OS, et l’encodage est laissé aux paramètres régionaux de l’utilisateur (même si Unicode avec UTF-8 est souvent utilisé, raison de compatibilité). NTFS, vFAT et d’autres utilisent UTF-16.
Chaque fichier est décrit par des métadonnées (dans l’inode sur Linux), tandis que le contenu est dans des blocs du support de stockage. Les métadonnées les plus courantes sous UNIX sont :
    • droits d'accès en lecture, écriture et exécution selon l'utilisateur, le groupe, ou les autres ;
    • dates de dernier accès, de modification des métadonnées (inode), de modification des données (block)8 ;
    • propriétaire et groupe propriétaire du fichier ;
    • taille du fichier ;
    • nombre d'autres inodes (liens) pointant vers le fichier ;
    • nombre de blocs utilisés par le fichier;
    • type de fichier : fichier simple, lien symbolique, répertoire, périphérique, etc.
Sur la plupart des systèmes Unix, la commande stat permet d'afficher l'intégralité du contenu de l'inode.
Les fs peuvent être journalisés (toutes les modifications de fichiers sont inscrites dans un journal, afin de pouvoir les reprendre en cas de coupure intempestive) ou pas. Il existe PLEIN de systèmes de fichiers avec diverses caractéristiques ( Spécialisés, « snapshottables », en clusters, réseau, etc).

On peut voir les métadonnées de plusieurs façons:

• la commande stat donne le contenu de l'inode pour un fichier:

<source lang="bash"> [justine@Argonaut ~]$ stat qdqsd

 Fichier : qdqsd
  Taille : 166       	Blocs : 8          Blocs d'E/S : 4096   fichier

Périphérique : 812h/2066d Inœud : 11276314 Liens : 1 Accès : (0644/-rw-r--r--) UID : ( 1000/ justine) GID : ( 1000/ justine)

Accès : 2019-12-16 19:08:44.895096322 +0100

Modif. : 2019-12-16 19:08:44.895096322 +0100 Changt : 2019-12-16 19:08:44.895096322 +0100

 Créé : 2019-12-16 19:08:44.895096322 +0100

</source>

• ls -i affiche les n° d'inode

On peut notamment utiliser rm avec les n° d'inodes plutôt qu'avec les noms, en cas de besoin.

Partition Primaire, Étendue, Logique

Dans le schéma de notation MBR (Master Boot Record : Un secteur de boot spécial au début d'un disque dur), 4 partition primaires maximum sont autorisées. Du coup, pour étendre ce chiffre, on doit passer par des partitions étendues.

• Primaire : C'est une partition classique sur un disque dur, qui contient des fichiers.
• Étendue : C'est un type de partition spécial qui contient des partitions logiques (et non des fichiers).
• Logique : C'est une partition contenant des fichiers, située dans une partition étendue.

MBR: < primary | primary | primary | primary > Une possibilité de MBR
MBR: < primary | primary | extended [logical, logical, logical] > Une autre possibilité

Fonctionnement général, notion de répertoire / d'inode / de bloc

Ce qui va suivre est surtout valable pour ext !

Un tel système stocke les données et les métadonnées à part. Les métadonnées sont stockées dans les inodes, et contiennent les informations citées plus haut sur cette page (PAS le nom notamment) ainsi que des liens vers les données en elle-mêmes; les blocs de données contiennent le n° d'inode lié aux données.

• Un répertoire est un fichier spécial, qui relie des noms de fichiers et des inodes.
• Un inode contient des métadonnées et des liens vers les blocs de données
• Les blocs de données contiennent des données (duh) et les n° d'inodes.

Répertoires

Le tout est contenu dans les répertoires, qui sont des genres de fichiers: Chaque ligne d'un "fichier répertoire" contient l'inode, la longueur du nom en octets, et le nom.

Cette structure (ou le nom est détaché du reste) permet la création de "hard links", où plusieurs fichiers mènent vers les même données.

Blocs

La donnée brute est stockée dans des blocs dont la taille est configurable lors du partitionnement. On peut voir la taille de bloc en octets, en place sur un FS:

# blockdev --getbsz /dev/sda1 
4096

Tailles de blocs

Concernant les tailles de blocs, il ne faut pas confondre:

• La taille des secteurs (parfois appellés blocs) du disque dur : le disque dur présente des blocs dont la taille est fixe et déterminée par le matos en lui-même (en général 512 octets, 4096 pour les gros). Le disque ne peut pas écrire ou lire bit par bit, mais secteur par secteur. Le CPU va dire au contrôleur : "écrit moi ça sur tel secteur : 0xfce5566d4... [sur toute la taille du secteur]". Le disque dur ignore tout du système de fichiers qu'il contient, il se contente de lire et écrire sur ses secteurs.
• La taille des blocs déterminée par le système : ce sont les blocs de données d'ext, dont la taille est configurable (et donc la couche au-dessus). Typiquement, pour ext, ils font 4096 octets.

Les IO sont généralement gérés non pas par les processus, mais par la mémoire virtuelle de l'OS. It uses extensively paging. The VM page size is typically 4096 bytes (might be different on non-x86 CPUs), it is determined by the CPU architecture. (For example, newer amd64 CPUs can handle 2MB pages, or dec alpha used 8192 byte pages). [À comprendre]

Pour déterminer la bonne taille de bloc:

• Le mieux est que secteur, bloc et page soient des multiples les uns des autres. Donc, en général, on utilise des blocs de 4096 octets.
• Les partitions du disque doivent commencer et finir sur des tailles exactes de page; sinon, on deux lectures / écriture pour une seule IO parce que les blocs et les secteurs se superposent (un bloc se retrouve à cheval sur deux secteurs !). Donc, en général : toutes les partitions doivent commencer et finir sur un secteur divisible par 8 (4096/512 = 8).

Formats connus

La notion de copy-on-write est une façon d'améliorer les performances en terme de lecture. Il s'agit d'une technique de programmation, dont le paradigme est le suivant : si de multiples appelants demandent des ressources initialement impossibles à distinguer, vous pouvez leur donner des pointeurs vers la même ressource. Cette fiction peut être maintenue jusqu'à ce qu'un appelant modifie sa « copie » de la ressource. À ce moment-là, une copie privée est créée. Cela évite que le changement soit visible ailleurs.

Ext2/3/4

Extended File System

Il s'agit du format standard pour Linux. La seule différence entre les versions 2 et 3 et que la 3 dispose d'un journal recensant les dernières interactions avec le sytème de fichiers. De cette manière, si le système est interrompu de manière brutale, il n'y a pas besoin de vérifier tout le système de fichiers : on sait quelles étaient les dernières transactions en cours et donc quels sont les fichiers potentiellement corrompus (qui seront alors placés dans le lost+found). Avec la version 2, dans ce genre de cas, il était nécessaire de vérifier l'intégralité du système de fichiers afin de trouver les deux ou trois fichiers corrompus. Le journal est fichier qui connait énormément d'entrées sorties,

Le journal a trois modes:

• journal : faible risque de pertes : le journal contient données et métadonnées (on sauve tout en double !)
• Ordered : Risque moyen : Ne garde que les métadonnées dans le journal
• Writeback : Rsique fort : Aucune garantie quant au moment où les métadonnées sont inscrites.

La version 4 fonctionne sur le même principe, mais avec de plus grande capacités en termes de tailles maximale, et autres choses du genre. Il propose un système d'"extent" qui remplace des fonctionnalités d'échange de blocs venant de la version 3. Peut être monté comme de l'ext3 si ces fonctionnalités nouvelles ne sont pas utilisées. Il propose aussi des checksums du journal pour s'assurer qu'il est fiable.

XFS

Système journalisé en 64 bits, conçu par Silicon Graphics pour ses grosses stations de calcul. Conçu pour les IO parallélisées; on peut scaler le système en fonction du nombre d'IO et de la bande passante du FS. Il inclut son propre gestionnaire de volumes. Propose des blocs de taille variables, des snapshots.

Il utilise un système d'arbres (B tree) pour ses répertoires et et l'allocation de ses fichiers. Le systèmes est partitionné en AG (Allocation Groups) qui ont leur propre allocation et gestion de l'espace libre. Les fichiers sont des étendues allouées, contiguës si possible.

La journalisation peut être synchrone (meilleure garantie en cas de crash : on attend que le journal soit écrit avant de continuer) ou asynchrone (plus performant). Le journal peut être mis dans un autre disque dur pour améliorer la fiabilité.

Propose aussi le GRIO (Guaranteed Rate I/O), qui permet aux applications de se réserver une quantité de bande passante.

btrfs, dit ButterFS

Basé sur un B tree utilisant le copy-on-write. Son principal intérêt est la sacalabilité et un certain nombre de fonctions. Citation d'un de ses auteurs: "[btrfs goal is] to let Linux scale for the storage that will be available. Scaling is not just about addressing the storage but also means being able to administer and to manage it with a clean interface that lets people see what’s being used and makes it more reliable".

Il est basé sur des étendues, comme XFS. Il est efficace pour les petits fichiers et les répertoires indexés, et supporte l'allocation d'inodes dynamique.

Les autres fonctionnalités:

• Support de stockages multiples gérés comme un seul, à la manière de LVM
• Support du mirroring + striping
• Support direct des systèmes flash
• Compression
• Snapshots inscriptibles / read-only avec incrémentales
• Déduplication
• Migration ext > btrfs possible

Btrfs est la base de Ceph, un système de cluster open source.

LVM

LVM (Logical Volume Manager) : LVM diffère des systèmes habituels en se détachant du matériel : il ne tient pas compte, au final, des partitions. Il est plus souple. Plus de partitions primaire, étendues, etc ; plus besoin de chercher des emplacements exacts des données ; on peut agrandir les volumes n’importe quand ; le redimensionnement ne présente pas beaucoup de risques.

LVM se divise en trois unités :

 

• Volume Physique : C’est un DD, une partition, etc. Un volume sous la forme /dev/sda1, par exemple.
• Groupe de volumes : C’est un ensemble de volumes physiques. Il en faut au moins un, il peut contenir plusieurs volumes physiques. Généralement dans un serv, on regroupe les DD ayant des perfs similaires dans le même volume group.  
• Volume logique ou LV : Il remplace les partitions. C’est un « espace quelque part dans un groupe de volumes ». On peut y mettre un /home, un /, etc. Il faut juste éviter d’y mettre GRUB. Il peut s’étaler sur plusieurs disques ou partitions, mais attention à ne pas perdre de disque !!