Как мне использовать OverlayFS?

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

Верхний и нижний

Оверлейная файловая система объединяет две файловые системы - "верхнюю" файловую систему и "нижнюю" файловую систему. Когда имя существует в обеих файловых системах, объект в "верхней" файловой системе виден, в то время как объект в "нижней" файловой системе либо скрыт, либо, в случае каталогов, объединяется с "верхним" объектом.

Было бы правильнее сослаться на верхнее и нижнее "дерево каталогов", а не на "файловую систему", поскольку вполне возможно, что оба дерева каталогов находятся в одной и той же файловой системе, и не требуется указывать корень файловой системы для или верхний или нижний.

Нижняя файловая система может быть любой файловой системой, поддерживаемой Linux, и не требует записи. Нижняя файловая система может быть даже другим оверлеем. Верхняя файловая система обычно будет доступна для записи, и если она есть, она должна поддерживать создание расширенных атрибутов доверенных. * И предоставлять действительный d_type в ответах readdir, поэтому NFS не подходит.

Только для чтения наложение двух файловых систем только для чтения может использовать любой тип файловой системы.

Справочники

Наложение в основном включает в себя каталоги. Если данное имя появляется как в верхней, так и в нижней файловых системах и ссылается на не каталог в любом из них, то нижний объект скрыт - имя относится только к верхнему объекту.

Если верхний и нижний объекты являются каталогами, создается объединенный каталог.

Во время монтирования две директории, указанные как опции монтирования "lowerdir" и "upperdir", объединяются в объединенную директорию:

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

"Рабочий каталог" должен быть пустым каталогом в той же файловой системе, что и каталог верхнего каталога.

Затем всякий раз, когда поиск запрашивается в таком объединенном каталоге, поиск выполняется в каждом фактическом каталоге, и объединенный результат кэшируется в dentry, принадлежащем оверлейной файловой системе. Если оба фактических поиска находят каталоги, оба сохраняются и создается объединенный каталог, в противном случае сохраняется только один: верхний, если он существует, иначе нижний.

Только списки имен из каталогов объединяются. Другое содержимое, такое как метаданные и расширенные атрибуты, сообщается только для верхнего каталога. Эти атрибуты нижнего каталога скрыты.

Минимальный исполняемый пример

# 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 вверх по течению.

Выход первого ls с креплением:

lower:
lost+found  lower-file

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

upper/upper:
overlay-file  upper-file

upper/work:
work

Выход второй ls без крепления:

lower:
lost+found  lower-file

upper/upper:
overlay-file  upper-file

upper/work:
work

Интерпретация:

• ниже: не изменился после записи в оверлей
• верхний: получил модификацию для наложения
• наложение: показывает файлы как сверху, так и снизу
• Работа: содержит случайный контент (work/ каталог) нас не должно волновать

Пример адаптирован из: Пример использования OverlayFS

Вот более сложный пример с несколькими нижними уровнями: Overlayfs перезагружается с несколькими слоями (переход от aufs)

Протестировано на Ubuntu 18.04, ядро ​​Linux 4.15.0.

Я расширил эти статьи, добавив в них скрипт для оверлеев, который устанавливает корень fs только для чтения.

• Английский: https://help.ubuntu.com/community/aufsRootFileSystemOnUsbFlash
• Немецкий: http://wiki.ubuntuusers.de/Nur-Lesen_Root-Dateisystem

Надеюсь, поможет.

Монтирование OverlayFS в fstab

Вышеприведенные ответы объяснили, как смонтировать оверлейную файловую систему из строки cmd и/или скрипта. Также можно смонтировать OverlayFS из fstab.

Существует неотъемлемая проблема с монтированием OverlayFS. Поскольку мы монтируем каталоги, эти каталоги должны быть в наличии и/или готовы. Присутствует означает, что файловая система, в которой находится конкретный каталог, уже смонтирована, а готовность означает, что конкретный каталог «заполнен». Примером более позднего является монтирование ISO-образа в определенный каталог или монтирование сетевого ресурса (любого типа).

Смонтировать каталог, которого нет, не удастся, в то время как смонтировать еще не «заполненный» каталог не удастся, так как OverlayFS не может узнать, готов ли каталог.

При монтировании файловых систем из fstab это особенно проблематично, так как все монтирование выполняется параллельно, поэтому мы не можем гарантировать, что все подготовлено для OverlayFS.

Однако, если дистрибутив Linux использует systemd, то монтирование файловых систем выполняется им. Systemd читает файл fstab и создает модули монтирования на лету. После этого все монтирование обрабатывается systemd. Файлы юнитов systemd имеют параметры: require , after , before , которые можно использовать для управления порядком и зависимостью монтирования, определенными в fstab, таким образом гарантируя, что монтирование OverlayFS не завершится ошибкой (по крайней мере, из-за неправильного порядка).

Чтобы установить порядок/зависимость монтирования в файле fstab, мы объявим параметр systemd « require », используя синтаксис: x-systemd.require. Аргументом в пользу этой опции является точка монтирования монтирования, которая должна быть успешно смонтирована до данного монтирования (определяется в fstab).

Пример:

Чтобы показать пример (и синтаксис записей fstab ), мы покажем случай, когда мы будем накладывать каталог, на который смонтирован iso-образ, в то время как этот конкретный файл образа будет храниться на отдельном жестком диске, который нужно будет смонтировать, прежде чем мы получим доступ файл изображения. Таким образом формируется требуемый порядок событий:

      mount hdd -> mount iso image -> mount OverlayFS

Для данного случая записи fstab будут выглядеть так:

      # 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
                                                                            

Если какие-либо монтирования в цепочке завершатся неудачей, зависимые монтирования не будут выполняться.

Примечание:

В Arch Linux Wiki есть пример использования fstab для монтирования OverlayFS, в котором используются следующие параметры:

      noauto,x-systemd.automount

Это приведет к тому, что оверлейная файловая система просто не будет монтироваться во время загрузки ( опция noauto ), что позволит избежать возможного сбоя, если предыдущие монтирования не готовы. При первом доступе к оверлейному каталогу файловая система будет смонтирована ( опция x-systemd.automount ). У этого подхода есть два недостатка:

1. Если необходимые нижние/верхние каталоги не готовы, это монтирование завершится ошибкой.
2. Смонтировать удастся, даже если нижние/верхние каталоги не заполнены (например, ISO не смонтирован)

Мы можем избежать этого позже, добавив x-systemd.require в список опций.