The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Для ядра Linux предложена реализация SMB-сервера, opennews (??), 30-Авг-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


12. "Для ядра Linux предложена реализация SMB-сервера"  +1 +/
Сообщение от Kusb (?), 30-Авг-21, 19:59 
А почему такие реализации эффективнее? Из-за переключения режимов процессора и того факта, что мы много общаемся с ядром? А если вытащить из ядра те сущности с которыми общаемся, чтобы меньше переключений?
Mmu не используется и так быстрее? Что-то ещё типа не используется?
Ответить | Правка | Наверх | Cообщить модератору

16. "Для ядра Linux предложена реализация SMB-сервера"  +5 +/
Сообщение от Аноньимъ (ok), 30-Авг-21, 20:09 
>А почему такие реализации эффективнее?

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

>А если вытащить из ядра те сущности с которыми общаемся, чтобы меньше переключений?

А так и делают, есть реализации сетевого стека в юзерспейсе для нечистивого хайлоада, как открытые так и проприетарные работающие с конкретными сетевыми картами.

Видел однако мнение, что, лучше таким не срадать, ибо сетевой стек не просто так придумали.
Кроме того есть карты по типу челсио которые аппаратный TCP-IP предоставляют.

Самба же, в ядре, это чистой воды безумие, сатана плачет от зависти.

Что за жуткий такой хайлоад на сотни гигабит в секунду на самбе у кого-то?

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

29. "Для ядра Linux предложена реализация SMB-сервера"  +1 +/
Сообщение от Аноним (25), 30-Авг-21, 20:20 
Мелко мыслите, нужна аппратная реализация,
сменный чип на маме, типа ASIC
Ответить | Правка | Наверх | Cообщить модератору

63. "Для ядра Linux предложена реализация SMB-сервера"  –1 +/
Сообщение от Урри (ok), 30-Авг-21, 21:27 
> В первую очередь обход сетевого стека и файлового апи. ... безопасности, вот это всё, разделение ролей управление ресурсами.

Для этого сто лет в обед есть sendfile.

> Самба же, в ядре, это чистой воды безумие, сатана плачет от зависти.

+

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

106. "Для ядра Linux предложена реализация SMB-сервера"  +1 +/
Сообщение от anonymous (??), 31-Авг-21, 00:55 
> Для этого сто лет в обед есть sendfile

А кто будет со стороны ядра разбивать на samba frame-ы?

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

157. "Для ядра Linux предложена реализация SMB-сервера"  –1 +/
Сообщение от Урри (ok), 31-Авг-21, 10:19 
> А кто будет со стороны ядра разбивать на samba frame-ы?

А для этого маленького оверхеда и юзерспейса с головой хватит.

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

178. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от Аноним (178), 31-Авг-21, 13:54 
Любой юзерспейс - это переключения контекста.
Ответить | Правка | Наверх | Cообщить модератору

191. "Для ядра Linux предложена реализация SMB-сервера"  –1 +/
Сообщение от Урри (ok), 31-Авг-21, 15:16 
есть большая разница между переключением контекста между тасками в юзерспейсе, и переключением контекста в ядро со сменой кольца.
таски в юзерспейсе - почти ничто.
Ответить | Правка | Наверх | Cообщить модератору

209. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от kissmyass (?), 01-Сен-21, 00:13 
разница может и есть но "таски в юзерспейсе - почти ничто" далеко не ничто

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

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

215. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от n00by (ok), 01-Сен-21, 11:45 
Одному экземпляру чего? Так-то и машинный код условной функции потока общий для потоков и иммутабельный. Так и Урри, похоже, под " "таски в юзерспейсе - почти ничто" имеет ввиду сопрограммы, а не потоки ОС. Короче, каждый о своём и непонятно что сравнивает. :)
Ответить | Правка | Наверх | Cообщить модератору

20. "Для ядра Linux предложена реализация SMB-сервера"  +7 +/
Сообщение от Хан (?), 30-Авг-21, 20:14 
Защинененный режим процессора был создан как инструмент для изоляции кода ядра от пользовательского софта, другими словами когда приложение дергает ядро за системные вызовы, происходит переключение в режим ядра в котором выполняется только ядро, которое считывает номер системного вызова передаваемого пользовательским ПО и сопоставляет его со списком указателей на свои функции, после чего вызывает соответствующую функцию для обработки данного вызова и когда ядерная функция завершает свое выполнение снова происходит переключение режима процессора из превилигированного режима в неприлигированный

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

