Как стать автором
Обновить

Комментарии 32

Если кому интересно, в блоге автора этой статьи есть ещё большая статья по инферновскому шеллу: debu.gs/entries/inferno-part-1-shell (я её переводить не планирую).
Простите, но ваша ссылка на FAQ ведет не на FAQ, а на каталог статей.
Разве ссылка на FAQ? По-моему ссылка на вопросе «Что такое Инферно». А каталог статей — это ответ. ;-)
Каталог статей — не ответ на этот вопрос.
Ну, какой есть. Другого ответа пока нет. Вот как напишет кто-нить внятный и короткий ответ в пару абзацев — буду ссылаться на него.
Если честно, то за вычетом функционала «скрытия» (для замены chroot), всё остальное как-то не особо водушевляет.

Особенно я не понял, как это так лихо разобрались с nfs.
В ядро инферно встроен сетевой протокол для доступа к файлам (тот самый 9P2000 a.k.a. Styx), это одна из ключевых составляющих инферно. Он используется для доступа и к локальным и к удалённым файлам. Соответственно, никаких дополнительных протоколов или утилит для расшаривания файлов по сети, вроде NFS, не требуется.
И он настолько хорош, что может заменить собой NFS? Не в теории «а мы тоже можем через сеть ходить за файлами», а в реальной боевой нагрузке? Как этот протокол себя ведёт при массовом конкурентном доступе от приложений в сетях 10G (и выше?) Как разруливаются файловые блокировки при перезагрузке сервера?

Если эта штука реально крута — рассказывайте, потому что NFS и CIFS всех утомили, но лучше пока файловых протоколов не известно.
Насколько мне известно, под высокими нагрузками 9P ведёт себя точно так же, как и под низкими.

Файловые блокировки не разруливаются никак по причине их отсутствия. Никакого flock(2) в инферно нет. При необходимости они легко реализуются множеством способов, и разруливание при перезагрузке будет зависеть от деталей реализации.

Что касается использования 9P в качестве замены NFS/CIFS для поднятия банальной файлопомойки, то здесь есть одна проблема. Основной (он же вроде бы единственный, если я ничего не путаю) недостаток 9P это высокая latency. Исправить сей недостаток достаточно проблематично, т.к. по хорошему это вовсе не недостаток, а особенность протокола.

Дело в том, что 9P всё-таки в первую очередь заточен для доступа к любым файлам, что в частности подразумевает файлы синтетические, файлы устройств в /dev, etc. Поэтому операция, к примеру, чтения файла выглядит так:
  1. клиент вызывает read(2) и блокируется в ожидании возврата из системного вызова
  2. ОС клиента отправляет пакет по протоколу 9P на сервер, откуда подмонтирован читаемый файл
  3. ОС сервера получает пакет 9P и передаёт его файл-серверу (это может быть и драйвер физической файловой системы и любое приложение файл-сервер)
  4. Файл-сервер анализирует полученный запрос на чтение файла и принимает решение — вернуть ошибку или данные
  5. ОС сервера отправляет пакет 9P с ответом
  6. ОС клиента получает пакет 9P с ответом
  7. клиент выходит из системного вызова read(2) получив данные либо ошибку переданные файл-сервером
Суть описанного процесса в том, что пока клиент не получит ответ на первую операцию read(2), он не может послать следующую. А чтобы получить ответ нужно как минимум потратить 2*RTT времени, не зависимо от того, считывается 1 байт или 1 мегабайт. И реализовать какое либо кеширование и опережающее чтение в этих условиях проблематично. Более того, с синтетическими файлами любое кеширование и опрежающее чтение может привести к совершенно непредсказуемым результатам.

Насколько я знаю, предпринималось как минимум две различные попытки решить эту проблему, но насколько они были удачны в плане сравнения производительности с CIFS я не помню.

Лично я не вижу никакой проблемы в том, чтобы продолжать использовать CIFS для файлопомоек, и использовать 9P2000 для всего остального, где нет необходимости в выжимании максимальной скорости при передаче гигабайт данных. К примеру, одна из очень приятных особенностей 9P2000 заключается в том, что сам факт завершения системного вызова write без ошибки гарантирует что файл-сервер получил отправленные данные (в отличие от традиционных ОС, где завершение write не говорит вообще ни о чём — данные могут быть в исходящем буфере ОС отправляющей стороны или во входящем ОС принимающей стороны, а приложение куда они отправлялись может их так и не увидеть).
НЛО прилетело и опубликовало эту надпись здесь
Если оно не умеет параллельного IO, то его можо уносить, NFS оно никаким образом не заменит.

Поясняю: мы открываем файл и запускаем 30 параллельных процессов, делающих IO с этим файлом. Если это не возможно, то практической пользы от протокола — не много больше, чем от sshfs — пользовательский уровень покрывает, системный — нет.
Хм. А с чего Вы решили, что это не будет работать в инферно? Все эти параллельные запросы придут на файл-сервер, во всех запросах по определению будет смещение в файле для текущей операции чтения/записи, и никаких проблем не возникнет.
То есть random io от многопоточного приложения будет обрабатываться нормально? Тогда я хочу увидеть это в жизни.

