Своя файловая система без единой строчки кода в ядре Linux

Раньше создание новой файловой системы было занятием для избранных. Код жил внутри ядра, ошибка в нём роняла всю машину, а отладка превращалась в пытку с перезагрузками. Поэтому файловых систем было мало, и писали их немногие. FUSE перевернул эту картину, позволив реализовать полноценную файловую систему обычной программой в пространстве пользователя, на любом удобном языке, без права суперпользователя и без риска уронить ядро. Рабочий прототип теперь дело одного вечера, а не месяцев ковыряния в ядерном коде.

Аббревиатура расшифровывается как файловая система в пространстве пользователя. Идею в 2001 году предложил венгерский программист Миклош Середи, и с тех пор на ней выросла целая экосистема: удалённый доступ к серверам как к локальным дискам, монтирование облачных хранилищ, прозрачное шифрование, чтение архивов без распаковки. Всё это работает поверх одного и того же механизма, и понять его устройство значит понять, где FUSE незаменим, а где упирается в свой главный недостаток.

Как запрос к файлу путешествует из ядра в обычную программу и обратно

В основе FUSE лежит разделение на две части: модуль ядра и библиотека пространства пользователя. Модуль ядра встраивается в виртуальную файловую систему, общий слой, через который проходят все обращения к любым файлам в Linux. Когда приложение читает файл на FUSE-разделе, обычным вызовом чтения, виртуальная файловая система переадресует этот запрос не драйверу диска, а модулю FUSE. Модуль же выставляет запрос в особое устройство в системе, через которое общается с пространством пользователя.

С другой стороны этого устройства сидит демон, написанный разработчиком. Он вычитывает пришедший запрос, выполняет его собственной логикой, чем угодно, от обращения к облаку до генерации данных на лету, и пишет ответ обратно в устройство. Модуль ядра принимает ответ и возвращает его виртуальной файловой системе, а та отдаёт приложению. С точки зрения приложения всё выглядит как обращение к обычной файловой системе, оно даже не подозревает, что за монтированием стоит программа в пользовательском пространстве.

Библиотека пространства пользователя берёт на себя рутину общения с устройством и протоколом, оставляя разработчику только содержательную часть: реализовать набор операций вроде чтения каталога, открытия файла, чтения и записи. Минимальная реализация на C сводится к заполнению таблицы обработчиков и передаче её в главный цикл библиотеки:

#define FUSE_USE_VERSION 31
#include <fuse3/fuse.h>

static int my_read(const char *path, char *buf, size_t size,
                   off_t offset, struct fuse_file_info *fi) {
    /* здесь своя логика: отдать данные из облака, из памяти, откуда угодно */
    return filled_bytes;
}

static const struct fuse_operations ops = {
    .getattr = my_getattr,   /* атрибуты файла */
    .readdir = my_readdir,   /* содержимое каталога */
    .open    = my_open,      /* открытие */
    .read    = my_read,      /* чтение */
};

int main(int argc, char *argv[]) {
    return fuse_main(argc, argv, &ops, NULL);  /* запускаем цикл обработки */
}

Запускать демон можно языком на выбор: существуют привязки для Python, Go, Rust и многих других, что и делает FUSE таким доступным. Реальная история из инженерной практики показательна: команде понадобился мост между стандартными инструментами и нестандартным хранилищем двоичных объектов, и вместо обёрток и временных загрузчиков один FUSE-демон на C отобразил каждый объект как файл в каталоге. Инструменты остались нетронутыми, временные файлы исчезли, а решение стало штатным интерфейсом к внутреннему хранилищу.

Важно понимать, что FUSE поддерживает два рода файловых систем. Обычная виртуальная файловая система ничем не подкреплена на диске и целиком порождается логикой демона: содержимое существует ровно постольку, поскольку его выдаёт обработчик. Второй род подкреплён блочным устройством, и тут FUSE служит прослойкой между ядром и кодом, который сам разбирает формат раздела на устройстве. Первый вариант годится для облачных мостов, генераторов данных на лету и представления чего угодно деревом файлов, второй для реализации настоящих дисковых форматов в пространстве пользователя. Большинство популярных применений, от удалённого доступа до монтирования архивов, относятся к первому роду, потому что именно в нём раскрывается главная свобода FUSE: данные могут браться откуда угодно, а не только с локального диска.

Почему за гибкость приходится платить производительностью

Главная цена удобства FUSE это накладные расходы на пересечение границы между ядром и пространством пользователя. У обычной файловой системы вызов обслуживается внутри ядра целиком. У FUSE каждая операция совершает дополнительные путешествия через эту границу: запрос идёт из приложения в ядро, оттуда в демон пользователя, ответ возвращается тем же путём обратно. Получается порядка четырёх пересечений границы на операцию, вдвое больше, чем у нативной файловой системы, и каждое такое переключение контекста стоит процессорного времени и добавляет задержку.

Отсюда репутация FUSE как чего-то медленного, и отчасти она заслужена, но лишь отчасти. Опыт крупных проектов показывает, что на большинстве реальных сценариев FUSE укладывается в требования по производительности. Скажем, распределённая файловая система, построенная на FUSE, в большинстве задач, связанных с искусственным интеллектом, удовлетворяет требованиям к скорости. Истина в том, что не все FUSE-системы медленные: для инструментов разработчика, интроспекции системы, имитации интерфейсов производительность обычно более чем достаточна, и такие решения спокойно крутятся в конвейерах сборки ежедневно и ежечасно.