К чем это я? Да переключение режима процессора накладывает определенные расходы, но если все запихнуть в привилигированный режим ядра, в результате получится реальный режим, привет MS-DOS

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

207. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от Kusb (?), 31-Авг-21, 18:07 
Хорошо. А почему через заранее оговорённые регистры это "не напрямую"? Я воображал, что все функции вызываются как-то так, через параметры в регистрах.
Прошу прощения за ламерское видение, я не знаю где там переход на какой-то адрес, а где функция или ядро как-то вызывается (По прерываниям? В Колибри по моему так.)
Ответить | Правка | Наверх | Cообщить модератору

218. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от n00by (ok), 01-Сен-21, 12:16 
Да всё верно Вы воображали. "Изоляция достигается" когда при исполнении команд int (или syscall) изменяется уровень привилегий. Эта операция занимает времени больше, чем обычный вызов подпрограммы. Остальное (про регистры) лишнее.

Из ядра не вытащить, поскольку прерывание от сетевой обрабатывает ядро. Но всё подряд тянуть в ядро опасно.

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

21. "Для ядра Linux предложена реализация SMB-сервера"  –3 +/
Сообщение от пох. (?), 30-Авг-21, 20:15 
> А почему такие реализации эффективнее?

потому что переключения миллиона контекстов и протаскивание через миллион прослоек в ядре - не самая эффективная деятельность, не?

> А если вытащить из ядра те сущности с которыми общаемся, чтобы меньше переключений?

это как, прости? Адепт секты свидетелей микроядра, не дочитавший документацию отцов церкви? Там не меньше, там БОЛЬШЕ переключений - и еще и очень неудобное и неэффективное взаимодействие, обложенное миллионом прокладочек и подпорочек с проверочками, а иначе вся польза от микроядерности - к х-ю сведется.

Самба представляет собой сетевой интерфейс доступа к файлам на локальной fs. То есть ей нужен весь набор механизмов файловых систем. Включая непростые и неочевидные, например, блокировки.
И изрядный набор сетевых функций. Потому как ей надо отправлять пакетики и принимать пакетики, причем разом тремя разными способами, если полностью реализовывать спецификации (кто квакал про rdma?).

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

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

30. "Для ядра Linux предложена реализация SMB-сервера"  –4 +/
Сообщение от Хан (?), 30-Авг-21, 20:21 
Предлагаешь вернуться во времена MS-DOS и реального режима?
Ответить | Правка | Наверх | Cообщить модератору

48. "Для ядра Linux предложена реализация SMB-сервера"  –1 +/
Сообщение от нах.. (?), 30-Авг-21, 21:08 
Да, и наконецто.
Ответить | Правка | Наверх | Cообщить модератору

55. "Для ядра Linux предложена реализация SMB-сервера"  +2 +/
Сообщение от Хан (?), 30-Авг-21, 21:16 
Неееееет! Это уже слишком
Ответить | Правка | Наверх | Cообщить модератору

214. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от Аноним (214), 01-Сен-21, 07:54 
Так freedos уже есть, скачать можно бесплатно и без смс.
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

216. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от kusb (?), 01-Сен-21, 12:03 
Я бы посмотрел на какой-нибудь киберпанк (циферки) для DOS. Но драйверы протаскивать, современные вещи протаскивать и т.п. Целый набор библиотек, наверное, что делает современная ОС. Dos в большей степени будет загрузчиком. Хранить ресурсы мы будем в едином архиве и почти не завязываться на ФС DOS...
Ответить | Правка | Наверх | Cообщить модератору

66. "Для ядра Linux предложена реализация SMB-сервера"  –1 +/
Сообщение от InuYasha (??), 30-Авг-21, 21:33 
Почему нет? А лучше и без MS-.
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

67. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от Урри (ok), 30-Авг-21, 21:34 
>> А почему такие реализации эффективнее?
> Потому как ей надо отправлять пакетики и принимать пакетики

А файловые пакетики в самбе - это по 10 байт? "Хочу 10 байт этого файла, и 10 этого, и, пожалуй, еще два вот этого."?

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

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

79. "Для ядра Linux предложена реализация SMB-сервера"  –2 +/
Сообщение от пох. (?), 30-Авг-21, 22:20 
> А файловые пакетики в самбе - это по 10 байт? "Хочу 10

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

> Для эффективной передачи массивов данных, чтобы не прыгать туда-сюда, не (пере)аллоцировать,
> не (пере)копировать память и не перекидывать контексты, давным-давно существует sendfile.

