Линус - Userspace filesystem ?

Говнофс лучше в юзерспейсе держать — всё правильно сделали.

Да и всякие образы дисков монтировать можно было бы и без прав рута. Нелогично если ты не рут, прочитать сам образ можешь, а файлы с него — нет

Он наверно про ФС для постоянного использования, то есть основную на компьютере. Тут действительно всё - говно говном. А флешки и т.п. - пофиг.

Был о Линусе лучшего мнения. Порость такую чушь. Он там что, белены объелся.

Хотя, скорее всего он описал состояние дел в линукс ядре :)

Чем лучше ? Идеологически ? :-) Практически только производительность падает, о чем линус и пишет

Torvalds additionally added, «fuse works fine if the thing being exported is some random low-use interface to a fundamentally slow device. But for something like your root filesystem? Nope. Not going to happen. So Andrew, I think that arguing that something _can_ be done with fuse, and thus _should_ be done with fuse is just ridiculous. That's like saying you should do a microkernel - it may sound nice on paper, but it's a damn stupid idea for people who care more about some idea than they care about reality.»

But for something like your root filesystem? Nope. Not going to happen.

Линус хороший, годный Капитан. Я в него всегда верил :)

> Был о Линусе лучшего мнения. Порость такую чушь. Он там что, белены объелся.

Ну смари.

Грузим ядро и инитрд. Из инитрд запускаем демон файловой системы, монтируем корень.
Отмонтировываем инитрд, за ненадобностью.
Работаем, открываем тучу файлов.
Тут демон наш х-як — сегфолтится к черту.
И нет у нас больше корневой системы. И демона переподнять обратно неоткуда, потому как initrd отмонтирован.
Чем это лучше ядреного VFS?

«While it turns out that most people are idiots, the corollary to that is sadly that you are one too [...] we should also admit that we're not the sharpest knife around»

linux/Documentation/ManagementStyle

> Тут демон наш х-як — сегфолтится к черту.

А мы его х*як - перезапускаем.

Ну смари.

Грузим ядро и инитрд. Из инитрд грузим модуль файловой системы, монтируем корень.
Отмонтировываем инитрд, за ненадобностью.
Работаем, открываем тучу файлов.
Тут ядро наше oops — вешается к черту.
И нет у нас больше корневой системы. И модуль перезагрузить обратно неоткуда, потому как всё ядро в панике.
Чем это лучше FS в юзерспейсе?

Сам все и рассказал.
Случай с vfs - одна возможность оказаться с нерабочей ФС.
Случай с userspace - две возможности оказатьсяс нерабочей ФС.

Следовательно, надежнее(и быстрее) первая реализация.

> одна возможность

две возможности

Не одна, а четыре. Не две, а три.

В данном случае «ядро» и «ядро и демон».
Разумеется у тебя могут случиться разные вещи, вроде отключения электроэнергии и внезапного некроза пениса. Но их тут незачем рассматривать.

> Случай с vfs - одна возможность оказаться с нерабочей ФС.

Случай с userspace - две возможности оказатьсяс нерабочей ФС.

Не совсем верно.

Следовательно, надежнее(и быстрее) первая реализация.

Совсем неверно.

Разумеется не совсем верно.
Но если есть система из 4-х шестеренок и из 2-х, то в общем случае система из двух шестеренок более надежна. В общем-то именно это я и хотел сказать.

> Но если есть система из 4-х шестеренок и из 2-х,

Механические аналогии не действуют в случае софта.

то в общем случае система из двух шестеренок более надежна

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

Что надежнее дубина, или надежная дубина под управлением надежного линукса ? :-)

> Что надежнее дубина, или надежная дубина под управлением надежного линукса ? :-)

Зависит. Кроме того, вы оба то ли недопонимаете, то ли мошенничаете - число компонентов и в случае внутриядерной ФС, и в случае userspace-ФС одно и то же.

Предполагается, что вероятность отказа одинакова.
Хвост кстати неотъемлимая часть ящерицы.

Надежность дубины зависит от надежности линукса ? Гм, вообще то вовсе напротив :-))

Я попытался не совсем корректно обрисовать принцип «чем больше компонентов, тем выше шанс отказа», не более того.

> Хвост кстати неотъемлимая часть ящерицы.

Вполне отъемлимая %)

Рука у тебя тоже отъелимая. Но ты потеряешь часть функций, которые она выполняет.
У ящерицы кстати та же самая история, они вполне могут потерять возможность размножения, хорошую ориентацию в пространстве и способность плавать.

>Рука у тебя тоже отъелимая.

не настолько же: http://www.zoopicture.ru/pochemu-yashherica-otbrasyvaet-xvost/

не настолько

> Рука у тебя тоже отъелимая.

У ящерицы кстати та же самая история,

Рука у меня не отрастет, в отличие от хвоста у ящерицы; и травматической ампутации руки я, скорее всего, просто не переживу (опять же в отличие от).

А если возвращаться к ФС, то демон можно очень быстро перезапустить в случае краха, и можно даже сделать так, что клиенты не заметят перезапуска.

