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

Этот ответ и сообщение электронной почты укажите, что нечто, называемое "OverlayFS", доступно в Ubuntu 11.10 и принудительно заменит aufs в Ubuntu 12.04.

Как мне его использовать? Где его документация?

Редактировать: С момента написания этого ответа некоторые вещи изменились в overlayfs, а именно добавление требуемого параметра workdir, видишь ответ Тотти ниже приведено подробное описание этого нового параметра.

Наконец-то мне удалось его найти. Я нашел ссылки на него в исходном коде ядра, но по какой-то причине он не отображается в дереве git на kernel.org . Но! Если вы извлекаете исходный код ядра Ubuntu следующим образом: apt-get source linux-image-3.0.0-16-generic вы можете найти его в linux-3.0.0/Documentation/overlayfs.txt. Он также доступен в пакете linux-doc в /usr/share/doc/linux-doc/filesystems/overlayfs.txt.gz.

Поскольку фактическая справочная документация - это скорее "как это работает", а не "как смонтировать с его помощью", вот краткое изложение (в документации ядра есть один пример).:

mount -t overlayfs -o [mount options] overlayfs [mountpoint for merged system]

Где [параметры монтирования] могут быть:

  • lowerdir =somedir: lowerdir - это каталог, в который вы собираетесь поместить свою новую файловую систему, если есть дубликаты, они будут перезаписаны (на самом деле, скрыты в пользу) версии upperdir
  • upperdir=somedir: верхний каталог - это каталог, на который вы хотите наложить нижний каталог. Если в lowerdir и upperdir существуют повторяющиеся имена файлов, версия upperdir имеет приоритет.
  • стандартные варианты крепления. Единственный, который я видел из кода, - это ro / rw, но вы можете поэкспериментировать.

Одна вещь, которая сначала смутила меня, поэтому я, вероятно, должен уточнить, заключается в том, что монтирование overlayfs на самом деле не монтирует файловую систему. Я пытался смонтировать файловую систему squashfs с помощью монтирования overlayfs, но это работает не так. Сначала вы должны смонтировать файловую систему (в моем случае squashfs) в произвольный каталог, затем использовать overlayfs для объединения точки монтирования (каталога) и другого каталога в третичный каталог (точка монтирования overlayfs) (редактировать: этот "третичный" каталог на самом деле может быть каталогом upperdir=). Третичный каталог - это то место, где вы увидите объединенные файловые системы (или деревья каталогов - это гибко).

Пример 1, наложение корневой файловой системы

Я работал над гибридным загрузочным диском Ubuntu, где базовая система Ubuntu существует как filesystem.squashfs, и у меня есть файлы под названием ubuntu.overlay kubuntu.overlay xubuntu.overlay и lubuntu.overlay. Файлы .overlay являются базовыми установками указанных систем с обрезанным содержимым файловой системы.squashfs (для экономии места). Затем я изменил сценарии инициализации, чтобы наложить файл .overlay правильного дистрибутива (из параметра загрузки), используя overlayfs и вышеуказанные параметры, и это работает как шарм!

Это строки, которые я использовал в своих сценариях инициализации (после перевода всех переменных):

mkdir -p /overlaymount -t squashfs /cdrom/casper/ubuntu.overlay /overlaymount -t overlayfs -o lowerdir=/filesystem.squashfs,upperdir=/overlay overlayfs /

Обратите внимание, что файловая система.squashfs выше представляет собой каталог создан Каспером, а не файлом.

Эти три утверждения создают /overlay каталог, смонтируйте файловую систему squashfs на /overlay каталог, а затем используйте OverlayFS, чтобы по существу объединить содержимое /overlay над /.

Пример 2, прозрачное слияние двух каталогов

В процессе перестройки моего live USB для каждого выпуска я использую OverlayFS, чтобы сэкономить кучу времени. Я начинаю с каталога под названием ubuntu-base, который содержит содержимое образа ubuntu-core, который является самой базовой установкой. Затем я создам каталоги с именами ubuntu, kubuntu, lubuntu и xubuntu.

Затем я использую OverlayFS, чтобы файлы из базы ubuntu отображались в отдельных каталогах. Я бы использовал что-то вроде этого:

mount -t overlayfs -o lowerdir=ubuntu-base,upperdir=kubuntu overlayfs kubuntu

Это приводит к тому, что файлы из ubuntu-base отображаются в папке kubuntu. Тогда я смогу chroot в папку kubuntu и сделайте что-то вроде apt-get install kubuntu-desktop. Любые изменения, внесенные во время этого монтирования OverlayFS, останутся в верхнем каталоге, в данном случае в папке kubuntu. Затем, как только я размонтирую OverlayFS, файлы, которые действительно существуют в ubuntu-base, но "зеркально отражаются" в папке kubuntu, исчезают, если они не были изменены. Это избавляет меня от необходимости иметь несколько копий файлов в ubuntu-base, сохраняя при этом возможность использовать их так, как если бы они физически существовали в каждом месте.

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

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

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

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

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

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

Каталоги

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

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

Во время монтирования два каталога, указанные в качестве параметров монтирования "нижний каталог" и "верхний каталог", объединяются в объединенный каталог:

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

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

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

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

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

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

Минимальный доступный для выполнения пример

# Create the filesystems.dd if=/dev/zero of=lower.ext4 bs=1024 count=102400mkfs -t ext4 lower.ext4cp lower.ext4 upper.ext4mkdir lower upper overlaysudo mount lower.ext4 lowersudo mount upper.ext4 uppersudo chown "$USER:$USER" lower upperprintf lower-content > lower/lower-file# Upper and work must be on the same filesystem.mkdir upper/upper upper/workprintf 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-filels 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 overlayls lower upper/upper upper/work# Cleanup.sudo umount upper lower

Восходящий поток GitHub.

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

lower:lost+found  lower-fileoverlay:lost+found  lower-file  overlay-file  upper-fileupper/upper:overlay-file  upper-fileupper/work:work

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

lower:lost+found  lower-fileupper/upper:overlay-file  upper-fileupper/work:work

Толкование:

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

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

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

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

Монтаж оверлейных файлов в fstab

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

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

Монтирование каталога, которого нет, завершится ошибкой, в то время как монтирование еще не "заполненного" каталога не завершится ошибкой, поскольку OverlayFS не имеет возможности узнать, готов ли каталог.

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

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

Чтобы установить порядок/зависимость монтирования в файле fstab, мы объявим параметр systemd "требовать" использование синтаксиса: x-systemd.требуется. Аргументом для этого параметра является точка монтирования монтирования, которая должна быть успешно смонтирована перед заданным монтированием (определено в 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  0overlay              /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 опция), избегая возможного сбоя, если предыдущие монтирования не готовы. При первом доступе к каталогу overlay файловая система будет смонтирована (x-systemd.automount вариант). У этого подхода есть два слабых места:

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

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

Ты и я оба, брат. До сих пор я сталкивался с этим: "mount -t overlayfs -o rw,upperdir=x,lowerdir=y overlayfs /mount/point`. Кроме того, я ничего не знаю. Я возлюсь с ним в живой системе, но мне еще не удалось заставить его работать. Хотел бы я точно выяснить, что означают “верхний уровень” и “нижний уровень”. Я ничего не нашел.