Просто для информации: сетевой оверхед от scst (iscsi target) неощутим до 20k IOPS, для NFS я ещё серьёзных тестов не делал, но там примерно такие же показатели.

Речь про IO внутри открытого файла, разумеется.
С другой стороны, поскольку пространство имён общее для всей системы, вам требуется быть root чтобы изменять его.
Мне хватит и pam_namespace. Ну и fuse для монтирования всего без рута.

9p2000 это, конечно, круто, но обычные файловые системы в *nix заметно быстрее для типичных задач.
Inferno и plan9 очень клевые ОС. Когда впервые узнал про plan9 был поражен его красотой и простотой. Был некий русскоязычный сайт с хорошей документацией, постараюсь найти ссылку. Там описывалось очень много всего интересного. Например (про план):
— отлаживать можно не просто на удаленной машине, а машине с другой архитектурой. Стандартными средствами. Просто импортировав к себе /proc.
— ps и top- просто скрипты, читающие /proc
— rio — оконная система в plan9 — требует для работы файлы устройств клавиатуры, мыши и экрана (и еще чего то, не помню). Своим клиентам (gui приложениям) она предоставляет их же. В результате можно запускать рекурсивно, и для этого ничего не требуется.
— tcp/ip — тоже фс, можно сделать какой нибудь cat сайта и разобрать полученное shell скриптом.

А еще идеи plan9 развили еще дальше — см. lsub.org
Там и элементы gui тоже фс. Или как вам включение света в комнате через. Echo on > /rooms/234/light/top?
Советую сходить посмотреть демки.
Буду не с мобилки — напишу еще.

