Код OverlayFS принят в состав ядра Linux 3.18 Печать
28.10.14 06:42

В тестовом выпуске ядра Linux 3.18-rc2 появилась поддержка файловой системы OverlayFS, разработанной компанией SUSE в качестве более прогрессивной замены UnionFS и AUFS. В процессе цикла подготовки первого кандидата в релизы, включение OverlayFS в состав ядра было отложено, но в последний момент разработчикам удалось устранить финальные замечания и код был принят во второй кандидат в релизы.

OverlayFS позволяет создать виртуальную многослойную файловую систему, объединяющую несколько частей других файловых систем. OverlayFS входит в число наиболее ожидаемых в ядре возможностей, так как многослойная ФС востребована в Live-дистрибутивах и системах контейнерной виртуализации, и в частности, необходима для организации работы контейнеров отдельных десктоп-приложений. При помощи OverlayFS можно организовать файловую систему, которая будет сформирована поверх доступной только на чтение основы, созданной из существующей директории в уже примонтированной типовой ФС.

ФС создаётся из нижнего и верхнего слоёв, каждый из которых прикрепляется к отдельным директориям. В качестве нижнего слоя, используемого только для чтения, могут применяться директории любых поддерживаемых в Linux систем, включая NFS и другие экземпляры OverlayFS. Верхний слой, который может быть доступен на запись, будет перекрывать состав нижнего слоя, т.е. если файлы дублируются, в итоговой ФС будет виден только перекрывающийся контент верхнего слоя. При этом все записываемые и изменяемые данные будут сохраняться только в верхнем слое, даже если изначально они размещались в нижнем слое ФС, что позволяет использовать одну основу для создания серии одинаковых окружений (контейнеры приложений), гарантировать неизменность базовых данных (гостевые сеансы) или организовать полноценную работу поверх накопителя, не поддерживающего запись (CD/DVD).

Основным недостатком ранее существующей файловой системы UnionFS и созданного на её основе ответвления AUFS является излишне усложнённая кодовая база, составляющая примерно 60 тысяч строк кода, не использующая штатную подсистему VFS. Код AUFS и UnionFS очень трудоёмок для сопровождения и не отвечает требованиям к оформлению кода для ядра Linux, что не позволяло включить его в основной состав ядра. Кроме того, производительность и надёжность данных систем оставляет желать лучшего. В рамках проекта OverlayFS предпринята попытка создания компактного, надёжного и высокопроизводительного аналога UnionFS, построенного поверх штатной подсистемы VFS.

