Comment utiliser OverlayFS ?

De https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt :

Supérieure et inférieure

Un système de fichiers superposé combine deux systèmes de fichiers - un système de fichiers "supérieur". et un système de fichiers "inférieur". Lorsqu'un nom existe dans les deux systèmes de fichiers, l'objet du système de fichiers "supérieur" est considéré comme un nom de fichier. l'objet du système de fichiers "supérieur" est visible tandis que l'objet du système de fichiers inférieur est soit caché, soit, dans le cas des répertoires, fusionné avec l'objet supérieur, fusionné avec l'objet "supérieur".

Il serait plus correct de parler d'un "répertoire" supérieur et inférieur. supérieur et inférieur plutôt que de "système de fichiers", car il est tout à fait possible que les deux dans le même système de fichiers et il n'est pas nécessaire que la racine d'un et il n'est pas nécessaire que la racine d'un système de fichiers soit indiquée pour le système inférieur.

Le système de fichiers inférieur peut être n'importe quel système de fichiers supporté par Linux et ne n'a pas besoin d'être accessible en écriture. Le système de fichiers inférieur peut même être un autre overlayfs. Le système de fichiers supérieur est normalement accessible en écriture et s'il l'est, il doit prendre en charge la création d'attributs étendus trusted.*. et s'il l'est, il doit prendre en charge la création d'attributs étendus trusted.*, et doit fournir un d_type valide dans les réponses readdir, donc NFS ne convient pas.

Une superposition de deux systèmes de fichiers en lecture seule peut utiliser n'importe quel système de fichiers en lecture seule. type de système de fichiers.

Annuaires

La superposition concerne principalement les répertoires. Si un nom donné apparaît à la fois dans systèmes de fichiers supérieur et inférieur et fait référence à un non-répertoire dans l'un ou l'autre, alors l'objet inférieur est caché - le nom ne fait référence qu'à l'objet supérieur. supérieur.

Lorsque les objets supérieur et inférieur sont tous deux des répertoires, un répertoire fusionné est formé.

Au moment du montage, les deux répertoires donnés comme options de montage "lowerdir" et "upperdir" sont combinés en un répertoire fusionné :

mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,workdir=/work /merged

Le "workdir" doit être un répertoire vide sur le même système de fichiers que upperdir.

Ensuite, chaque fois qu'une consultation est demandée dans un tel répertoire fusionné, la fonction recherche est effectuée dans chaque répertoire réel et le résultat combiné est mis en cache dans le répertoire appartenant au système de fichiers superposé. Si les deux recherches réelles trouvent des répertoires, elles sont toutes deux stockées et un répertoire fusionné est créé. fusionné est créé, sinon un seul est stocké : le répertoire supérieur s'il est s'il existe, sinon le répertoire inférieur.

Seules les listes de noms des répertoires sont fusionnées. Les autres contenus tels que les métadonnées et les attributs étendus ne sont rapportés que pour le supérieur uniquement. Ces attributs du répertoire inférieur sont cachés.

J'ai étendu ces artikels pour inclure un script pour overlayfs qui met en place un fs racine en lecture seule.

• Anglais : https://help.ubuntu.com/community/aufsRootFileSystemOnUsbFlash
• Allemand : http://wiki.ubuntuusers.de/Nur-Lesen_Root-Dateisystem

J'espère que cela vous aidera.

Exemple minimal exécutable

# Create the filesystems.
dd if=/dev/zero of=lower.ext4 bs=1024 count=102400
mkfs -t ext4 lower.ext4
cp lower.ext4 upper.ext4
mkdir lower upper overlay
sudo mount lower.ext4 lower
sudo mount upper.ext4 upper
sudo chown "$USER:$USER" lower upper
printf lower-content > lower/lower-file
# Upper and work must be on the same filesystem.
mkdir upper/upper upper/work
printf upper-content > upper/upper/upper-file
# Work must be empty. E.g. this would be bad:
#printf work-content > upper/work/work-file
# Make the lower readonly to show that that is possible:
# writes actually end up on the upper filesystem.
sudo mount -o remount,ro lower.ext4 lower

# Create the overlay mount.
sudo mount \
  -t overlay \
  -o lowerdir=lower,upperdir=upper/upper,workdir=upper/work \
  none \
  overlay \
;

# Interact with the mount.
printf 'overlay-content' > overlay/overlay-file
ls lower upper/upper upper/work overlay

# Write to underlying directories while mounted
# gives undefined behaviour.
#printf lower-content-2 > lower/lower-file-2
#printf upper-content-2 > upper/upper-file-2

# Unmount the overlay and observe state.
sudo umount overlay
ls lower upper/upper upper/work

# Cleanup.
sudo umount upper lower

GitHub en amont .

Sortie de la première ls avec la monture :

lower:
lost+found  lower-file

