Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Если кому интересно, в блоге автора этой статьи есть ещё большая статья по инферновскому шеллу: debu.gs/entries/inferno-part-1-shell (я её переводить не планирую).
Простите, но ваша ссылка на FAQ ведет не на FAQ, а на каталог статей.
Если честно, то за вычетом функционала «скрытия» (для замены chroot), всё остальное как-то не особо водушевляет.
Особенно я не понял, как это так лихо разобрались с nfs.
Особенно я не понял, как это так лихо разобрались с nfs.
В ядро инферно встроен сетевой протокол для доступа к файлам (тот самый 9P2000 a.k.a. Styx), это одна из ключевых составляющих инферно. Он используется для доступа и к локальным и к удалённым файлам. Соответственно, никаких дополнительных протоколов или утилит для расшаривания файлов по сети, вроде NFS, не требуется.
И он настолько хорош, что может заменить собой NFS? Не в теории «а мы тоже можем через сеть ходить за файлами», а в реальной боевой нагрузке? Как этот протокол себя ведёт при массовом конкурентном доступе от приложений в сетях 10G (и выше?) Как разруливаются файловые блокировки при перезагрузке сервера?
Если эта штука реально крута — рассказывайте, потому что NFS и CIFS всех утомили, но лучше пока файловых протоколов не известно.
Если эта штука реально крута — рассказывайте, потому что NFS и CIFS всех утомили, но лучше пока файловых протоколов не известно.
Насколько мне известно, под высокими нагрузками 9P ведёт себя точно так же, как и под низкими.
Файловые блокировки не разруливаются никак по причине их отсутствия. Никакого flock(2) в инферно нет. При необходимости они легко реализуются множеством способов, и разруливание при перезагрузке будет зависеть от деталей реализации.
Что касается использования 9P в качестве замены NFS/CIFS для поднятия банальной файлопомойки, то здесь есть одна проблема. Основной (он же вроде бы единственный, если я ничего не путаю) недостаток 9P это высокая latency. Исправить сей недостаток достаточно проблематично, т.к. по хорошему это вовсе не недостаток, а особенность протокола.
Дело в том, что 9P всё-таки в первую очередь заточен для доступа к любым файлам, что в частности подразумевает файлы синтетические, файлы устройств в /dev, etc. Поэтому операция, к примеру, чтения файла выглядит так:
Насколько я знаю, предпринималось как минимум две различные попытки решить эту проблему, но насколько они были удачны в плане сравнения производительности с CIFS я не помню.
Лично я не вижу никакой проблемы в том, чтобы продолжать использовать CIFS для файлопомоек, и использовать 9P2000 для всего остального, где нет необходимости в выжимании максимальной скорости при передаче гигабайт данных. К примеру, одна из очень приятных особенностей 9P2000 заключается в том, что сам факт завершения системного вызова write без ошибки гарантирует что файл-сервер получил отправленные данные (в отличие от традиционных ОС, где завершение write не говорит вообще ни о чём — данные могут быть в исходящем буфере ОС отправляющей стороны или во входящем ОС принимающей стороны, а приложение куда они отправлялись может их так и не увидеть).
Файловые блокировки не разруливаются никак по причине их отсутствия. Никакого flock(2) в инферно нет. При необходимости они легко реализуются множеством способов, и разруливание при перезагрузке будет зависеть от деталей реализации.
Что касается использования 9P в качестве замены NFS/CIFS для поднятия банальной файлопомойки, то здесь есть одна проблема. Основной (он же вроде бы единственный, если я ничего не путаю) недостаток 9P это высокая latency. Исправить сей недостаток достаточно проблематично, т.к. по хорошему это вовсе не недостаток, а особенность протокола.
Дело в том, что 9P всё-таки в первую очередь заточен для доступа к любым файлам, что в частности подразумевает файлы синтетические, файлы устройств в /dev, etc. Поэтому операция, к примеру, чтения файла выглядит так:
- клиент вызывает read(2) и блокируется в ожидании возврата из системного вызова
- ОС клиента отправляет пакет по протоколу 9P на сервер, откуда подмонтирован читаемый файл
- ОС сервера получает пакет 9P и передаёт его файл-серверу (это может быть и драйвер физической файловой системы и любое приложение файл-сервер)
- Файл-сервер анализирует полученный запрос на чтение файла и принимает решение — вернуть ошибку или данные
- ОС сервера отправляет пакет 9P с ответом
- ОС клиента получает пакет 9P с ответом
- клиент выходит из системного вызова read(2) получив данные либо ошибку переданные файл-сервером
Насколько я знаю, предпринималось как минимум две различные попытки решить эту проблему, но насколько они были удачны в плане сравнения производительности с CIFS я не помню.
Лично я не вижу никакой проблемы в том, чтобы продолжать использовать CIFS для файлопомоек, и использовать 9P2000 для всего остального, где нет необходимости в выжимании максимальной скорости при передаче гигабайт данных. К примеру, одна из очень приятных особенностей 9P2000 заключается в том, что сам факт завершения системного вызова write без ошибки гарантирует что файл-сервер получил отправленные данные (в отличие от традиционных ОС, где завершение write не говорит вообще ни о чём — данные могут быть в исходящем буфере ОС отправляющей стороны или во входящем ОС принимающей стороны, а приложение куда они отправлялись может их так и не увидеть).
Если оно не умеет параллельного IO, то его можо уносить, NFS оно никаким образом не заменит.
Поясняю: мы открываем файл и запускаем 30 параллельных процессов, делающих IO с этим файлом. Если это не возможно, то практической пользы от протокола — не много больше, чем от sshfs — пользовательский уровень покрывает, системный — нет.
Поясняю: мы открываем файл и запускаем 30 параллельных процессов, делающих IO с этим файлом. Если это не возможно, то практической пользы от протокола — не много больше, чем от sshfs — пользовательский уровень покрывает, системный — нет.
Хм. А с чего Вы решили, что это не будет работать в инферно? Все эти параллельные запросы придут на файл-сервер, во всех запросах по определению будет смещение в файле для текущей операции чтения/записи, и никаких проблем не возникнет.
То есть random io от многопоточного приложения будет обрабатываться нормально? Тогда я хочу увидеть это в жизни.
Просто для информации: сетевой оверхед от scst (iscsi target) неощутим до 20k IOPS, для NFS я ещё серьёзных тестов не делал, но там примерно такие же показатели.
Речь про 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 был бы отличной мобильной ос.
— отлаживать можно не просто на удаленной машине, а машине с другой архитектурой. Стандартными средствами. Просто импортировав к себе /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.
Ну да, разницы почти никакой. Разве что… реализация инферновского ps содержит 61 строчку в одном файле, а линухового 5793 строк в 8-ми файлах.
А 18 листов опций (в man'е) для ps обрабатываются 61 строкой? Или сравним таки c ps в busybox'е, которая широтой опций не отличается?
Да не вопрос: в ps busybox-а 799 строчек.
Что касается 18-ти листов опций, то это проблемы индейцев. Им ещё в 1983 пытались объяснить, что так делать не надо.
Что касается 18-ти листов опций, то это проблемы индейцев. Им ещё в 1983 пытались объяснить, что так делать не надо.
Я посмотрел на эту 61 строчку — я не очень их «b» понимаю, но, кажется, эта штука не способна даже ps -faux нарисовать, не говоря уже про всё остальное.
А если мне процессы нужно вывести, то это можно и проще:
for a in /proc/[1-9]*;do echo `cat $a/cmdline`;done
А если мне процессы нужно вывести, то это можно и проще:
for a in /proc/[1-9]*;do echo `cat $a/cmdline`;done
Ну, давайте сравним:
Как по мне, функциональности инферновского ps более чем достаточно.
$ 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, позволяет разбираться кто там что где забыл на сервере запущенным.
То есть аргументировать «да нафига все эти опции сдались», можно, но это будет в категории «мне хватает для игрушек, а что вы там для работы юзаете, меня это не касается».
«Свои» приложения часто бывают тоже в большом количестве и видеть быстро, что приложение съело не те ресурсы, что ему положено, весьма удобно.
Вторая важная опция — T — показывает треды.
Ещё одно важное — это -s, позволяет разбираться кто там что где забыл на сервере запущенным.
То есть аргументировать «да нафига все эти опции сдались», можно, но это будет в категории «мне хватает для игрушек, а что вы там для работы юзаете, меня это не касается».
«Свои» приложения часто бывают тоже в большом количестве и видеть быстро, что приложение съело не те ресурсы, что ему положено, весьма удобно.
Кто кого породил видно по ID группы. Если нужно нарисовать псевдографикой — ну значит либо сами напишете, либо Вам инферно не подходит по причине отсутствия псевдографики в выводе ps. :D
В инферно нет разделения на процессы и нити, так что то, что вы видите в выводе ps — это и есть нити.
-s — в моём Gentoo не работает. Это что вообще и для чего?
Аргументировать «нафига» это, конечно, не вариант. Но помимо «нафига», есть ещё такое понятие как «misuse». При разработке Инферно была решена сложнейшая задача: реализовать всю необходимую функциональность сохранив простоту — как архитектуры, так и реализации. Инферно даёт Вам всё необходимое для того, чтобы писать абсолютно полноценные и функциональные приложения очень просто. Безусловно, если проигнорировать эту возможность, и начать писать под инферно традиционный переусложнённый раздутый софт — через некоторое время Вам действительно понадобятся 18 листов опций для ps, чтобы хоть как-то управлять созданной Вами сложностью. Но вины инферно в этом не будет.
В инферно нет разделения на процессы и нити, так что то, что вы видите в выводе ps — это и есть нити.
-s — в моём Gentoo не работает. Это что вообще и для чего?
Аргументировать «нафига» это, конечно, не вариант. Но помимо «нафига», есть ещё такое понятие как «misuse». При разработке Инферно была решена сложнейшая задача: реализовать всю необходимую функциональность сохранив простоту — как архитектуры, так и реализации. Инферно даёт Вам всё необходимое для того, чтобы писать абсолютно полноценные и функциональные приложения очень просто. Безусловно, если проигнорировать эту возможность, и начать писать под инферно традиционный переусложнённый раздутый софт — через некоторое время Вам действительно понадобятся 18 листов опций для ps, чтобы хоть как-то управлять созданной Вами сложностью. Но вины инферно в этом не будет.
Не понимаю патетики высказывания. Примеры крупных product-исталляций есть?
Э… в чём Вы там патетику углядели?
Некоторые примеры использования инферно можно увидеть здесь: inferno.execbit.ru/wiki.wsgi/Реальное%20применение%20Inferno У нас в проекте инферно крутится на некотором кол-ве сервисов на 4-х серверах, под весьма высокими нагрузками. В maillist-е и на IRC народ упоминал ещё довольно много проектов на инферно, но продакшн это или просто эксперименты я не знаю.
Безусловно, это мизер. Пока про инферно мало кто знает — никто не рискнёт внедрять её в продакшн. А пока её не внедрят в продакшн в значительном кол-ве мест — про неё никто не узнает. Проблема курицы и яйца. Обычно решается поднятием маркетингового хайпа вокруг системы, но в случае инферно её разработчики предпочитают тихо сидеть и работать с системой, а не заниматься её раскруткой.
Даже я и то почти пять лет внедрял её крайне осторожно и точечно в нашу систему, т.к. не был уверен не вылезут ли где-нить проблемы с производительностью или надёжностью, активно тестируя чуть ли не каждую фичу перед использованием. И только недавно принял решение, что все тесты пройдены успешно, работает она отлично, и можно приступать к массовой замене текущих Perl+libev сервисов на инферно.
Некоторые примеры использования инферно можно увидеть здесь: inferno.execbit.ru/wiki.wsgi/Реальное%20применение%20Inferno У нас в проекте инферно крутится на некотором кол-ве сервисов на 4-х серверах, под весьма высокими нагрузками. В maillist-е и на IRC народ упоминал ещё довольно много проектов на инферно, но продакшн это или просто эксперименты я не знаю.
Безусловно, это мизер. Пока про инферно мало кто знает — никто не рискнёт внедрять её в продакшн. А пока её не внедрят в продакшн в значительном кол-ве мест — про неё никто не узнает. Проблема курицы и яйца. Обычно решается поднятием маркетингового хайпа вокруг системы, но в случае инферно её разработчики предпочитают тихо сидеть и работать с системой, а не заниматься её раскруткой.
Даже я и то почти пять лет внедрял её крайне осторожно и точечно в нашу систему, т.к. не был уверен не вылезут ли где-нить проблемы с производительностью или надёжностью, активно тестируя чуть ли не каждую фичу перед использованием. И только недавно принял решение, что все тесты пройдены успешно, работает она отлично, и можно приступать к массовой замене текущих Perl+libev сервисов на инферно.
Ну, я бы хотел посмотреть на неё в условиях боевой нагрузки (условно — больше гигабита входящего трафика).
Для этого, видимо, надо начать с поддержки приличного серверного оборудования. ixgb/ixgbe портирован? aacraid/mpt2sas?
Для этого, видимо, надо начать с поддержки приличного серверного оборудования. ixgb/ixgbe портирован? aacraid/mpt2sas?
Я не понимаю, для каких задач Вы хотите её использовать? Как замену линуховому файрволу/роутеру на шлюзе? Возможно native инферно и может что-то в этом духе, не знаю, я этот вопрос не изучал и с native инферно не работал, но я сомневаюсь, что это является подходящим use case для инферно.
Как я уже упоминал, я просто пишу под инферно софт, фактически использую инферно как альтернативу для Perl или Java. Подумайте, насколько осмысленно звучат Ваши вопросы в отношении, например, JavaVM… Написать приложение на Java или Inferno которое будет как-то осмысленно обрабатывать гигабит входящего трафика, возможно, и получится. Смотря как обрабатывать и на каком железе. Но при чём тут портирование ixgb/ixgbe/aacraid/mpt2sas?
Как я уже упоминал, я просто пишу под инферно софт, фактически использую инферно как альтернативу для Perl или Java. Подумайте, насколько осмысленно звучат Ваши вопросы в отношении, например, JavaVM… Написать приложение на Java или Inferno которое будет как-то осмысленно обрабатывать гигабит входящего трафика, возможно, и получится. Смотря как обрабатывать и на каком железе. Но при чём тут портирование ixgb/ixgbe/aacraid/mpt2sas?
Ну, например, в качестве головы для раздачи дисков виртуальных машин. Примерные ожидания — поддержка кластеризации, способность обработать ~100k прерываний в секунду от оборудования, раздать (file/block io) 1-3 Гбит/с.
Это даже не совсем highload, но не «рутер».
ЗЫ Может я неправильно понимаю, inferno — это ОС или нет? прерывания, кольца защиты, виртуальная память, переключение процессов, скедулинг, свопинг, стек блочных устройств, сетевой стек… Что там ещё от казуальной ОС ожидают?
Это даже не совсем highload, но не «рутер».
ЗЫ Может я неправильно понимаю, inferno — это ОС или нет? прерывания, кольца защиты, виртуальная память, переключение процессов, скедулинг, свопинг, стек блочных устройств, сетевой стек… Что там ещё от казуальной ОС ожидают?
Прерывания — точно не скажу. Наверное, на уровне native ОС они есть, иначе она бы не работала. Но в user-space никаких прерываний нет.
Колец защиты и виртуальной памяти нет. Вся память плоская и доступна всем процессам (защита памяти обеспечивается сильной типизацией, я об этом уже писал).
Переключение процессов есть. Скедулинг — это что? Планировщик процессов (scheduler)? Есть.
Свопа нет.
Стек блочных устройств — поскольку устройство это просто файл в /dev, то стекирование этих устройств реализуется обычными файл-серверами в user space. Есть ли готовый файл-сервер, например, для реализации software RAID — я не знаю, никогда не интересовался.
Сетевой стек есть, хотя используется он скорее всего только в native Inferno, а hosted использует стек основной OS.
В общем, да, Инферно это ОС. И нет, это не альтернатива линуху на сервере или винде на десктопе. Да, Инферно работает и на встроенных устройствах и на суперкомпах вроде Blue Gene. Вероятно это означает, что, да, её можно запустить и на обычном сервере. Только вот смысла в этом скорее всего нет, т.к. для решения задач стоящих перед обычными серверами гораздо лучше приспособлены традиционные ОС, и возможностей инферно не хватит для решения этих задач. На обычных серверах/десктопах инферно имеет смысл запускать в hosted режиме как обычную VM (вроде JavaVM, а не VMware VM :)) или сервис.
Колец защиты и виртуальной памяти нет. Вся память плоская и доступна всем процессам (защита памяти обеспечивается сильной типизацией, я об этом уже писал).
Переключение процессов есть. Скедулинг — это что? Планировщик процессов (scheduler)? Есть.
Свопа нет.
Стек блочных устройств — поскольку устройство это просто файл в /dev, то стекирование этих устройств реализуется обычными файл-серверами в user space. Есть ли готовый файл-сервер, например, для реализации software RAID — я не знаю, никогда не интересовался.
Сетевой стек есть, хотя используется он скорее всего только в native Inferno, а hosted использует стек основной OS.
В общем, да, Инферно это ОС. И нет, это не альтернатива линуху на сервере или винде на десктопе. Да, Инферно работает и на встроенных устройствах и на суперкомпах вроде Blue Gene. Вероятно это означает, что, да, её можно запустить и на обычном сервере. Только вот смысла в этом скорее всего нет, т.к. для решения задач стоящих перед обычными серверами гораздо лучше приспособлены традиционные ОС, и возможностей инферно не хватит для решения этих задач. На обычных серверах/десктопах инферно имеет смысл запускать в hosted режиме как обычную VM (вроде JavaVM, а не VMware VM :)) или сервис.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Inferno Часть 0: пространства имён