Механизм работы OverlayFS в корне отличается от UnionFS: после открытия файла, все операции с ним напрямую транслируются непосредственно в базовые файловые системы, из которых составлен раздел OverlayFS. Подобный подход позволяет существенно упростить реализацию многослойной ФС и добиться производительности на уровне основной ФС. В OverlayFS поддерживается отдельное дерево элементов директорий (dentry), дублирующее подобные структуры низлежащих ФС, что позволяет обеспечить быстрое кэширование запросов без внесения изменений в VFS, но приводит к дополнительным затратам памяти за счёт дублирования в памяти параметров inode (предусмотрена возможность оптимизации для совместного использования inode, не привязанных к директориям).

  1. Главная ссылка к новости (http://www.heise.de/open/meldung/Linux-K...)
  2. OpenNews: Разработчики GNOME подготовили пожелания по улучшению ядра Linux
  3. OpenNews: Для Fedora Linux создан репозиторий для тестирования новинок в ядре Linux
  4. OpenNews: Red Hat и Docker развивают систему изолированных контейнеров для десктоп-приложений
Тип: Программы
Ключевые слова: overlayfs, linux, kernel, (найти похожие документы)
При перепечатке указание ссылки на opennet.ru обязательно
Реклама
id=adv>
  1.1, Lautre, 11:47, 28/10/2014 [ответить] [смотреть все]    [к модератору] +6 +/
Класс!
 
1.2, Xaionaro, 11:48, 28/10/2014 [ответить] [смотреть все]    [к модератору]
+2 +/
Рад слышать. Неудобно было использовать внешний patchset для поддержки AUFS.
Код OverlayFS принят в состав ядра Linux 3.18
 
1.3, Аноним, 12:07, 28/10/2014 [ответить] [смотреть все]     [к модератору] –1 +/
Docker заживет новой жизнью ... весь текст скрыт [показать]
 
  2.5, Аноним, 12:20, 28/10/2014 [^] [ответить] [смотреть все] [показать ветку]     [к модератору]  +/
 
    4.8, Аноним, 12:35, 28/10/2014 [^] [ответить] [смотреть все]     [к модератору]  –1 +/
а aufs как не было в 2 6 32 так и нет, nih-синдром это не шутки... весь текст скрыт [показать]
 
  5.9, Аноним, 12:41, 28/10/2014 [^] [ответить] [смотреть все]     [к модератору]  –1 +/
написали же aufs и unionfs по кодовой базе УГ если оверлай будет безглючным, ста... весь текст скрыт [показать]
 
  6.20, Mirraz, 15:44, 28/10/2014 [^] [ответить] [смотреть все]    [к модератору]  –1 +/
Написали, что aufs - плохо, а ты и поверил. Нет, это чисто NIH.
 
1.7, Michael Shigorin, 12:34, 28/10/2014 [ответить] [смотреть все]    [к модератору]  +1 +/ Отлично, будем посмотреть (ц)
Код OverlayFS принят в состав ядра Linux 3.18  
  2.10, Гость, 12:53, 28/10/2014 [^] [ответить] [смотреть все] [показать ветку]    [к модератору]  +1 +/
Михаил, меня одна из прошлых реализаций интересовала как возможность миграции данных СУБД с одного диска на другой.
Тестирование показало, что это работало не так, как ожидалось: во время внутренней дефрагментации БД, службы подвисали и новые данные не вставлялись.
Интересно было бы узнать Ваш взгляд на проблему прозрачной миграции данных с диска на диск.
 
  3.12, Аноним, 14:08, 28/10/2014 [^] [ответить] [смотреть все]     [к модератору]  +/
 
  4.16, Гость, 14:42, 28/10/2014 [^] [ответить] [смотреть все]    [к модератору]  –1 +/
Я рассматривал такой вариант, через него и осуществил затею.
Но хочется прозрачно: сверху стеклом большего размера накрыл, перерисовал и убрал подложку.
 
  5.17, Аноним, 15:07, 28/10/2014 [^] [ответить] [смотреть все]     [к модератору]  +2 +/
Хочу есть, но не ртом ... весь текст скрыт [показать]
 
5.19, Andrey Mitrofanov, 15:11, 28/10/2014 [^] [ответить] [смотреть все]    [к модератору]  +1 +/ > Я рассматривал такой вариант, через него и осуществил затею.
> Но хочется прозрачно: сверху стеклом большего размера накрыл, перерисовал и убрал подложку.

Ну, рассказывай, чем тебе pvmove не "сверху стеклом накрыл"?

 
  6.26, Sinot, 19:21, 28/10/2014 [^] [ответить] [смотреть все]    [к модератору]  +/
Я так понял, что у OverlayFS есть возможность переноса данных между дисками с разными ФС, без потери доступности данных на какое-то время. С LVM, raid и т.п. только клонирование.
image
 
3.24, Michael Shigorin, 18:42, 28/10/2014 [^] [ответить] [смотреть все]    [к модератору]  +/ > Интересно было бы узнать Ваш взгляд на проблему прозрачной миграции данных с
> диска на диск.

Если локально, то может иметь смысл MD RAID1 (обратите внимание на --write-mostly); если между хостами -- DRBD.  Но я так не делал.

image  
1.11, izyk, 12:58, 28/10/2014 [ответить] [смотреть все]    [к модератору]  +/ > построенного поверх штатной подсистемы VFS.

Ну не совсем.
      vfs: export check_sticky()
      vfs: add whiteout support
      vfs: add RENAME_WHITEOUT
      ext4: support RENAME_WHITEOUT
      shmem: support RENAME_WHITEOUT
Ох уж эти ВАЙТАУТЫ, тот еще костыль.
Не зря, Линус так долго сопротивлялся.
Но, продовили, все же.
Знаком, немного, с этим по NetBSD.
"DragonFly" гордится что ушел от этого, а в Linux,
только вкорячили.
Печалька. IMHO.

 
  2.13, Xaionaro, 14:08, 28/10/2014 [^] [ответить] [смотреть все] [показать ветку]    [к модератору]  +/
>> построенного поверх штатной подсистемы VFS.
> Ну не совсем.
>       vfs: export check_sticky()
>       vfs: add whiteout support
>       vfs: add RENAME_WHITEOUT
>       ext4: support RENAME_WHITEOUT
>       shmem: support RENAME_WHITEOUT
> Ох уж эти ВАЙТАУТЫ, тот еще костыль.

А не лень будет написать конкретнее? Что это за WHITEOUT-ы и чем они плохи? А то гуглится лишь исходный код с использованием этих {DELETE,RENAME}_WHITEOUT, но никакой документации. В результате зачем это нужно остаётся не понятным.

Самое вменяемое, что принёс поиск было: http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2005-October/003426.html

image
 
  3.15, Andrey Mitrofanov, 14:30, 28/10/2014 [^] [ответить] [смотреть все]    [к модератору]  +/
>> Ох уж эти ВАЙТАУТЫ, тот еще костыль.
> А не лень будет написать конкретнее? Что это за WHITEOUT-ы и чем
> они плохи? А то гуглится лишь исходный код с использованием этих

??! https://kernel.googlesource.com/pub/scm/linux/kernel/git/mszeredi/vfs/+/overlayfs.current/Documentation/filesystems/overlayfs.txt#84

Первая ссылка в google://overlayfs whiteout

Поддержка удаления из union-а, когда ниже лежащая FS - в read-only, наверное.

> {DELETE,RENAME}_WHITEOUT, но никакой документации. В результате зачем это нужно остаётся
> не понятным.

 
  4.18, izyk, 15:10, 28/10/2014 [^] [ответить] [смотреть все]    [к модератору]  +1 +/
>>> Ох уж эти ВАЙТАУТЫ, тот еще костыль.
>> А не лень будет написать конкретнее? Что это за WHITEOUT-ы и чем
>> они плохи? А то гуглится лишь исходный код с использованием этих
> ??! https://kernel.googlesource.com/pub/scm/linux/kernel/git/mszeredi/vfs/+/overlayfs.current/Documentation/filesystems/overlayfs.txt#84
> Первая ссылка в google://overlayfs whiteout
> Поддержка удаления из union-а, когда ниже лежащая FS - в read-only, наверное.

Точно.
В каталоге появляется запись с именем файла и типом "whiteout", по сути,
новый тип файла.
Я так понял, такие каталоги были давно, а вот их поддержку, на уровне VFS,
вкорячили только сейчас.
По мне, чем меньше сущностей, тем лучше.
Хотя реализация, на какое-то время, упростится, но взаимосвязь
overlayfs <-> VFS будет расти.

 
4.21, Xaionaro, 16:40, 28/10/2014 [^] [ответить] [смотреть все]    [к модератору]  +/ >>> Ох уж эти ВАЙТАУТЫ, тот еще костыль.
>> А не лень будет написать конкретнее? Что это за WHITEOUT-ы и чем
>> они плохи? А то гуглится лишь исходный код с использованием этих
> ??! https://kernel.googlesource.com/pub/scm/linux/kernel/git/mszeredi/vfs/+/overlayfs.current/Documentation/filesystems/overlayfs.txt#84
> Первая ссылка в google://overlayfs whiteout

Ок, спасибо. Я гуглил без слова "overlayfs", так как думал, что это более общая вещь.

image  

Ваш комментарий  

Read more http://www.opennet.ru/opennews/art.shtml?num=40947