Спасибо за дополнение! Я про stat в этом контексте где-то уже читал. По идее, должно работать, да. Не помню точно, почему я остановился в итоге на своём однострочнике. Как будто бы stat давал неправильный выхлоп в кейсе MAJOR > 0, а греп по mountinfo явно выдаёт результат в MAJOR:MINOR формате и можно байтами в ручном режиме поиграть.
Спасибо за дополнение! Видел эту статью, когда делал литобзор - хороший пример использования high-level API, если хочется работать сразу с путями, без разделения dentry / inode. К слову, та же модель многопоточности и особенности эксплуатации, о которых я писал, будут применимы и к high-level API тоже :)
Нам надо было очереди почтового сервера в отказоустойчивый сторадж складывать. Свою ФС написали, чтобы:
Обеспечить совместимость с почтовым сервером. Например, одно письмо - 2 файла (тело и заголовки), в сторадже они одной сущностью "письмо" должны быть объединены.
Работать с проприетарным стораджем, это наша in-house технология. В итоге, система должна обеспечивать бесперебойную работу Почты при отказе одного центра обработки данных.
Подробнее о том, зачем и почему сделали так, и как устроена наша реализация - расскажу в докладе на SaintHighload++, в этот вторник :)
In-kernel разработка требует специфичной экспертизы. С нуля пришлось бы неприлично долго с этим разбираться. Я отлаживал несколько багов вида "ядро нарушает FUSE протокол, не присылает запрос, хотя должно" - это в жуткую боль всегда выливалось, очень сложно ядро дебажить.
Разработка в юзерспейсе позволила взять много готовых модулей, прежде всего, структур данных, библиотек для сетевого взаимодействия, отладочных инструментов. В ядре бы тоже замучились с этим.
Мы на уровне ФС планируем реализовать части бизнес-логики, в юзерспейсе можно быстрее вносить изменения.
Ну и через ИБ свой модуль ядра было бы сложно протащить, у нас таких прецедентов не было пока :)
При этом мы наверняка пожертвовали производительностью, но в пока что нас устраивает такой трейд-оф - платить перфом за скорость и стоимость разработки.
У любой опенсорсной технологии есть такие риски: мейнтейнеры отойдут от дел, поддерживать станет некому. У libfuse в этом плане всё не так плохо: последний патч там был неделю назад; когда мне надо было получить поддержку, мне в имейл-листе быстро ответили.
libfuse - не очень сложная библиотека. Думаю, даже без постоянных мейнтейнеров с ней всё будет хорошо. Я бы больше беспокоился за FUSE модуль ядра и протокол взаимодействия kernelspace / userspace - с этим сильно сложнее разобраться и доку по протоколу я не нашёл, когда искал :(
Спасибо за статью! Я периодически пишу на Go, но чаще всё-таки на C. Была как-то идея гошный код в .so собрать и к сишке подключить, но побоялся, не хотелось гошную асинхронщину с сишной смешивать. Был ли у кого-то опыт CGO "в обратную сторону", можете поделиться?)
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Спасибо за дополнение! Я про stat в этом контексте где-то уже читал. По идее, должно работать, да. Не помню точно, почему я остановился в итоге на своём однострочнике. Как будто бы stat давал неправильный выхлоп в кейсе MAJOR > 0, а греп по mountinfo явно выдаёт результат в MAJOR:MINOR формате и можно байтами в ручном режиме поиграть.
Спасибо за дополнение! Видел эту статью, когда делал литобзор - хороший пример использования high-level API, если хочется работать сразу с путями, без разделения dentry / inode. К слову, та же модель многопоточности и особенности эксплуатации, о которых я писал, будут применимы и к high-level API тоже :)
Нам надо было очереди почтового сервера в отказоустойчивый сторадж складывать. Свою ФС написали, чтобы:
Обеспечить совместимость с почтовым сервером. Например, одно письмо - 2 файла (тело и заголовки), в сторадже они одной сущностью "письмо" должны быть объединены.
Работать с проприетарным стораджем, это наша in-house технология. В итоге, система должна обеспечивать бесперебойную работу Почты при отказе одного центра обработки данных.
Подробнее о том, зачем и почему сделали так, и как устроена наша реализация - расскажу в докладе на SaintHighload++, в этот вторник :)
У нас несколько причин было делать в юзерспейсе:
In-kernel разработка требует специфичной экспертизы. С нуля пришлось бы неприлично долго с этим разбираться. Я отлаживал несколько багов вида "ядро нарушает FUSE протокол, не присылает запрос, хотя должно" - это в жуткую боль всегда выливалось, очень сложно ядро дебажить.
Разработка в юзерспейсе позволила взять много готовых модулей, прежде всего, структур данных, библиотек для сетевого взаимодействия, отладочных инструментов. В ядре бы тоже замучились с этим.
Мы на уровне ФС планируем реализовать части бизнес-логики, в юзерспейсе можно быстрее вносить изменения.
Ну и через ИБ свой модуль ядра было бы сложно протащить, у нас таких прецедентов не было пока :)
При этом мы наверняка пожертвовали производительностью, но в пока что нас устраивает такой трейд-оф - платить перфом за скорость и стоимость разработки.
У любой опенсорсной технологии есть такие риски: мейнтейнеры отойдут от дел, поддерживать станет некому. У libfuse в этом плане всё не так плохо: последний патч там был неделю назад; когда мне надо было получить поддержку, мне в имейл-листе быстро ответили.
libfuse - не очень сложная библиотека. Думаю, даже без постоянных мейнтейнеров с ней всё будет хорошо. Я бы больше беспокоился за FUSE модуль ядра и протокол взаимодействия kernelspace / userspace - с этим сильно сложнее разобраться и доку по протоколу я не нашёл, когда искал :(
Спасибо за статью! Я периодически пишу на Go, но чаще всё-таки на C. Была как-то идея гошный код в .so собрать и к сишке подключить, но побоялся, не хотелось гошную асинхронщину с сишной смешивать. Был ли у кого-то опыт CGO "в обратную сторону", можете поделиться?)