P.s. жаль что обе ос не особо распространены. Думаю что inferno был бы отличной мобильной ос.
jfyi, в обычном линуксе ps тоже парсит только proc.
А 18 листов опций (в man'е) для ps обрабатываются 61 строкой? Или сравним таки c ps в busybox'е, которая широтой опций не отличается?
Да не вопрос: в ps busybox-а 799 строчек.

Что касается 18-ти листов опций, то это проблемы индейцев. Им ещё в 1983 пытались объяснить, что так делать не надо.
Я рад, что они не послушались. Потому что сейчас coreutils в линуксе позволяют решать довольно обширный класс задач быстрее, чем на любом языке программирования.
НЛО прилетело и опубликовало эту надпись здесь
Я посмотрел на эту 61 строчку — я не очень их «b» понимаю, но, кажется, эта штука не способна даже ps -faux нарисовать, не говоря уже про всё остальное.

А если мне процессы нужно вывести, то это можно и проще:

for a in /proc/[1-9]*;do echo `cat $a/cmdline`;done
Ну, давайте сравним:
$ ps faux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME 
    COMMAND
powerman 12472  0.0  0.0   7352  1100 ?        S    22:04   0:00 
    sshd: powerman@pts/5
powerman 12491  1.2  0.0   5500  2156 pts/5    Ss   22:04   0:00 
     \_ -bash
powerman 12546  0.0  0.0   4392  1044 pts/5    R+   22:04   0:00 
         \_ ps faux

$ emu-g
; ps
       1        1   powerman    0:00.0    release   143K Sh
      20        1   powerman    0:00.0       recv   147K Mntgen
      21        1   powerman    0:00.0        alt    13K Nametree
      22        1   powerman    0:00.0    release    77K Styx
      65       64   powerman    0:00.0        alt    34K Cs
      66        1   powerman    0:00.0      ready   142K Ps

  • USER — выводится
  • PID — выводится
  • %CPU, START, TIME — выводится только TIME, да и тот работает только в native инферно, а в hosted там всегда 0 если я не ошибаюсь. В любом случае, к функциональности самой команды ps это имеет слабое отношение.
  • VSZ, RSS — выводится, просто в инферно нет разделения на VSZ и RSS
  • %MEM — а оно нужно? учитывая, сколько килобайт памяти используют все инферновские приложения? мегабайтами память в инферно могут жрать только ваши собственные приложения, и это не сложно увидеть без всяких процентов
  • TTY — в инферно такого понятия нет
  • STAT — выводится
  • COMMAND — выводится; что до псевдографики, то вместо неё выводится ID группы процессов (вторая колонка), он же PID главного процесса в группе

Как по мне, функциональности инферновского ps более чем достаточно.
'f' рисует кто кого породил. Когда разбираешься в зоопарке сложной системы, очень помогает.

Вторая важная опция — T — показывает треды.
Ещё одно важное — это -s, позволяет разбираться кто там что где забыл на сервере запущенным.

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

«Свои» приложения часто бывают тоже в большом количестве и видеть быстро, что приложение съело не те ресурсы, что ему положено, весьма удобно.
Кто кого породил видно по ID группы. Если нужно нарисовать псевдографикой — ну значит либо сами напишете, либо Вам инферно не подходит по причине отсутствия псевдографики в выводе ps. :D

В инферно нет разделения на процессы и нити, так что то, что вы видите в выводе ps — это и есть нити.

-s — в моём Gentoo не работает. Это что вообще и для чего?

Аргументировать «нафига» это, конечно, не вариант. Но помимо «нафига», есть ещё такое понятие как «misuse». При разработке Инферно была решена сложнейшая задача: реализовать всю необходимую функциональность сохранив простоту — как архитектуры, так и реализации. Инферно даёт Вам всё необходимое для того, чтобы писать абсолютно полноценные и функциональные приложения очень просто. Безусловно, если проигнорировать эту возможность, и начать писать под инферно традиционный переусложнённый раздутый софт — через некоторое время Вам действительно понадобятся 18 листов опций для ps, чтобы хоть как-то управлять созданной Вами сложностью. Но вины инферно в этом не будет.
Не понимаю патетики высказывания. Примеры крупных product-исталляций есть?
Э… в чём Вы там патетику углядели?

Некоторые примеры использования инферно можно увидеть здесь: inferno.execbit.ru/wiki.wsgi/Реальное%20применение%20Inferno У нас в проекте инферно крутится на некотором кол-ве сервисов на 4-х серверах, под весьма высокими нагрузками. В maillist-е и на IRC народ упоминал ещё довольно много проектов на инферно, но продакшн это или просто эксперименты я не знаю.

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

Даже я и то почти пять лет внедрял её крайне осторожно и точечно в нашу систему, т.к. не был уверен не вылезут ли где-нить проблемы с производительностью или надёжностью, активно тестируя чуть ли не каждую фичу перед использованием. И только недавно принял решение, что все тесты пройдены успешно, работает она отлично, и можно приступать к массовой замене текущих Perl+libev сервисов на инферно.
Ну, я бы хотел посмотреть на неё в условиях боевой нагрузки (условно — больше гигабита входящего трафика).

Для этого, видимо, надо начать с поддержки приличного серверного оборудования. ixgb/ixgbe портирован? aacraid/mpt2sas?
Я не понимаю, для каких задач Вы хотите её использовать? Как замену линуховому файрволу/роутеру на шлюзе? Возможно native инферно и может что-то в этом духе, не знаю, я этот вопрос не изучал и с native инферно не работал, но я сомневаюсь, что это является подходящим use case для инферно.

Как я уже упоминал, я просто пишу под инферно софт, фактически использую инферно как альтернативу для Perl или Java. Подумайте, насколько осмысленно звучат Ваши вопросы в отношении, например, JavaVM… Написать приложение на Java или Inferno которое будет как-то осмысленно обрабатывать гигабит входящего трафика, возможно, и получится. Смотря как обрабатывать и на каком железе. Но при чём тут портирование ixgb/ixgbe/aacraid/mpt2sas?
Ну, например, в качестве головы для раздачи дисков виртуальных машин. Примерные ожидания — поддержка кластеризации, способность обработать ~100k прерываний в секунду от оборудования, раздать (file/block io) 1-3 Гбит/с.

Это даже не совсем highload, но не «рутер».

ЗЫ Может я неправильно понимаю, inferno — это ОС или нет? прерывания, кольца защиты, виртуальная память, переключение процессов, скедулинг, свопинг, стек блочных устройств, сетевой стек… Что там ещё от казуальной ОС ожидают?
Прерывания — точно не скажу. Наверное, на уровне native ОС они есть, иначе она бы не работала. Но в user-space никаких прерываний нет.

Колец защиты и виртуальной памяти нет. Вся память плоская и доступна всем процессам (защита памяти обеспечивается сильной типизацией, я об этом уже писал).

Переключение процессов есть. Скедулинг — это что? Планировщик процессов (scheduler)? Есть.

Свопа нет.

Стек блочных устройств — поскольку устройство это просто файл в /dev, то стекирование этих устройств реализуется обычными файл-серверами в user space. Есть ли готовый файл-сервер, например, для реализации software RAID — я не знаю, никогда не интересовался.

Сетевой стек есть, хотя используется он скорее всего только в native Inferno, а hosted использует стек основной OS.

В общем, да, Инферно это ОС. И нет, это не альтернатива линуху на сервере или винде на десктопе. Да, Инферно работает и на встроенных устройствах и на суперкомпах вроде Blue Gene. Вероятно это означает, что, да, её можно запустить и на обычном сервере. Только вот смысла в этом скорее всего нет, т.к. для решения задач стоящих перед обычными серверами гораздо лучше приспособлены традиционные ОС, и возможностей инферно не хватит для решения этих задач. На обычных серверах/десктопах инферно имеет смысл запускать в hosted режиме как обычную VM (вроде JavaVM, а не VMware VM :)) или сервис.
ок, оно ближе к понятию платформы, чем ОС, я понял. Только просьба тогда с юниксом не сравнивать, ибо классы решаемых задач разные.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории