Комментарии 15
К сожалению, у libfuse такой Development Status: "at present libfuse does not have any active, regular contributors". Сложно представить, что будет с технологиями, авторы и основные мейнтейнеры которых со временем уйдут в оффлайн.
У любой опенсорсной технологии есть такие риски: мейнтейнеры отойдут от дел, поддерживать станет некому. У libfuse в этом плане всё не так плохо: последний патч там был неделю назад; когда мне надо было получить поддержку, мне в имейл-листе быстро ответили.
libfuse - не очень сложная библиотека. Думаю, даже без постоянных мейнтейнеров с ней всё будет хорошо. Я бы больше беспокоился за FUSE модуль ядра и протокол взаимодействия kernelspace / userspace - с этим сильно сложнее разобраться и доку по протоколу я не нашёл, когда искал :(
В целом отличная имплементация и опыт. Но мне кажется было проще разработать Kernel level FS, fuse все равно требуется установки с правами root и это очередная point of failure.
Автор написал, что разрабатывать и отлаживать в пространстве пользователя сильно проще.
У нас несколько причин было делать в юзерспейсе:
In-kernel разработка требует специфичной экспертизы. С нуля пришлось бы неприлично долго с этим разбираться. Я отлаживал несколько багов вида "ядро нарушает FUSE протокол, не присылает запрос, хотя должно" - это в жуткую боль всегда выливалось, очень сложно ядро дебажить.
Разработка в юзерспейсе позволила взять много готовых модулей, прежде всего, структур данных, библиотек для сетевого взаимодействия, отладочных инструментов. В ядре бы тоже замучились с этим.
Мы на уровне ФС планируем реализовать части бизнес-логики, в юзерспейсе можно быстрее вносить изменения.
Ну и через ИБ свой модуль ядра было бы сложно протащить, у нас таких прецедентов не было пока :)
При этом мы наверняка пожертвовали производительностью, но в пока что нас устраивает такой трейд-оф - платить перфом за скорость и стоимость разработки.
Отличная и очень интересная статья! Ранее не сталкивался с FUSE, поэтому это было очень познавательно. Но зачем и как может пригодиться такая файловая система на практике? Какие проблемы она решила для вас и почему их нельзя было решить другими готовыми решениями?
Ещё можно, например, сделать fuse-файловую систему, чтобы через неё своим приложением управлять. По такому же принципу, как линуксовое ядро управляется через /sys.
Нам надо было очереди почтового сервера в отказоустойчивый сторадж складывать. Свою ФС написали, чтобы:
Обеспечить совместимость с почтовым сервером. Например, одно письмо - 2 файла (тело и заголовки), в сторадже они одной сущностью "письмо" должны быть объединены.
Работать с проприетарным стораджем, это наша in-house технология. В итоге, система должна обеспечивать бесперебойную работу Почты при отказе одного центра обработки данных.
Подробнее о том, зачем и почему сделали так, и как устроена наша реализация - расскажу в докладе на SaintHighload++, в этот вторник :)
Отличная и очень интересная статья! Ранее не сталкивался с FUSE, поэтому это было очень познавательно. Но зачем и как может пригодиться такая файловая система на практике? Какие проблемы она решила для вас и почему их нельзя было решить другими готовыми решениями?
By Sumit Singh 13 October 2014 Develop your own filesystem with FUSE
https://developer.ibm.com/articles/l-fuse/?cb=4
Перевод:
Разработка собственной файловой системы с помощью FUSE
https://www.interface.ru/home.asp?artId=3620
Спасибо за дополнение! Видел эту статью, когда делал литобзор - хороший пример использования high-level API, если хочется работать сразу с путями, без разделения dentry / inode. К слову, та же модель многопоточности и особенности эксплуатации, о которых я писал, будут применимы и к high-level API тоже :)
Как сопоставить экземпляр ФС и ID FUSE-соединения в FUSE control filesystem?
stat -c %d /path/to/mount-point тоже должен работать.
Спасибо за дополнение! Я про stat в этом контексте где-то уже читал. По идее, должно работать, да. Не помню точно, почему я остановился в итоге на своём однострочнике. Как будто бы stat давал неправильный выхлоп в кейсе MAJOR > 0, а греп по mountinfo явно выдаёт результат в MAJOR:MINOR формате и можно байтами в ручном режиме поиграть.
Возможно оффтоп, но может кому-то пригодится, по теме FUSE. В нашей компании мы реализовали зеркало репозиториев для обновления серверов в дата-центрах в виде веб-сервера. Так как основной сервер занимает около 10Тб, то для экономии места на других площадках надо было применять продукты типа Sonatype Nexus, а это может быть дорого, ресурсоемко и не импорто-замещенно. Поискав решения кеширующих ФC я нашел для FUSE реализацию чего-то похожего по смыслу только на Python, но это не наш путь. Поэтому воспользовавшись примерами за пару выходных в свободное от работы время реализовал это на Си. https://github.com/KuzinAndrey/kavcachefs
В компании это пока не внедрили :) Но хотелось бы найти применение, получить какой-то фидбек от нуждающихся, потому что тема действительно интересная.
FUSE: как написать свою файловую систему