В тестовом выпуске ядра Linux 3.18-rc2 появилась (https://lkml.org/lkml/2014/10/26/137) поддержка файловой системы OverlayFS (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....), разработанной компанией SUSE в качестве более прогрессивной замены UnionFS (http://unionfs.filesystems.org/) и AUFS (http://aufs.sourceforge.net/). В процессе цикла подготовки первого кандидата в релизы, включение OverlayFS в состав ядра было отложено, но в последний момент разработчикам удалось устранить финальные замечания и код был принят во второй кандидат в релизы.
OverlayFS позволяет (https://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.gi...) создать виртуальную многослойную файловую систему, объединяющую несколько частей других файловых систем. OverlayFS входит в число наиболее ожидаемых в ядре возможностей, так как монослойная ФС востребована в Live-дистрибутивах и системах контейнерной виртуализации, и в частности, необходима для организации работы контейнеров отдельных десктоп-приложений (https://www.opennet.ru/opennews/art.shtml?num=40176). При помощи OverlayFS можно организовать файловую систему, которая будет сформирована поверх доступной только на чтение основы, созданной из существующей директории в уже примонтированной типовой ФС.ФС создаётся из нижнего и верхнего слоёв, каждый из которых прикрепляется к отдельным директориям. В качестве нижнего слоя, используемого только для чтения, могут применяться директории любых поддерживаемых в Linux систем, включая NFS и другие экземпляры OverlayFS. Верхний слой, который может быть доступен на запись, будет перекрывать состав нижнего слоя, т.е. если файлы дублируются, в итоговой ФС будет виден только перекрывающийся контент верхнего слоя. При этом все записываемые и изменяемые данные будут сохраняться только в верхнем слое, даже если изначально они размещались в нижнем слое ФС, что позволяет использовать одну основу для создания серии одинаковых окружений (контейнеры приложений), гарантировать неизменность базовых данных (гостевые сеансы) или организовать полноценную работу поверх накопителя, не поддерживающего запись (CD/DVD).
Основным недостатком ранее существующей файловой системы UnionFS и созданного на её основе ответвления AUFS является излишне усложнённая кодовая база, составляющая примерно 60 тысяч строк кода, не использующая штатную подсистему VFS. Код AUFS и UnionFS очень трудоёмок для сопровождения и не отвечает требованиям к оформлению кода для ядра Linux, что не позволяло включить его в основной состав ядра. Кроме того, производительность и надёжность данных систем оставляет желать лучшего (http://lwn.net/Articles/396020/). В рамках проекта OverlayFS предпринята попытка создания компактного, надёжного и высокопроизводительного аналога UnionFS, построенного поверх штатной подсистемы VFS.
Механизм работы OverlayFS в корне отличается от UnionFS: после открытия файла, все операции с ним напрямую транслируются непосредственно в базовые файловые системы, из которых составлен раздел UnionFS. Подобный подход позволяет существенно упростить реализацию многослойной ФС и добиться производительности на уровне основной ФС. В OverlayFS поддерживается отдельное дерево элементов директорий (dentry), дублирующее подобные структуры низлежащих ФС, что позволяет обеспечить быстрое кэширование запросов без внесения изменений в VFS, но приводит к дополнительным затратам памяти за счёт дублирования в памяти параметров inode (предусмотрена возможность оптимизации для совместного использования inode, не привязанных к директориям).
URL: http://www.heise.de/open/meldung/Linux-Kernel-mit-OverlayFS-...
Новость: https://www.opennet.ru/opennews/art.shtml?num=40947
Класс!
+6? а в каких случаях вы используете это?
AuFS используется Docker.
> +6? а в каких случаях вы используете это?Livecd кальки работают на aufs + утилиты calculate-assemble 3.
Рад слышать. Неудобно было использовать внешний patchset для поддержки AUFS.
Docker заживет новой жизнью.
в венде и шапке её всё равно не будет, в отличие от докера
> в венде и шапке её всё равно не будет, в отличие от докераКак полагаете, сколько лет этому патчсету и много ли подобных в шапочных "2.6.32" и "3.10"?
а aufs как не было в 2.6.32 так и нет, nih-синдром это не шутки
написали же aufs и unionfs по кодовой базе УГ
если оверлай будет безглючным, стабильным, шустрым, то редхат при необходимости портирует его куда угодно, кроме 2.6.32 тк возможна проблема с vfs
Написали, что aufs - плохо, а ты и поверил. Нет, это чисто NIH.
> Написали, что aufs - плохо, а ты и поверил. Нет, это чисто
> NIH.Ну, ты же внимательно смотрел код aufs, поэтому точно знаешь, что "это чисто NIH".
Отлично, будем посмотреть (ц)
Михаил, меня одна из прошлых реализаций интересовала как возможность миграции данных СУБД с одного диска на другой.
Тестирование показало, что это работало не так, как ожидалось: во время внутренней дефрагментации БД, службы подвисали и новые данные не вставлялись.
Интересно было бы узнать Ваш взгляд на проблему прозрачной миграции данных с диска на диск.
LVM?
Я рассматривал такой вариант, через него и осуществил затею.
Но хочется прозрачно: сверху стеклом большего размера накрыл, перерисовал и убрал подложку.
"Хочу есть, но не ртом."
> Я рассматривал такой вариант, через него и осуществил затею.
> Но хочется прозрачно: сверху стеклом большего размера накрыл, перерисовал и убрал подложку.Ну, рассказывай, чем тебе pvmove не "сверху стеклом накрыл"?
Я так понял, что у OverlayFS есть возможность переноса данных между дисками с разными ФС, без потери доступности данных на какое-то время. С LVM, raid и т.п. только клонирование.
хреново документацию читал pvmove перемещает экстенты между pv на ходу
То есть если у меня есть lv с ext4 и lv с fat32, я с помощью pv смогу перенести файлы с одного на другой? На сколько я прочитал документацию - нет.
тебе не нужен второй lv, первый lv просто переезжает с одного pv на другой.
Мы друг друга не поняли. У меня есть диск с одной ФС, я хочу переехать на другой диск с другой ФС, да еще до кучи на втором диске уже есть данные и их терять нельзя. Иначе говоря нужно скопировать с одного на другой файлы, а не разделы. Да еще и так, чтобы для всех этот переезд виден не был.
Именно. Я ровно того же хочу. Есть гора серверов с зоопарками файловых систем, которые надо плавно проапрейдить.
У кого-то xfs, где-то лет 10 работает reiserfs, где-то даже ntfs.
Всё это добро надо перетащить на новые хранилища, где и места дам машинам больше, и файловые системы сменятся у некоторых.
> Мы друг друга не поняли. У меня есть диск с одной ФС,
> я хочу переехать на другой диск с другой ФС, да еще
>Да еще и так, чтобы для всех этот переезд
> виден не был.Ммм, ну да, use case. Правда если прикинуть частоту перехода на новую FS (приблизительно оцениваю как частоту/скорость написания новой FS), помножить на "куча серверов", то можно только _удивляться, как они *так* *быстро* выкатили эту нужную фичу. Видимо, все "спасибы" гламурным контенерезаторам.
>Да еще и так, чтобы для всех этот переезд виден не был.Да, остановить Сервис и сделать rsync тяжелее, конечно, чем...
Или даже _невозможно! Так и видится файловая помойка ("куча" ф.помоек!) с требованием online-а в 9 девяток и непрерывным циклом доменно-прокатного редактирования вордов-эксельчиков. Страх и ужас.
---
Про fat+rieser в связке не скажу, но вот, например, http://gluster.org/community/documentation/index.php/Gluster... ещё, возможно, способ.
> Интересно было бы узнать Ваш взгляд на проблему прозрачной миграции данных с
> диска на диск.Если локально, то может иметь смысл MD RAID1 (обратите внимание на --write-mostly); если между хостами -- DRBD. Но я так не делал.
> построенного поверх штатной подсистемы 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.
>> построенного поверх штатной подсистемы 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/...
>> Ох уж эти ВАЙТАУТЫ, тот еще костыль.
> А не лень будет написать конкретнее? Что это за WHITEOUT-ы и чем
> они плохи? А то гуглится лишь исходный код с использованием этих??! https://kernel.googlesource.com/pub/scm/linux/kernel/git/msz...
Первая ссылка в google://overlayfs whiteout
Поддержка удаления из union-а, когда ниже лежащая FS - в read-only, наверное.
> {DELETE,RENAME}_WHITEOUT, но никакой документации. В результате зачем это нужно остаётся
> не понятным.
>>> Ох уж эти ВАЙТАУТЫ, тот еще костыль.
>> А не лень будет написать конкретнее? Что это за WHITEOUT-ы и чем
>> они плохи? А то гуглится лишь исходный код с использованием этих
> ??! https://kernel.googlesource.com/pub/scm/linux/kernel/git/msz...
> Первая ссылка в google://overlayfs whiteout
> Поддержка удаления из union-а, когда ниже лежащая FS - в read-only, наверное.Точно.
В каталоге появляется запись с именем файла и типом "whiteout", по сути,
новый тип файла.
Я так понял, такие каталоги были давно, а вот их поддержку, на уровне VFS,
вкорячили только сейчас.
По мне, чем меньше сущностей, тем лучше.
Хотя реализация, на какое-то время, упростится, но взаимосвязь
overlayfs <-> VFS будет расти.
>>> Ох уж эти ВАЙТАУТЫ, тот еще костыль.
>> А не лень будет написать конкретнее? Что это за WHITEOUT-ы и чем
>> они плохи? А то гуглится лишь исходный код с использованием этих
> ??! https://kernel.googlesource.com/pub/scm/linux/kernel/git/msz...
> Первая ссылка в google://overlayfs whiteoutОк, спасибо. Я гуглил без слова "overlayfs", так как думал, что это более общая вещь.
> Ок, спасибо. Я гуглил без слова "overlayfs", так как думал, что это
> более общая вещь.Да, более общая.
unionfs whiteout
aufs whiteout
давно еще писал, что такое вайтаут:http://unixfaq.ru/index.pl?req=qs&id=414
плохи вайтауты тем, что это очередная загогулина в реализации FS, которую потом необходимо учитывать при разработках нового и доработках старого. Не все ФС могут поддерживать вайтауты.
>"DragonFly" гордится что ушел от этогода он много от кого/чего ушел... пришел бы еще куда-нибудь :)
Каким образом DragonFly ушёл от whiteout? В Linux планировали реализовать witeout через специальный char device. Возможно так и сделали. Однако OvelayFS не достаточно для нормального livecd типа Slax. OverlayFS позволяет объединить только два каталога -- read-write и read-only. А желательно как минимум много read-only.
Чудесно. Только вот RC2 не грузится. Упс.
Ура, мои сигналы в ноосферу достигли их мозгов спустя 20 лет!
> Ура, мои сигналы в ноосферу достигли их мозгов спустя 20 лет!В следующий раз в багтрекер стучись или в рассылку пиши.
Не всегда и не все так просто порой проще отправить в Ноосферу гораздо проще чем зарегистрироваться или создать Issue а баг трекере. Хотя тенденция сейчас хорошая пошла открывать код и т.д.
А что с удалением? А что с повторным монтированием? А в файл можно?
А что насчет замены SCM такой штуковиной?
Так это ж nullfs из FreeBSD, которой сто лет в обед: "The nullfs layer first appeared in 4.4BSD."