OverlayFS включают в ядро
Опубликовано 24.10.2014 17:54 пользователем Peter Lemenkov
Наконец-то, после 25й (!) итерации, OverlayFS включили в дерево vfs.git. Еще пара-тройка шагов, и его включат в официальный Git-репозиторий Торвальдса.
OverlayFS, это результат более чем четырехлетней разработки Miklos Szeredi, разработчика FUSE. Целью проекта является создание "многослойной" файловой системы, объединяющей другие файловые системы в одну, и предоставляющей возможность "форка" полученной системы. Одним из приложений этой функциональности были LiveCD, которые таким образом планировали предоставлять возможность прозрачного доступа к системе на чтение-запись. Еще вариантом использования была функциональность "factory reset" в embedded-системах (телефоны, роутеры, медиаплейеры), когда основная система никогда не изменялась, а настройки велись в union-fs. С развитием облачных технологий появилось еще одно применение - большая часть облачных систем идентична, и хочется эту общую часть разделять между сотнями и тысячами контейнеров в хостовой системе одновременно позволяя всем контейнеризированным приложениям ее изменять, если нужно.
Существовало несколько реализаций Union-FS в разных системах (хороший обзор был сделан Valerie Aurora на LWN.net - первая часть и вторая часть), но в Linux ни одна из реализаций не добралась до ванильного ядра. Причин тому много - архитектурная усложненность, низкое качество кода,высокий уровень ненависти в рассылке ядра социально-личностные проблемы. Ближе всех к ядру подобралась было AuFS, и ее даже поспешно включили в ряд Debian-based дистрибутивов. Но быстро выяснилось, что это было ошибкой, т.к. система оказалась чрезвычайно сложной, хрупкой, и бесперспективной для включения в ядро. Но ущерб поспешными действиями мэйнтейнеров был нанесен - разработчики Docker, по наивности полагаясь на возможности, присутствовавшие в самом популярном Linux-дистрибутиве, решили базироваться на aufs. Непонятно, почему они не проконсультировались с нашими коллегами, которые бы наверняка подсказали более рациональное решение. Так или иначе, когда у Red Hat появился интерес к Docker, то наши коллеги протянули руку помощи зашедшему в архитектурный тупик проекту, переведя его на Device Mapper.
История OverlayFS началась давно, и по сравнению с другими вариантами, система выглядела очень простой. Мэйнтейнеры ядра, придерживаясь их неповторимого стиля общения в списке рассылки ядра, отозвались о патчсете окрыляюще для начинающих - Andrew Morton сказал, что ему проще не принимать его, а на последовавшее предложение перенести функционал в FUSE-модуль в userspace, Linus Torvalds, в присутствии разработчика userspace-файловых систем, высказался, что люди, разрабатывающие файловые системы в userspace просто заблуждаются. Получив свою дозу мотиваторов, Miklos за три года совершил еще две дюжины попыток, и наконец-то пробился!
Одним из первых пользователей OverlayFS были разработчики OpenWRT, и недаром - factory reset и откат при аварии обновления для них является обязательной фичей. Как вы знаете, атомарное, консистентное, изолированное и надежное обновление системы в рамках старой Linux-архитектуры сейчас в общем случае невозможно. Особенно сложно добиться хотя бы частичного удовлетворения ACID, если использовать не RPM, а один из нестандартных самодельных пакетных менеджеров (некоторые из них довольно популярны, и их примитивность и малофункциональность порой видится их наивными пользователями как преимущество перед сложным RPM). Наши коллеги работают над надежными апдейтами довольно давно - offline-апдейты, перенос всего в /usr, использование btrfs, контейнеризация и изоляция приложений, инициатива Fedora Atomic, и многое другое. До чего-то работающего еще пока, к сожалению, довольно далеко.
OverlayFS, это результат более чем четырехлетней разработки Miklos Szeredi, разработчика FUSE. Целью проекта является создание "многослойной" файловой системы, объединяющей другие файловые системы в одну, и предоставляющей возможность "форка" полученной системы. Одним из приложений этой функциональности были LiveCD, которые таким образом планировали предоставлять возможность прозрачного доступа к системе на чтение-запись. Еще вариантом использования была функциональность "factory reset" в embedded-системах (телефоны, роутеры, медиаплейеры), когда основная система никогда не изменялась, а настройки велись в union-fs. С развитием облачных технологий появилось еще одно применение - большая часть облачных систем идентична, и хочется эту общую часть разделять между сотнями и тысячами контейнеров в хостовой системе одновременно позволяя всем контейнеризированным приложениям ее изменять, если нужно.
Существовало несколько реализаций Union-FS в разных системах (хороший обзор был сделан Valerie Aurora на LWN.net - первая часть и вторая часть), но в Linux ни одна из реализаций не добралась до ванильного ядра. Причин тому много - архитектурная усложненность, низкое качество кода,
История OverlayFS началась давно, и по сравнению с другими вариантами, система выглядела очень простой. Мэйнтейнеры ядра, придерживаясь их неповторимого стиля общения в списке рассылки ядра, отозвались о патчсете окрыляюще для начинающих - Andrew Morton сказал, что ему проще не принимать его, а на последовавшее предложение перенести функционал в FUSE-модуль в userspace, Linus Torvalds, в присутствии разработчика userspace-файловых систем, высказался, что люди, разрабатывающие файловые системы в userspace просто заблуждаются. Получив свою дозу мотиваторов, Miklos за три года совершил еще две дюжины попыток, и наконец-то пробился!
Одним из первых пользователей OverlayFS были разработчики OpenWRT, и недаром - factory reset и откат при аварии обновления для них является обязательной фичей. Как вы знаете, атомарное, консистентное, изолированное и надежное обновление системы в рамках старой Linux-архитектуры сейчас в общем случае невозможно. Особенно сложно добиться хотя бы частичного удовлетворения ACID, если использовать не RPM, а один из нестандартных самодельных пакетных менеджеров (некоторые из них довольно популярны, и их примитивность и малофункциональность порой видится их наивными пользователями как преимущество перед сложным RPM). Наши коллеги работают над надежными апдейтами довольно давно - offline-апдейты, перенос всего в /usr, использование btrfs, контейнеризация и изоляция приложений, инициатива Fedora Atomic, и многое другое. До чего-то работающего еще пока, к сожалению, довольно далеко.