и тут модный-современный разработчик внезапно обнаруживает что smb3-то - шифрованный.

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

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

80. "Для ядра Linux предложена реализация SMB-сервера"  –1 +/
Сообщение от Урри (ok), 30-Авг-21, 22:25 
> И банальная проверка что файл вообще существует - с полным проходом по всему пути к нему

Для этого существует сискол stat
У вас там совсем рукожопы все делали?

> smb3-то - шифрованный

Это нюанс, да. Ну да тут такое дело: хотите все шифровать - страдайте.

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

89. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от пох. (?), 30-Авг-21, 23:31 
у нас - это в microsoft? Нет, нормальные разработчики делали, в отличие от тебя в голову не только ели.

Сискол стат на твоем локалхосте совершенно бесполезен, когда файл лежит где-то на сервере.

А чтобы выполнить его на сервере - надо пройти по всей иерархии, причем виртуальная вовсе не обязана 1:1 отражать реальную структуру fs сервера, это вообще может быть не одна fs, и хотя бы убедиться, что путь существует (_отдельно_ - с точки зрения smb, позволено ли ему вообще отдавать такой путь, _отдельно_ - с точки зрения fs, а есть ли то во что он в конце-то концов отмапится - в принципе). А вообще-то еще бы и неплохо проверить, есть ли именно у данного пользователя права по нему ходить так далеко, и еще отдельно - на сам этот "stat" (тут есть некрасивый фокус, я его пропущу).

Видишь, сколько неожиданных сложностей возникает при решении реальных задач, непохожих на твой хеловорд?

Домашнее задание  - посчитать сколько тут будет переключений контекста при реализации самбы в юзерспейсе и прикинуть, сколько блоков с диска реально при этом придется прочитать, если размер стораджа не совсем детский.

> Это нюанс, да. Ну да тут такое дело: хотите все шифровать - страдайте.

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

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

158. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от Урри (ok), 31-Авг-21, 10:31 
stat прекрасно делает все вышеперечисленное и много больше. И пути проверяет, и по разным ФС бегает, и симлинки отслеживает по флажку, и права проверяет. И вообще ну вот все, что надо.

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

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

225. "Для ядра Linux предложена реализация SMB-сервера"  +1 +/
Сообщение от пох. (?), 01-Сен-21, 14:20 
Модный современный разработчик лишенный мозгов, как и следовало ожидать.

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

> Ну а рукожопы, которые решили свой кривой мегавелосипед с квадратными колесами

я верю что в твоем хеловроте под пиццот архитектур все прямое.

А у нас в сетевых системах прежде чем будет на что выполнить stat (если вообще будет, кстати) - исполняется примерно то что я попытался тебе описать. Сложная это штука, сетевые fs, не для твоего понимания.

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

230. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от Урри (ok), 02-Сен-21, 13:08 
Так я и говорю - через опу у вас все. Страдайте.
Ответить | Правка | Наверх | Cообщить модератору

231. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от пох. (?), 02-Сен-21, 13:39 
то есть до тебя так и не дошло что так работают сетевые fs? Ну ооок...

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

237. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от Урри (ok), 02-Сен-21, 14:24 
Ты все еще пытаешься доказать, что не через _опу писано руко_опами?
Ответить | Правка | Наверх | Cообщить модератору

121. "Для ядра Linux предложена реализация SMB-сервера"  +3 +/
Сообщение от Аноним (121), 31-Авг-21, 05:59 
>Это нюанс, да. Ну да тут такое дело: хотите все шифровать - страдайте.

Справедливости ради, инженеры прошлого изобрели ужасно универсальный IPSec. Он так же в ядре и полностью совместим с sendfile. По уму следовало всем расширять и использовать его, а не городить шифрование поверх каждого протокола по отдельности, регулярно ловя уникальные ошибки безопасности в каждом.

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

131. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от пох. (?), 31-Авг-21, 08:19 
Прикинь, как должна выглядеть реализация https поверх, например.

Ну в смысле, необязательно именно https, а любого протокола, требующего установки шифрованного соединения с недоверенными и заранее неизвестными 3d-party, причем сразу пачкой разных, и чтоб не получить дырку для mitm размером с паровоз.

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

Поэтому и нивзлетело - даже у microsoft, где в принципе настройки человекообразны еще со времен 2000 (но вот с сертификатами и прочими сложными вариантами xauth - полная беда даже по сей день и любой ентерпрайзный vpn софт первым делом городит свой костыль вместо виндовых).

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

А ms хочет чтобы юзер в Африке мог пошарить папочку - а юзер в Бангалоре файлик оттуда скопипастил не напрягая извилин и без необходимости рыть туннель через всю планетку.

Вот и приходится отдельное шифрование в каждом протоколе заводить, чтоб ничего не настраивать.

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

136. "Для ядра Linux предложена реализация SMB-сервера"  –1 +/
Сообщение от СеменСеменыч777 (?), 31-Авг-21, 08:50 
> ужасно универсальный IPSec.

вы идите, идите. а мы вас бить не будем. может быть.

> Он так же в ядре и полностью совместим с sendfile.

начнем с того, что он несовместим сам с собой.
разные реализации, сделанные разными людьми для разных платформ,
и вроде бы все по одному стандарту.

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

159. "Для ядра Linux предложена реализация SMB-сервера"  +1 +/
Сообщение от Урри (ok), 31-Авг-21, 10:32 
>>Это нюанс, да. Ну да тут такое дело: хотите все шифровать - страдайте.
> Справедливости ради, инженеры прошлого изобрели ужасно универсальный IPSec. Он так же в
> ядре и полностью совместим с sendfile.

Спасибо за наводку. Ушел досамообразовываться.

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

134. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от СеменСеменыч777 (?), 31-Авг-21, 08:41 
> есть у меня сервис [...] который просто складывается, если [...]
> количество этих файликов - мама не горюй.

enjoy your файлопомойка.

гипотеза: сервис никто не проектировал, никто не реинженерил,
бездумно перетащили с нетвари целиком, где оно само как-то выросло.
и нетрививальную раскладку прав доступа тоже с нетвари.
да ?

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

232. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от пох. (?), 02-Сен-21, 13:44 
> enjoy your файлопомойка.

его задача - работать с файлами. Помимо прочего. Что он и делает.
Это оригиналы, их трогать нельзя - могут потом и на экспертизу потребовать, на тему следов фотошопа.

> гипотеза: сервис никто не проектировал, никто не реинженерил,

трудное у тебя было детство.

Нормально его спроектировали, но такие объемы совсем без проблем переварить не получится - хоть на чем.

Я одно не понимаю - зачем вы лезете со своими непрошенными советами, когда вам совершенно другую вещь на этом примере пытаются продемонстрировать?

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

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

250. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от СеменСеменыч777 (?), 03-Сен-21, 22:56 
> его задача - работать с файлами. Помимо прочего. Что он и делает.

по твоему же описанию, он делает это хреново.

> трудное у тебя было детство.
> синдром собственной ох..енности

психоанализ меня по переписке, без моего запроса и без оплаты == дилетант по ту сторону экрана.

ps: я получу наконец ответ на свой вопрос или нет?
вопрос очень простой: https://www.opennet.ru/openforum/vsluhforumID3/124931.html#379
предыстория вопроса: https://www.opennet.ru/openforum/vsluhforumID3/124931.html#355

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

107. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от anonymous (??), 31-Авг-21, 00:56 
> это как, прости?

usnic?

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

196. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от Kusb (?), 31-Авг-21, 15:45 
Ну я не очень хорошо разбираюсь в компьютерах. Достаточно чтобы рассуждать о контекстах и всяких таких вещах, но всё равно, так что я не знаю сколько там прослоек и переключений. Хотя если они так влияют, то скажу что "наверное" это беда, раз такие падения производительности, это место для оптимизации. Если вызов ЛЮБОЙ ФУНКЦИИ тормозит, то и ядро.
Ну или выхода немного, безопасность важна.

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

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

233. "Для ядра Linux предложена реализация SMB-сервера"  +/
Сообщение от пох. (?), 02-Сен-21, 13:49 
> всё в режим ядра избавляться от переключений контекста (и сейчас подумал
> - прослоек) вытаскиванием нужного в режим пользователя. И лишних проверок тоже

ну ты почти уже изобрел ceph. Примерно так они в последних версиях и сделали - fs нинужна, мы ниасилили, давайте сделаем raw partition и...положим на него базу данных, помимо прочего. Зато ядро нинужна и переключений контекстов минимум.

А когда (даже не "если") оно все у нас навернется - чинить незачем, выкрасить и новую ноду запустить.

> не делать. Может получится всё-ж безопаснее чем в ядро. А может

не, не получится.

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

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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