Важно отметить, особенно в Linux, что экспериментальный также может означать «код, который кто-то сюда сбросил, который в то время выглядел приемлемым, но не мог активно поддерживаться».
Я большой поклонник хранения файловых систем в пользовательском пространстве, но я должен также указать, что я большой энтузиаст микроядра . Я считаю целесообразным и предпочтительным хранить файловые системы в пользовательском пространстве по следующим причинам:
Файловые системы в пользовательском пространстве проще поддерживать
Найдите минутку, чтобы взглянуть на ext3cow файловую систему , проект PHD, получивший значительную поддержку в течение очень короткого времени. Его автор закончил, а затем перешел к карьере, имея очень мало времени для работы с файловой системой. Из-за того, что в Linux нет ничего общего, внутреннее перемещение Linux между версиями требует, чтобы каждый, кто хочет использовать его в современном ядре, имел глубокие знания, которыми обладают немногие.
Если бы он использовал FUSE API, его было бы намного проще поддерживать, и фактическая работа, направленная на преобразование ext3 в файловую систему копирования при записи, получила бы больше информации. Это также относится к коду в ядре, который набирает плесень, потому что никто не достаточно смел (или скучен), чтобы прикоснуться к нему.
Файловые системы в пользовательском пространстве легче отлаживать
В пользовательском пространстве у вас есть замечательные инструменты, такие как Valgrind (и его друзья, такие как массив), которые являются бесценными инструментами и просты в использовании. Кривая обучения, связанная с отладкой ядра, часто слишком велика для многих, чтобы просто приступить к написанию кода. Обратите внимание, что я делаю четкое разделение архитектуры FUSE и микроядра, как отмечено в этом ответе . Некоторые системы, основанные на микроядрах, чрезвычайно сложны для отладки, в основном из-за гонок в связи между запущенными сервисами (vfs, блочное устройство, файловая система, ipc). В обоих случаях код легче отлаживать, потому что его из ядра, при условии, что его нет в ядре, не вызывает странных сложностей.
В любом случае я возьму GDB и Valgrind за шумную printk() отладку в любой день или за попытку разобраться в довольно загадочных хуках отладки ядра, присутствующих в Linux. Мне также понравится возможность использовать любую отладочную (или даже сборку мусора ) malloc() реализацию, которую я выберу. То же самое относится и к моей избранной библиотеке C, при условии, что она работает с FUSE. Я не разбираюсь с библиотекой ядра Linux, но мне нравятся мои удобства создания.
Пользовательские файловые системы проще в использовании
Для малообеспеченных пользователей очень полезно иметь возможность монтировать и поддерживать любую файловую систему, которую они хотят использовать, но на самом деле это конечная игра. Если ваша файловая система находится вне ядра, она может развиваться независимо от ядра, что означает, что пользователи могут обновить настроенный до ваш цикл выпуска. Вы могли бы достичь 6 этапов за время, необходимое Linux для перехода к следующему варианту выпуска. Это также позволяет дистрибьюторам и OEM-производителям вывести вашу FS в дикую природу, где она проходит необходимое тестирование быстрее, чем если бы это был модуль ядра.
Норман Рэмси уже описал фактор надежности, связанный с файловыми системами как сервисом в архитектуре микроядра. Однако надежность означает, что не требуется служба реинкарнации, которая имеет тенденцию скрывать (или откладывать) ошибки и другие проблемы. Я согласен с тем, что хорошо, если неудачное монтирование root не приводит к прерыванию ядра, но это возможно и для монолитных ядер с поддержкой FUSE.
Таким образом, написание файловой системы достаточно сложно без необходимости работать в пространстве ядра. Я бы предпочел использовать FUSE API или изучить реализацию службы IPC / VFS в микроядерной ОС, чем писать ее как модуль ядра.