Снизить накладные расходы помогает несколько приёмов. Кеширование на стороне ядра позволяет повторные чтения обслуживать без обращения к демону, многопоточная обработка распараллеливает запросы, укрупнение операций чтения уменьшает их число. Когда производительность всё же проседает, диагностируют узкое место привычными инструментами трассировки системных вызовов и профилирования, сравнивая FUSE-монтирование с эталоном вроде файловой системы в оперативной памяти, чтобы измерить именно накладные расходы прослойки.

Полезно различать два уровня интерфейса, которые предлагает эталонная библиотека. Высокоуровневый интерфейс оперирует путями к файлам: обработчику приходит готовая строка пути, и это проще в реализации, но заставляет на каждом обращении заново разбирать путь и искать по нему объект. Низкоуровневый интерфейс работает с числовыми идентификаторами объектов, инодами, и сам ведёт учёт ссылок на них. Он сложнее в написании, требует аккуратно считать обращения и освобождения, зато избавляет от повторного разбора путей и даёт заметно более высокую производительность на нагруженных системах. Зрелые проекты вроде распределённых файловых систем выбирают именно низкоуровневый путь ради скорости, мирясь с возросшей сложностью кода.

На каких задачах гибкость пользовательской файловой системы окупается сполна

Сила FUSE раскрывается там, где важна не сырая скорость, а возможность представить произвольный источник данных в виде привычного дерева файлов. Самый известный пример это удалённый доступ к серверу как к локальному каталогу: подключаешь удалённую машину, и её файлы видны так, словно лежат на своём диске, при этом клиент способен пережить разрывы связи и работать даже офлайн, если кеш на диске уже прогрет.

Облачные хранилища монтируются тем же способом. Корзина объектного хранилища, диск популярного облачного сервиса, удалённая папка по сетевому протоколу превращаются в обычный каталог, с которым работают любые программы без переделки. Архивы вроде упакованных коллекций файлов можно просматривать прямо как смонтированную файловую систему, не распаковывая, что особенно ценно для гигантских архивов с миллионами файлов. Поверх FUSE строят прозрачное шифрование, когда данные на диске зашифрованы, а приложениям видны расшифрованными. На лету можно сжимать, преобразовывать или подменять содержимое файлов, представлять аппаратные устройства иерархией файлов или собирать единое представление из разрозненных источников.

Отдельно стоит упомянуть, что FUSE давно вышел за пределы Linux и доступен на множестве систем, а эталонная библиотека активно развивается: её свежие версии выходят регулярно, последняя из крупных релизов вышла летом 2025 года, и развитие ядерной части тоже продолжается. Это не музейный экспонат, а живой и поддерживаемый инструмент.

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

Какие подводные камни всплывают при монтировании и эксплуатации

Удобство FUSE сопровождается рядом тонкостей, о которые спотыкаются новички. Первая касается безопасности монтирования. Раз файловую систему монтирует непривилегированный пользователь, ядро по умолчанию обкладывает её защитными ограничениями: запрещает исполнение файлов с битом повышения прав и доступ к специальным файлам устройств, чтобы через подставную файловую систему нельзя было пробить защиту системы. Доступ других пользователей к чужому FUSE-монтированию по умолчанию закрыт и включается особой опцией лишь осознанно.

Вторая тонкость это поведение при сбое демона. Поскольку файловая система это обычный процесс, его падение или зависание мгновенно сказывается на всех, кто работает с монтированием: обращения зависают или возвращают ошибки. Для контроля и аварийного обрыва зависших соединений в системе есть особый управляющий интерфейс, через который можно увидеть активные FUSE-соединения и при необходимости разорвать застрявшие. Это важный инструмент эксплуатации, без которого упавший демон способен намертво заблокировать обращающиеся к нему процессы.

Третья практическая забота это автоматическое монтирование при старте и после сетевых сбоев. Сетевые FUSE-системы зависят от доступности удалённой стороны, и их монтирование разумно описывать через менеджер служб с зависимостью от готовности сети, чтобы система не пыталась смонтировать удалённый ресурс раньше, чем поднимется сеть. Это превращает капризное ручное монтирование в надёжно управляемую службу.

Сведём картину воедино. FUSE отдаёт разработку файловых систем из узкого круга ядерных хакеров в руки любого программиста, позволяя за вечер собрать рабочий прототип на удобном языке без риска для ядра. За это платят накладными расходами на пересечение границы ядра и пространства пользователя, которые на большинстве реальных задач терпимы, а на горячих путях смягчаются кешированием и многопоточностью. Брать FUSE стоит там, где ценится гибкость представления произвольных данных деревом файлов: удалённый и облачный доступ, шифрование, архивы, мосты к нестандартным хранилищам. А помнить нужно про ограничения непривилегированного монтирования, про хрупкость связки с демоном и про аккуратную настройку автомонтирования. Тогда своя файловая система перестаёт быть подвигом и становится обычным инструментом в арсенале.