P.S. Ты живая иллюстрация тезиса о том, почему вредны аналогии %)

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

Если инитрд отмонтирован, а демон корневой ФС сегфолтнулся, то тебе его взять неоткуда, чтобы перезапустить. Нужны костыли. А еще демон тормозной будет, из-за перебросок данных между контекстами. То есть никакого профита, кроме идеологии (демона можно мутить проприетарного), мы не получаем. Возросшую сложность зато получаем вполне себе.

> Если инитрд отмонтирован, а демон корневой ФС сегфолтнулся, то тебе его взять неоткуда, чтобы перезапустить.

mlockall

А еще демон тормозной будет, из-за перебросок данных между контекстами.

А вот это уже другой вопрос.

То есть никакого профита, кроме идеологии

Живучесть.

Живучесть не в том, что переподнимается, а в том, что не падает. Допустим, его сегфолтит какое-то свойство дескриптора файла. Демон падает. Его подымают и подсовывают горсть дескрипторов. Он опять видит проблемный дескриптор и падает. Его опять поднимают и так далее. юзерспейсу лучше не станет.

> Живучесть не в том, что переподнимается, а в том, что не падает.

Бугага.

«Живучесть технических систем

способность технических систем и их компонентов сохранять или оперативно восстановить возможность выполнения заданных функций после повреждений в штатных и нештатных ситуациях, выходящих за пределы, установленные нормами и правилами».

Короче, повышай квалификацию - это сделает тебя более годным троллем.

>Отмонтировываем инитрд

Вот вам и ошибочка. Зачем ? Для чего ? Чем оно мешает ?

Предвидя ответы, подскажу per-process namespace. В линуксе реализован (спёрт из Plan 9) хрен знает когда.

Что мешает перезапускать демона файловой системы ?

Не пойму описанную ситуацию. А в случае нахождения кода в ядре, падать будет ядро ?

> Вот вам и ошибочка. Зачем ? Для чего ? Чем оно мешает ?

А зачем оно нужно? Так, чисто на всякий случай, авось система наколебнется?
Слишком как-то мудрено оно получается. Создание сложностей на ровном месте.

Что мешает перезапускать демона файловой системы ?

Тем, что это не устранит причину, по которой он собсна упал.

Можете мне объяснить зачем это нужно? Какие преимущества по сравнению с тем что уже есть это даст? Пока назвали только недостатки.

фига у вас в линуксе всё запущено. как минимум в драгонфлае есть sysctl переменная, позволяющая монтировать обычному юзеру

Мы все умрём. И что из этого ??? :)

Ваши рассуждения топчатся вокруг одного аргумента, который относится не к работе а к проектированию. Могу Вас уверить, что криво спроектированный драйвер ФС в ядре, сможет уложить его (ядро) на лопатки. Причину придётся устранять в ДНК.

А запуск серверов файловых систем в user space позволит, к примеру, создать драйвер закрытой файловой системы не нарушая лицензию ядра системы в целом. Но ведь, сегодня в Линуксе это просто не возможно :) всё равно все вызова идут в архаичный VFS Layer, а уж оттуда ...

Оттого FUSE это костыль (вернее попытка решить проблему косметикой).

> архаичный VFS Layer

И в чем его архаичность?

В том что вы общаетесь с посредником.

Конечно, положит. И демон положит в описанной ситуации.

Только профиту никакого, кроме возросшей нагрузки на IPC и, следовательно, тормозов. Плюс костыли типа невозможности вытеснить этот демон в условиях нехватки ОЗУ.

А какая-то идеология мне, как и Линусу, побоку. Пусть Таненбаум эту свою идеологию идеального микроядра кушает с кашей.

> В том что вы общаетесь с посредником.

Ух ты, а я-то думал, что интерфейсы-реализации и полиморфизм — это хорошо. Пойду посыплю голову пеплом (на всякий не буду уточнять — чью).

архаичный VFS Layer

И в чем его архаичность?

В том что вы общаетесь с посредником.

*shrug* Ну, а в Plan9 приходится реализовывать VFS в каждом сервер. И где профит? Нет профита.

>Ну, а в Plan9 приходится реализовывать VFS в каждом сервер.

А мужики то не знают. :) Может всё таки документацию почитать ??? Сервер поддерживает 9P (который кстати есть и в Linux kernel, для чего изобретали FUSE не совсем ясно) и соответственно отрабатывает запросы приходящие к нему.

> Может всё таки документацию почитать ???

Ссылку?

Сервер поддерживает 9P

Спасибо, кэп. Для поддержки 9P ему нужна поддержка кучи служебных операций, которые в беспонтовых ОС реализованы в VFS.

>Для поддержки 9P ему нужна поддержка кучи служебных операций,

13... это так много ??? Речь, то в общем не об 9P :) а о user-space servers в Linux.

P.S.: Реализаций 9P2K уже столько, и всё они 100% меньше куска VFS в Linux ядре :)