overlay:
lost+found  lower-file  overlay-file  upper-file

upper/upper:
overlay-file  upper-file

upper/work:
work

Sortie de la deuxième ls sans le support :

lower:
lost+found  lower-file

upper/upper:
overlay-file  upper-file

upper/work:
work

Interprétation :

• lower : n'a pas été modifié après l'écriture dans la couche supérieure
• supérieur : a reçu la modification de la superposition
• superposition : affiche les fichiers de la partie supérieure et de la partie inférieure.
• travail : contient un contenu aléatoire (un work/ ), nous ne devrions pas nous soucier de

Exemple adapté de : Exemple d'utilisation de OverlayFS

Voici un exemple plus complexe avec plusieurs couches inférieures : Les overlayfs se rechargent avec des couches multiples (migration loin des aufs)

Testé sur Ubuntu 18.04, noyau Linux 4.15.0.

Montage de OverlayFS dans fstab

Les réponses ci-dessus ont expliqué comment monter un système de fichiers superposé depuis la ligne cmd et/ou script. Il est également possible de monter OverlayFS à partir de fstab .

Il y a un problème inhérent au montage de OverlayFS. Puisque nous montons des répertoires, ces répertoires doivent être présents et/ou prêts. Présent signifie que le système de fichiers sur lequel se trouve un répertoire particulier est déjà monté, tandis que prêt signifie que le répertoire particulier est "rempli". Un exemple de ce dernier cas est le montage d'une image ISO dans un répertoire particulier, ou le montage d'un partage réseau (de n'importe quel type).

Le montage d'un répertoire qui n'est pas présent échouera, alors que le montage d'un répertoire qui n'est pas encore "peuplé" n'échouera pas, puisque OverlayFS n'a aucun moyen de savoir si le répertoire est prêt.

Lors du montage de systèmes de fichiers à partir de fstab, c'est particulièrement un problème, puisque tout le montage est fait en parallèle, donc nous ne pouvons pas nous assurer que tout est préparé pour OverlayFS.

Cependant, si la distribution Linux utilise systemd, le montage des systèmes de fichiers est géré par celui-ci. Systemd lit le fichier fstab, et crée des unités de montage à la volée. Après cela, tout le montage est traité par systemd. Les fichiers d'unités de systemd ont des options : r equire , nach , antes de qui peut être utilisé pour contrôler l'ordre et la dépendance des montages définis dans fstab, assurant ainsi que le montage d'OverlayFS n'échouera pas (du moins pas à cause d'un ordre incorrect).

Pour définir l'ordre/dépendance des montages dans le fichier fstab, nous allons déclarer l'option systemd " exiger " en utilisant la syntaxe : x-systemd.require . L'argument pour cette option est le point de montage du montage qui devrait être monté avec succès avant le montage donné (défini dans fstab).

Exemple :

Pour montrer un exemple (et la syntaxe de fstab ), nous allons montrer un cas où nous allons superposer le répertoire sur lequel l'image iso est montée, alors que ce fichier image particulier sera stocké sur un disque dur séparé, qui devra être monté avant que nous accédions au fichier image. Ainsi, nous formons l'ordre des événements requis :

mount hdd -> mount iso image -> mount OverlayFS

Pour le cas donné, les entrées fstab ressembleraient à ceci :

# 1. mount hdd partition
# 2. mount iso image from hdd partition, but only if/after hdd is mounted
# 3. overlay iso image, but only if/after iso image is mounted
#
/dev/hdb1            /mnt/hdd      ext4     errors=remount-ro                 0  2  
/mnt/hdd/linux.iso   /mnt/iso      auto     x-systemd.requires=/mnt/hdd,ro    0  0
overlay              /mnt/merged   overlay  x-systemd.requires=/mnt/iso,lowerdir=/mnt/iso,upperdir=/overlay/lower,workdir=/overlay/working  0 0

Si l'un des montages de la chaîne échoue, le ou les montages dépendants ne seront pas exécutés.

Note :

Sur Arch Linux Wiki il y a un exemple d'utilisation de fstab pour monter OverlayFS dans lequel les options suivantes sont utilisées :

noauto,x-systemd.automount

Cela aura pour effet que le système de fichiers superposé sera simplement non monté au moment du démarrage ( noauto ), évitant ainsi un éventuel échec si les montages précédents ne sont pas prêts. Lors du premier accès au répertoire de recouvrement, le système de fichiers sera monté ( x-systemd.automount ). Cette approche présente deux faiblesses :

1. Si les répertoires inférieurs/supérieurs nécessaires ne sont pas prêts, le montage échouera.
2. Le montage réussira même si les répertoires inférieurs/supérieurs ne sont pas remplis (ISO n'est pas monté, par exemple).

Nous pouvons l'éviter plus tard, en ajoutant x-systemd.require à la liste des options.