The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

28.10.2014 10:42  Код OverlayFS принят в состав ядра Linux 3.18

В тестовом выпуске ядра 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/meldu...)
  2. OpenNews: Разработчики GNOME подготовили пожелания по улучшению ядра Linux
  3. OpenNews: Для Fedora Linux создан репозиторий для тестирования новинок в ядре Linux
  4. OpenNews: Red Hat и Docker развивают систему изолированных контейнеров для десктоп-приложений
Лицензия: CC-BY
Тип: Программы
Ключевые слова: overlayfs, linux, kernel
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Lautre (ok), 11:47, 28/10/2014 [ответить] [показать ветку] [···]    [к модератору]
  • +10 +/
    Класс!
     
     
  • 2.29, crypt (ok), 21:38, 28/10/2014 [^] [ответить]    [к модератору]
  • +/
    +6? а в каких случаях вы используете это?
     
     
  • 3.31, uhbif19_ (?), 21:51, 28/10/2014 [^] [ответить]    [к модератору]
  • +/
    AuFS используется Docker.
     
  • 3.36, Lautre (ok), 09:16, 29/10/2014 [^] [ответить]    [к модератору]
  • –1 +/
    > +6? а в каких случаях вы используете это?

    Livecd кальки работают на aufs + утилиты calculate-assemble 3.

     
  • 1.2, Xaionaro (ok), 11:48, 28/10/2014 [ответить] [показать ветку] [···]    [к модератору]
  • +2 +/
    Рад слышать. Неудобно было использовать внешний patchset для поддержки AUFS.
     
  • 1.3, Аноним (-), 12:07, 28/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    Docker заживет новой жизнью.
     
     
  • 2.5, Аноним (-), 12:20, 28/10/2014 [^] [ответить]    [к модератору]  
  • +/
    в венде и шапке её всё равно не будет, в отличие от докера
     
     
  • 3.6, Michael Shigorin (ok), 12:33, 28/10/2014 [^] [ответить]    [к модератору]  
  • +1 +/
    > в венде и шапке её всё равно не будет, в отличие от докера

    Как полагаете, сколько лет этому патчсету и много ли подобных в шапочных "2.6.32" и "3.10"?

     
     
  • 4.8, Аноним (-), 12:35, 28/10/2014 [^] [ответить]    [к модератору]  
  • –1 +/
    а aufs как не было в 2.6.32 так и нет, nih-синдром это не шутки
     
     
  • 5.9, Аноним (-), 12:41, 28/10/2014 [^] [ответить]    [к модератору]  
  • +/
    написали же aufs и unionfs по кодовой базе УГ
    если оверлай будет безглючным, стабильным, шустрым, то редхат при необходимости портирует его куда угодно, кроме 2.6.32 тк возможна проблема с vfs
     
     
  • 6.20, Mirraz (ok), 15:44, 28/10/2014 [^] [ответить]    [к модератору]  
  • –1 +/
    Написали, что aufs - плохо, а ты и поверил. Нет, это чисто NIH.
     
     
  • 7.22, Led (ok), 17:39, 28/10/2014 [^] [ответить]    [к модератору]  
  • +4 +/
    > Написали, что aufs - плохо, а ты и поверил. Нет, это чисто
    > NIH.

    Ну, ты же внимательно смотрел код aufs, поэтому точно знаешь, что "это чисто NIH".

     
  • 1.7, Michael Shigorin (ok), 12:34, 28/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Отлично, будем посмотреть (ц)
     
     
  • 2.10, Гость (??), 12:53, 28/10/2014 [^] [ответить]     [к модератору]  
  • +1 +/
    Михаил, меня одна из прошлых реализаций интересовала как возможность миграции да... весь текст скрыт [показать]
     
     
  • 3.12, Аноним (-), 14:08, 28/10/2014 [^] [ответить]    [к модератору]  
  • +/
    LVM?
     
     
  • 4.16, Гость (??), 14:42, 28/10/2014 [^] [ответить]    [к модератору]  
  • –1 +/
    Я рассматривал такой вариант, через него и осуществил затею.
    Но хочется прозрачно: сверху стеклом большего размера накрыл, перерисовал и убрал подложку.
     
     
  • 5.17, Аноним (-), 15:07, 28/10/2014 [^] [ответить]    [к модератору]  
  • +3 +/
    "Хочу есть, но не ртом."
     
  • 5.19, Andrey Mitrofanov (?), 15:11, 28/10/2014 [^] [ответить]     [к модератору]  
  • +1 +/
    Ну, рассказывай, чем тебе pvmove не сверху стеклом накрыл ... весь текст скрыт [показать]
     
     
  • 6.26, Sinot (ok), 19:21, 28/10/2014 [^] [ответить]    [к модератору]  
  • +/
    Я так понял, что у OverlayFS есть возможность переноса данных между дисками с разными ФС, без потери доступности данных на какое-то время. С LVM, raid и т.п. только клонирование.
     
     
  • 7.28, Аноним (-), 21:37, 28/10/2014 [^] [ответить]    [к модератору]  
  • +/
    хреново документацию читал pvmove перемещает экстенты между pv на ходу
     
     
  • 8.30, Sinot (ok), 21:51, 28/10/2014 [^] [ответить]    [к модератору]  
  • +/
    То есть если у меня есть lv с ext4 и lv с fat32, я с помощью pv смогу перенести файлы с одного на другой? На сколько я прочитал документацию - нет.
     
     
  • 9.32, Аноним (-), 22:03, 28/10/2014 [^] [ответить]    [к модератору]  
  • +/
    тебе не нужен второй lv, первый lv просто переезжает с одного pv на другой.
     
     
  • 10.35, Sinot (ok), 08:42, 29/10/2014 [^] [ответить]     [к модератору]  
  • +1 +/
    Мы друг друга не поняли У меня есть диск с одной ФС, я хочу переехать на другой... весь текст скрыт [показать]
     
     
  • 11.40, Гость (??), 12:00, 30/10/2014 [^] [ответить]     [к модератору]  
  • +/
    Именно Я ровно того же хочу Есть гора серверов с зоопарками файловых систем, к... весь текст скрыт [показать]
     
  • 11.42, Andrey Mitrofanov (?), 09:56, 31/10/2014 [^] [ответить]     [к модератору]  
  • +1 +/
    Ммм, ну да, use case Правда если прикинуть частоту перехода на новую FS прибли... весь текст скрыт [показать]
     
  • 11.43, Andrey Mitrofanov (?), 10:05, 31/10/2014 [^] [ответить]    [к модератору]  
  • +1 +/
    >Да еще и так, чтобы для всех этот переезд  виден не был.

    Да, остановить Сервис и сделать rsync тяжелее, конечно, чем...

    Или даже _невозможно! Так и видится файловая помойка ("куча" ф.помоек!) с требованием online-а в 9 девяток и непрерывным циклом доменно-прокатного редактирования вордов-эксельчиков. Страх и ужас.

    ---
    Про fat+rieser в связке не скажу, но вот, например, http://gluster.org/community/documentation/index.php/Gluster_3.2:_Migrating_Volumes ещё, возможно, способ.

     
  • 3.24, Michael Shigorin (ok), 18:42, 28/10/2014 [^] [ответить]    [к модератору]  
  • +/
    > Интересно было бы узнать Ваш взгляд на проблему прозрачной миграции данных с
    > диска на диск.

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

     
  • 1.11, izyk (ok), 12:58, 28/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    > построенного поверх штатной подсистемы 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 (ok), 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

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

    ??! https://kernel.googlesource.com/pub/scm/linux/kernel/git/mszeredi/vfs/+/overla

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

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

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

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

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

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

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

     
     
  • 5.25, izyk (ok), 19:06, 28/10/2014 [^] [ответить]    [к модератору]  
  • +/

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

    Да, более общая.
    unionfs whiteout
    aufs whiteout

     
  • 3.23, Konstantin (??), 17:49, 28/10/2014 [^] [ответить]    [к модератору]  
  • +2 +/
    давно еще писал, что такое вайтаут:

    http://unixfaq.ru/index.pl?req=qs&id=414

    плохи вайтауты тем, что это очередная загогулина в реализации FS, которую потом необходимо учитывать при разработках нового и доработках старого. Не все ФС могут поддерживать вайтауты.

     
  • 2.14, Минона (?), 14:20, 28/10/2014 [^] [ответить]    [к модератору]  
  • +/
    >"DragonFly" гордится что ушел от этого

    да он много от кого/чего ушел... пришел бы еще куда-нибудь :)

     
  • 2.37, seyko2 (ok), 10:09, 29/10/2014 [^] [ответить]    [к модератору]  
  • –2 +/
    Каким образом DragonFly ушёл от whiteout? В Linux планировали реализовать witeout через специальный char device. Возможно так и сделали. Однако OvelayFS не достаточно для нормального livecd типа Slax. OverlayFS позволяет объединить только два каталога -- read-write и read-only. А желательно как минимум много read-only.
     
  • 1.27, Gannet (ok), 19:47, 28/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    Чудесно. Только вот RC2 не грузится. Упс.
     
  • 1.34, pavlinux (ok), 01:43, 29/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Ура, мои сигналы в ноосферу достигли их мозгов спустя 20 лет!
     
     
  • 2.41, andy (??), 06:13, 31/10/2014 [^] [ответить]    [к модератору]  
  • +1 +/
    > Ура, мои сигналы в ноосферу достигли их мозгов спустя 20 лет!

    В следующий раз в багтрекер стучись или в рассылку пиши.

     
     
  • 3.45, Аноним (-), 02:04, 04/11/2014 [^] [ответить]    [к модератору]  
  • +/
    Не всегда и не все так просто порой проще отправить в Ноосферу гораздо проще чем зарегистрироваться или создать Issue а баг трекере. Хотя тенденция сейчас хорошая пошла открывать код и т.д.
     
  • 1.44, Аноним (-), 02:02, 04/11/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    А что с удалением? А что с повторным монтированием? А в файл можно?
    А что насчет замены SCM такой штуковиной?
     
  • 1.46, iZEN (ok), 11:50, 14/08/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Так это ж nullfs из FreeBSD, которой сто лет в обед: "The nullfs layer first appeared in 4.4BSD."
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2019 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor