The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Линус Торвальдс не видит для ФС пространства пользователя се..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "Линус Торвальдс не видит для ФС пространства пользователя се..." –2 +/
Сообщение от fr0ster (ok), 01-Июл-11, 17:16 
>> В ядре? Вы забываете о чем шла речь в дискуссии, в которой
>> были сказаны слова Торвальдса.
> В каком ядре? Речь шла о FUSE в том числе, и по
> единственному критерию скорости Торвальдс назвал его игрушкой.

Ага, "сообщение Эндрю Мортона о том, что проблемы производительности файловых систем, основанных на FUSE, нельзя решить только за счет перемещения их кода в ядро".
Стало быть критерии оценки ФУЗЕ должны быть те же, что и к ядерным ФС. А по ним они сливают.

>> Ага, упустить или скрыть контекст дискуссии из которого взята фраза Торвальдса. Не
>> знает или намеренно вводит в заблуждение.
> И каков же контекст, просветите?

См. выше.

>> Есть такие критерии, вот только из ваших критериев к ядру относятся лишь
>> первые два кроме скорости работы - "стабильность, безопасность". А по ним
>> ФУЗЕ не блещет в сравнении с ядерными ФС.
> Все эти критерии "к ядру относятся". Есть два варианта: ядерный драйвер или
> FUSE-драйвер. Оцениваем...
> 1. Надёжность
> Ошибки в ядерном драйвере потенциально ведут к краху системы или отказу подсистемы.
> Ошибка в FUSE-драйвере - к краху только драйвера, с возможностью последующего
> перезапуска.

Повторение мантры не доказательство. Тем более устойчивость к последствиям краха не единственный пункт в понятии "надежность". Да и банально ядерная ФС часто не заметит тех проблем, что приведут к краху ФУЗЕ, банально проца не хватило и упс.

> 2. Безопасность
> Уязвимости в ядерном драйвере (включая логические, как в ReiserFS) потенциально ведут к
> компрометации всей системы; в FUSE-драйвере - к компрометации процесса драйвера, привилегий
> отдельного пользователя (с которыми работает процесс) и хранимых данных. При этом

Вопервых смотря какого пользователя. Вовторых вероятность существования неизвестной уязвимости в ядерном драйвере меньше, нежели в случае ФУЗЕ.

> FUSE-драйвер можно писать на типобезопасных, верифицируемых языках вроде Ada/SPARK.

Втретьих Ада для писания ФУЗЕ можно, но смысла немного. Да и чаще всего ФУЗЕ используют для наиболее простого решения задачи, забывая, что нередко простота хуже воровства.

> 3. Скорость разработки и свобода выбора инструментария
> Драйвер ядра придётся писать на Си для пространства ядра - медленно, дорого,
> неудобно тестировать. FUSE-драйвер можно писать на более удобных языках, с более
> развитыми средствами профилирования, тестирования и отладки.

А это специфика ядра. Хочешь надежно - не жлобись на время, знания и деньги.

> 4. Адаптация удобных традиционных абстракций
> Вещи, вроде s3fs, sshfs, copyfs - надёжнее, безопаснее и быстрее пишутся под
> FUSE.

Надежнее и безопаснее пишутся? Это что то новое. Пишуться то они пишуться, но быстро, надежно и безопасно работать таки не работают.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Линус Торвальдс не видит для ФС пространства пользователя се..., opennews, 01-Июл-11, 09:05  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру