The OpenNET Project / Index page

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



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

Оглавление

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

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


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.me/openforum/vsluhforumID3/124931.html#379
предыстория вопроса: https://www.opennet.me/openforum/vsluhforumID3/124931.html#355

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

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

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




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

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