Для включение в состав следующего выпуска ядра Linux предложена новая реализация файлового сервера, использующего протокол SMB3. Сервер оформлен в виде модуля ядра ksmbd и дополняет ранее доступный код клиента SMB. Отмечается, что в отличие от SMB-сервера, работающего в пространстве пользователя, реализация на уровне ядра более эффективна с точки зрения производительности, потребления памяти и интеграции с расширенными возможностями ядра...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55706
Ну и дыры тогда можно будет прямо эскалировать на уровень ядра ))
сабжем можно не пользоваться, используйте самбу и запретите модуль.в отличие от ebpf, например.
ebpf тоже можно отключить
"пересобрать ядро" для eBPF и "выгрузить модуль" для ksmbd - это немного разные вариации "отключить".
гнать ссаными тряпками из ядра
А Doorshlug в этой штуке будет?
И не только он, а еще оооочень много чего
И telemetry
Нет, только analnyi zond
Backdoorshlug
Так и до браузера в ядре не далеко, для продуктивности и компактности кода. Будет kmodfirefox на расте.Или емакс.
>Будет kmodfirefox на расте.Будет Google Chrome OS - kernel mode edition.
> Или емакс.EMACS будет встроен в GRUB.
А systemd в ядро. Ну или наборот: systemd-kerneld.
>Для ядра Linux предложена реализацияНадо еще реализации видеоплеера, месагера и кофеварки, ну, чтоб эффективее
Ну а чо - ведь очевидно же, что реализация на уровне ядра более эффективна с точки зрения производительности, потребления памяти и интеграции с расширенными возможностями ядра.Я бы еще gcc туда же засунул со всеми либами. И ллвм. Да и питон, чего уж греха таить, тоже бы туда всунул - может чуть меньше бы тормозил.
А еще vs code. А то что-то притормаживает последнее время.
Игры же.
Вот это вещь !!!
Интересно, кто выиграет право быть засунутым в ядро: Spydermonkey или V8?
Зачем "или"?
И то и то, я юзер пусть сам в рантайме выбирает.
низзя пользователю дать что-то выбирать! прибить гвоздями, чтобы оно померло и было бесполезно, но удалить его было невозможно из-за перекрестных зависимостей!
VS Code работает как пуля если у тебя конечно минимум 16 гиг оперативы, а иначе своп... своп... своп
> VS Code работает как пуля если у тебя конечно минимум 16 гиг
> оперативы, а иначе своп... своп... своп16 и своп отключен совсем. Не в памяти дело - просто куча плагинов под всякое нужное и ненужное. Начиная с маркдауна и заканчивая gdb.
Такое бывает когда хочешь обычный редактор кода превратить в IDE
> своп отключен совсем.не надо так. создайте хотя бы 1 ГБ (можно на сжатом рам-диске или zswap) и посмотрите что получится.
Гляну, ок.
Ничего не поменялось.
> Ничего не поменялось.черт возьми. больше идей нет. дальше идут только трассировка, профилирование, написание баг-репортов и обновление софта с железом.
А для удобного управления всем этим сверху надстроить гиперядро...
С разморозкой! Сразу скажу, ничего хорошего Вы не пропустили. Ах да, чуть не забыл. Гиперядро принято называть systemd.
Модули же. Вместо исполняемых файлов. Всегда.
Да здравствует реальный режим!
RDMA без ядра же не реализуешь, правильно?
man OFED.
man MPI
В novell netware так и было, ради производительности
Так Вам надо просто какой-то embedded распотрошить и сделать его userfrendly.
Не знаю какую-то старую Simbian собрать и будет счастье. Особенно на 80386 каких-нибудь.
А клиент?
Клиент сто лет как в ядре https://www.kernel.org/doc/html/latest/admin-guide/cifs/inde...
А почему такие реализации эффективнее? Из-за переключения режимов процессора и того факта, что мы много общаемся с ядром? А если вытащить из ядра те сущности с которыми общаемся, чтобы меньше переключений?
Mmu не используется и так быстрее? Что-то ещё типа не используется?
>А почему такие реализации эффективнее?В первую очередь обход сетевого стека и файлового апи.
От чего значительное сокращение переключений контекста всяких и копирований информации между буферами. Проверки безопасности, вот это всё, разделение ролей управление ресурсами.>А если вытащить из ядра те сущности с которыми общаемся, чтобы меньше переключений?
А так и делают, есть реализации сетевого стека в юзерспейсе для нечистивого хайлоада, как открытые так и проприетарные работающие с конкретными сетевыми картами.
Видел однако мнение, что, лучше таким не срадать, ибо сетевой стек не просто так придумали.
Кроме того есть карты по типу челсио которые аппаратный TCP-IP предоставляют.Самба же, в ядре, это чистой воды безумие, сатана плачет от зависти.
Что за жуткий такой хайлоад на сотни гигабит в секунду на самбе у кого-то?
Мелко мыслите, нужна аппратная реализация,
сменный чип на маме, типа ASIC
> В первую очередь обход сетевого стека и файлового апи. ... безопасности, вот это всё, разделение ролей управление ресурсами.Для этого сто лет в обед есть sendfile.
> Самба же, в ядре, это чистой воды безумие, сатана плачет от зависти.
+
> Для этого сто лет в обед есть sendfileА кто будет со стороны ядра разбивать на samba frame-ы?
> А кто будет со стороны ядра разбивать на samba frame-ы?А для этого маленького оверхеда и юзерспейса с головой хватит.
Любой юзерспейс - это переключения контекста.
есть большая разница между переключением контекста между тасками в юзерспейсе, и переключением контекста в ядро со сменой кольца.
таски в юзерспейсе - почти ничто.
разница может и есть но "таски в юзерспейсе - почти ничто" далеко не ничтоне так давно столкнулся с замерами, создание объекта для каждого потока осуществлялось быстрее, чем получение доступа к общему для всех потоков экземпляру (никакой синхронизации просто доступ к immutable объекту)
Одному экземпляру чего? Так-то и машинный код условной функции потока общий для потоков и иммутабельный. Так и Урри, похоже, под " "таски в юзерспейсе - почти ничто" имеет ввиду сопрограммы, а не потоки ОС. Короче, каждый о своём и непонятно что сравнивает. :)
Защинененный режим процессора был создан как инструмент для изоляции кода ядра от пользовательского софта, другими словами когда приложение дергает ядро за системные вызовы, происходит переключение в режим ядра в котором выполняется только ядро, которое считывает номер системного вызова передаваемого пользовательским ПО и сопоставляет его со списком указателей на свои функции, после чего вызывает соответствующую функцию для обработки данного вызова и когда ядерная функция завершает свое выполнение снова происходит переключение режима процессора из превилигированного режима в неприлигированныйВ чем суть данной технологии? Пользовательский код в неприлигированном режиме может общаться с кодом ядра в прилигированном режиме не напрямую, а через заранее оговоренные регистры, так достигается изоляция
К чем это я? Да переключение режима процессора накладывает определенные расходы, но если все запихнуть в привилигированный режим ядра, в результате получится реальный режим, привет MS-DOS
Хорошо. А почему через заранее оговорённые регистры это "не напрямую"? Я воображал, что все функции вызываются как-то так, через параметры в регистрах.
Прошу прощения за ламерское видение, я не знаю где там переход на какой-то адрес, а где функция или ядро как-то вызывается (По прерываниям? В Колибри по моему так.)
Да всё верно Вы воображали. "Изоляция достигается" когда при исполнении команд int (или syscall) изменяется уровень привилегий. Эта операция занимает времени больше, чем обычный вызов подпрограммы. Остальное (про регистры) лишнее.Из ядра не вытащить, поскольку прерывание от сетевой обрабатывает ядро. Но всё подряд тянуть в ядро опасно.
> А почему такие реализации эффективнее?потому что переключения миллиона контекстов и протаскивание через миллион прослоек в ядре - не самая эффективная деятельность, не?
> А если вытащить из ядра те сущности с которыми общаемся, чтобы меньше переключений?
это как, прости? Адепт секты свидетелей микроядра, не дочитавший документацию отцов церкви? Там не меньше, там БОЛЬШЕ переключений - и еще и очень неудобное и неэффективное взаимодействие, обложенное миллионом прокладочек и подпорочек с проверочками, а иначе вся польза от микроядерности - к х-ю сведется.
Самба представляет собой сетевой интерфейс доступа к файлам на локальной fs. То есть ей нужен весь набор механизмов файловых систем. Включая непростые и неочевидные, например, блокировки.
И изрядный набор сетевых функций. Потому как ей надо отправлять пакетики и принимать пакетики, причем разом тремя разными способами, если полностью реализовывать спецификации (кто квакал про rdma?).Естественно, в контексте ядра, где это банально вызовы сишных функций, будет быстрее и надежнее чем протаскивать это все через userland.
Предлагаешь вернуться во времена MS-DOS и реального режима?
Да, и наконецто.
Неееееет! Это уже слишком
Так freedos уже есть, скачать можно бесплатно и без смс.
Я бы посмотрел на какой-нибудь киберпанк (циферки) для DOS. Но драйверы протаскивать, современные вещи протаскивать и т.п. Целый набор библиотек, наверное, что делает современная ОС. Dos в большей степени будет загрузчиком. Хранить ресурсы мы будем в едином архиве и почти не завязываться на ФС DOS...
Почему нет? А лучше и без MS-.
>> А почему такие реализации эффективнее?
> Потому как ей надо отправлять пакетики и принимать пакетикиА файловые пакетики в самбе - это по 10 байт? "Хочу 10 байт этого файла, и 10 этого, и, пожалуй, еще два вот этого."?
Для эффективной передачи массивов данных, чтобы не прыгать туда-сюда, не (пере)аллоцировать, не (пере)копировать память и не перекидывать контексты, давным-давно существует sendfile.
> А файловые пакетики в самбе - это по 10 байт? "Хочу 10у современных разработчиков мозгов вообще нет? Прежде чем приедет хоть один файловый пакетик - приезжает еще пара сотен других, в обе стороны.
Причем, внезапно, это нифига не безобидная и не копеечная нагрузка - есть у меня сервис, не особо даже высоконагруженный (это корпоративный хайлоад, не торчащий на улицу) который просто складывается, если возникают малейшие проблемы с сетью или файловыми хранилками. Причем файлики в нем по десятку мегабайт максимум, обычно меньше. А вот количество этих файликов - мама не горюй. И банальная проверка что файл вообще существует - с полным проходом по всему пути к нему - внезапно, упирается в пропускную способность, не смотря на все кэши и попытки уменьшить число таких поисков.> Для эффективной передачи массивов данных, чтобы не прыгать туда-сюда, не (пере)аллоцировать,
> не (пере)копировать память и не перекидывать контексты, давным-давно существует sendfile.и тут модный-современный разработчик внезапно обнаруживает что smb3-то - шифрованный.
А помимо "эффективной передачи" в один конец, в режиме плюнули и забыли (для которой хватило бы и ftp) есть еще другие варианты работы с файлами. О чем модные разработчики, похоже, тоже не в курсе.
> И банальная проверка что файл вообще существует - с полным проходом по всему пути к немуДля этого существует сискол stat
У вас там совсем рукожопы все делали?> smb3-то - шифрованный
Это нюанс, да. Ну да тут такое дело: хотите все шифровать - страдайте.
у нас - это в microsoft? Нет, нормальные разработчики делали, в отличие от тебя в голову не только ели.Сискол стат на твоем локалхосте совершенно бесполезен, когда файл лежит где-то на сервере.
А чтобы выполнить его на сервере - надо пройти по всей иерархии, причем виртуальная вовсе не обязана 1:1 отражать реальную структуру fs сервера, это вообще может быть не одна fs, и хотя бы убедиться, что путь существует (_отдельно_ - с точки зрения smb, позволено ли ему вообще отдавать такой путь, _отдельно_ - с точки зрения fs, а есть ли то во что он в конце-то концов отмапится - в принципе). А вообще-то еще бы и неплохо проверить, есть ли именно у данного пользователя права по нему ходить так далеко, и еще отдельно - на сам этот "stat" (тут есть некрасивый фокус, я его пропущу).
Видишь, сколько неожиданных сложностей возникает при решении реальных задач, непохожих на твой хеловорд?
Домашнее задание - посчитать сколько тут будет переключений контекста при реализации самбы в юзерспейсе и прикинуть, сколько блоков с диска реально при этом придется прочитать, если размер стораджа не совсем детский.
> Это нюанс, да. Ну да тут такое дело: хотите все шифровать - страдайте.
все нюансы, не укладывающиеся в картину мира модного современного разработчика, и не подходящие под единственное осиленное им простое решение - объявляются ненужными и несущественными.
stat прекрасно делает все вышеперечисленное и много больше. И пути проверяет, и по разным ФС бегает, и симлинки отслеживает по флажку, и права проверяет. И вообще ну вот все, что надо.Ну а рукожопы, которые решили свой кривой мегавелосипед с квадратными колесами запилить должны страдать, а не пытаться пролезть без мыла туда, где не нужны.
Модный современный разработчик лишенный мозгов, как и следовало ожидать.stat у него через /dev/astral все это делает прямо на сервере, угадав чего именно ему stat через тот же /dev/astral Попытка объяснить как это на самом деле работает и что произойдет если дернуть stat, и заставить хоть немножко усомниться в своей непогрешимости - в межушный ганглий не поместилась, там костью все занято и непробиваемой самоуверенностью.
> Ну а рукожопы, которые решили свой кривой мегавелосипед с квадратными колесами
я верю что в твоем хеловроте под пиццот архитектур все прямое.
А у нас в сетевых системах прежде чем будет на что выполнить stat (если вообще будет, кстати) - исполняется примерно то что я попытался тебе описать. Сложная это штука, сетевые fs, не для твоего понимания.
Так я и говорю - через опу у вас все. Страдайте.
то есть до тебя так и не дошло что так работают сетевые fs? Ну ооок...
Ты все еще пытаешься доказать, что не через _опу писано руко_опами?
>Это нюанс, да. Ну да тут такое дело: хотите все шифровать - страдайте.Справедливости ради, инженеры прошлого изобрели ужасно универсальный IPSec. Он так же в ядре и полностью совместим с sendfile. По уму следовало всем расширять и использовать его, а не городить шифрование поверх каждого протокола по отдельности, регулярно ловя уникальные ошибки безопасности в каждом.
Прикинь, как должна выглядеть реализация https поверх, например.Ну в смысле, необязательно именно https, а любого протокола, требующего установки шифрованного соединения с недоверенными и заранее неизвестными 3d-party, причем сразу пачкой разных, и чтоб не получить дырку для mitm размером с паровоз.
Не то чтоб совсем невозможно, в xauth можно и обычные сертификаты запихать - но это именно та часть протокола, которая ни у кого толком не получилась совместимой, надежной и вообще хоть сколько-то разумной даже в существующем виде. А представь что еще и через прикладной софт пришлось бы все это протаскивать (с возможностью человеческим языком сказать пользователю, что пошло не так где-то там внизу стека)...
Поэтому и нивзлетело - даже у microsoft, где в принципе настройки человекообразны еще со времен 2000 (но вот с сертификатами и прочими сложными вариантами xauth - полная беда даже по сей день и любой ентерпрайзный vpn софт первым делом городит свой костыль вместо виндовых).
То есть тотальный ipsec в рамках хотя бы большого офиса - в целом технически можно, но у тебя скорее всего не получится или выйдет дыряво. С неопределенным кругом неизвестных заранее контрагентов - никак.
А ms хочет чтобы юзер в Африке мог пошарить папочку - а юзер в Бангалоре файлик оттуда скопипастил не напрягая извилин и без необходимости рыть туннель через всю планетку.
Вот и приходится отдельное шифрование в каждом протоколе заводить, чтоб ничего не настраивать.
> ужасно универсальный IPSec.вы идите, идите. а мы вас бить не будем. может быть.
> Он так же в ядре и полностью совместим с sendfile.
начнем с того, что он несовместим сам с собой.
разные реализации, сделанные разными людьми для разных платформ,
и вроде бы все по одному стандарту.
>>Это нюанс, да. Ну да тут такое дело: хотите все шифровать - страдайте.
> Справедливости ради, инженеры прошлого изобрели ужасно универсальный IPSec. Он так же в
> ядре и полностью совместим с sendfile.Спасибо за наводку. Ушел досамообразовываться.
> есть у меня сервис [...] который просто складывается, если [...]
> количество этих файликов - мама не горюй.enjoy your файлопомойка.
гипотеза: сервис никто не проектировал, никто не реинженерил,
бездумно перетащили с нетвари целиком, где оно само как-то выросло.
и нетрививальную раскладку прав доступа тоже с нетвари.
да ?
> enjoy your файлопомойка.его задача - работать с файлами. Помимо прочего. Что он и делает.
Это оригиналы, их трогать нельзя - могут потом и на экспертизу потребовать, на тему следов фотошопа.> гипотеза: сервис никто не проектировал, никто не реинженерил,
трудное у тебя было детство.
Нормально его спроектировали, но такие объемы совсем без проблем переварить не получится - хоть на чем.
Я одно не понимаю - зачем вы лезете со своими непрошенными советами, когда вам совершенно другую вещь на этом примере пытаются продемонстрировать?
(ну то есть понимаю - синдром собственной ох..енности просто не дает пройти мимо того, что никак с вашими куцыми знаниями и опытом не коррелирует)
> его задача - работать с файлами. Помимо прочего. Что он и делает.по твоему же описанию, он делает это хреново.
> трудное у тебя было детство.
> синдром собственной ох..енностипсихоанализ меня по переписке, без моего запроса и без оплаты == дилетант по ту сторону экрана.
ps: я получу наконец ответ на свой вопрос или нет?
вопрос очень простой: https://www.opennet.ru/openforum/vsluhforumID3/124931.html#379
предыстория вопроса: https://www.opennet.ru/openforum/vsluhforumID3/124931.html#355
> это как, прости?usnic?
Ну я не очень хорошо разбираюсь в компьютерах. Достаточно чтобы рассуждать о контекстах и всяких таких вещах, но всё равно, так что я не знаю сколько там прослоек и переключений. Хотя если они так влияют, то скажу что "наверное" это беда, раз такие падения производительности, это место для оптимизации. Если вызов ЛЮБОЙ ФУНКЦИИ тормозит, то и ядро.
Ну или выхода немного, безопасность важна.Ну микроядро делают обычно для безопасности, а я то про оптимизацию. Что будет если вывернуть его на изнанку и вместо того, чтобы тащить всё в режим ядра избавляться от переключений контекста (и сейчас подумал - прослоек) вытаскиванием нужного в режим пользователя. И лишних проверок тоже не делать. Может получится всё-ж безопаснее чем в ядро. А может и научить компоненты мигрировать между контекстами и автоматически патчить в памяти пути, по которым вызываются функции оптимизируя проверки в них и т.п.
> всё в режим ядра избавляться от переключений контекста (и сейчас подумал
> - прослоек) вытаскиванием нужного в режим пользователя. И лишних проверок тожену ты почти уже изобрел ceph. Примерно так они в последних версиях и сделали - fs нинужна, мы ниасилили, давайте сделаем raw partition и...положим на него базу данных, помимо прочего. Зато ядро нинужна и переключений контекстов минимум.
А когда (даже не "если") оно все у нас навернется - чинить незачем, выкрасить и новую ноду запустить.
> не делать. Может получится всё-ж безопаснее чем в ядро. А может
не, не получится.
Какой изысканный невероятный бред. Линукс не перестаёт удивлять.
Как знатно пингвинчик жиреет! Ну теперь ещё ядро раскормить системдой, вяйлендом, трубопроводом и Винда нервно закурит в сторонке, особенно когда ядром займутся растоманы, которые всё могут, но ничего не умеют!
Линукс тут причём? Это идиоты из мелкасофт
А кто больший? Тот кто это сделал, или тот кто примет это в ядро?
Линусу уже давно настоящие хозяева линукса сказали комитить, а не рефлексировать.
90% кода "независимого" ляликса пилится корпорациями. Чо сразу майки-то.
> Линукс тут причём? Это идиоты из мелкасофтТак они же одни из крупных коммитеров в линукс.
Линукс был бы не причём, если
1) это делали бы разработчики не связанные с линуксом
2) на это бы пошла реакция (не от анонимов с опеннета, а с Linux Foundation) — «это мы не примем».
> не от анонимов с опеннета, а с Linux FoundationОснователями и спонсорами которой были 7 крупнейших компьютерных корпораций: Computer Associates, Fujitsu, Hitachi, Ltd., Hewlett-Packard, IBM, Intel, NEC? И как ты это представляешь?
> Какой изысканный невероятный бред. Линукс не перестаёт удивлять.Изысканный и невероятной бред - это комментарии к этой новости. Если понять как работают некоторые вещи, то и удивляться перестанете.
Во-первых, SMB - это очень большой протокол, который среди прочего реализует сетевую файловую систему. Схожий протокол, NFS и его серверная реализация в пространстве ядра (knfsd.ko) сколько существует?
Во-вторых, не надо путать протокол SMB и Samba 4.Я позволю себе вам напомнить, что Samba 3 != Samba 4. Это 2 совершенно разных сервера выполняющих разные задачи. Samba 3, ныне покойная, являлась реализацией протокола SMB, NetBT, WINS и многих других частей устаревшего сетевого стека времен Windows 9x. Не забывайте, что SMB не порождает ни одноранговую сеть ни "Сетевое окружение" не занимается именами, не ведет листинг хостов и тем более не держит на себе ничего что связано с печатью. А между прочим Samba реализует внутри себя тонну служб Windows включая, например, Winbind - посредственную реализацию аутентификации и авторизации. Ну и не забываем про то что Samba испокон веков занимается трансляцией ACL (Маленькое подмножество NT ACL в то что умеет ядро ОС, под которую она собрана).
Samba 4 - это вообще монстр, цель которого, лично мне не ясна, но оно включает в себя огромное количество функций Active Directory и позволяет порождать керберос-реалм... вот это всё ну вообще не рядом с SMB.Когда читаешь комментарии тут, сразу понятно, что народ путает еще 2 вещи:
1. SMB в изначальном IBM-овском исполнении в связке с NetBIOS. Он известен как SMB1 или CIFS
2. Обновленные SMB исполнении от Microsoft, которому не нужны технологии прошлого века от IBM. SMB 2+
Исторически Samba пыталась реализовать старый SMB1 и ей это удалось. Затем пришел SMB 2, который просто добавили, потому что он проще. А вот SMB 3 содержит внутри себя много функций, которые нельзя производительно реализовать в юзерспейсе. Прежде всего отказоустойчивость (костылики вроде DFS канули в лету), Multichannel для возможности лить данные через конвергентные сетевые адаптеры, утилизируя их целиком, а также поддержка RDMA и организация доставки програмно определяемого стораджа S2D (Storage Space Direct). Вот в юзерспейсе SMB3 банально не имеет смысла.Дополнительно, нужно отметить что SMB1 официально не поддерживается совместно с SMB3.1. Свежайшая версия стандарта откажется работать с SMB1 прямо на уровне предаутентификации и потребует выключения его поддержки. Нет ничего плохого в том, что он наконец-то заработает в ядре, где ему и место. Samba тут не при чем, это другое. Реализация SMB в Samba - это лишь малая часть её функционала, который накапливался почти 30 лет.
Если говорить про настоящий бред, который происходит в ядре Линукс - это "поддержка ACL". Это касается не только SMB в ядре, но и посредственной поддержки NFS. Дело в том, что в Linux используется недоразумение под названием "Posix ACL", которые официально не входят в стандарт Posix не были приняты и не существуют за пределами Linux. NFS, например, использует NFSv4 ACL свои собственные, а SMB использует SDDL (Security Descriptor Definition Language), который объявляет 256-битные дескрипторы безопасности, идентификаторы в форме S-1-x-xx-xxxxx-xxxxx-xxx на 128 bit и вместе с ними DACL/SACL. И вот ни NFSv4 ACL, ни NT ACL никак не конвертируются в "Posix" ACL, ввиду ограниченности последних. При этом NFSv4 и NT очень близки за тем лишь исключением, что NT ACL поддерживает внутри себя условия проверки утверждений, пришедших из билетов Kerberos 5. То есть, можно просунуть атрибуты LDAP внутрь билетов. Это используется, например, для того чтобы предоставлять доступ пользователю только в том случае, если запрос авторизации поступил с доменного компьютера, который содержится в такой-то такой-то группе ну или там плюс еще какой-то атрибут. Этим функционалом ACL можно пренебречь, на самом деле, ввиду гигантского объема требований (ресурсы и сеть) к топологии развертывания и опять же не имеет отношения к самому главному - передаче данных по сети.
Сообщество Samba одни из тех кто и ACL хотел поменять на нормальные, хоть бы родные для NFS, по-барабану, что не полная поддержка все луче чем то что есть. В случае переноса реализации SMB в ядро, Samba как минимум начнет работать также как NFS. Тоже плохо (ACL и безопасность в юзерспейсе), но всяко лучше чем то что есть.
P.S. Дырки в безопасности о которых все так любят писать - это наличие поддержки SMB1 в пакетах samba-server в дистрибутивах. MS выпилил всем современным вендам этот копролит, а тут получается ни SMB3 не поддерживается ни SMB1 полностью выпилить нельзя. Мрак.
> Прежде всего отказоустойчивость (костылики вроде DFS канули в лету), Multichannel для возможности лить данные через конвергентные сетевые адаптеры, утилизируя их целиком, а также поддержка RDMA и организация доставки програмно определяемого стораджа S2D (Storage Space Direct).А можно ссылок на подробности этого? И как применять. Интересно как это выкинуть dfs в географически распределенных системах.
> А можно ссылок на подробности этого? И как применять.Начинать читать отсюда: https://docs.microsoft.com/en-us/windows-server/storage/stor...
Если в двух словах, то это применяется для организации гиперковергентного программно определяемого стораджа.
Есть редакции для Hyper-V / System Center и аппаратное применение в рамках Storage Server для современных хранилок с RDMA.
Продолжать тут: https://docs.microsoft.com/en-us/windows-server/storage/file...
В частности Transparent Failover заменяет DFS для создания кластерной отказоустойчиво шары.
https://docs.microsoft.com/en-us/windows-server/failover-clu...
Кроме того никуда не делся Scale-Out File Server для реализации конвергентных хранилок, собственных и от вендоров железа в рамках Storage Server. Это не то же самое, что кластерная шара.Важно понимать, что DFS и SMB - это теплое и мягкое. DFS - набор открытых протоколов от MS для осуществления файловой репликации поверх старого SMB1, потому что старый SMB не имел никакой отказоустойчивости. DFS сейчас имеет сейчас еще и другую реализацию. Старый FRS уже 10 лет как заменили на DFRS и эта штука используется не для отказоустойчивости, а для задач репликации. Это другое. Вообще DFS это высокоуровневый сервис поверх SMB и много чего еще, а не часть протокола.
> Интересно как это выкинуть dfs в географически распределенных системах.
А чем она у вас там занимается, ваша система? Если у вас шара для совместного использования реальными пользователями, то для этого уже 10 лет как используют WebDAV. В чем смысл такой геораспределения шары, если объектами у вас там являются документы? Опять же автономные копии кэш и синхронизация под WebDAV-каталоги работает лучше чем c DFS.
Если у вас виртуализация и у вас там диски, то DFS такое не тянет по определению. Никакие БД или данные приложений вы так не подключите. Кроме того работа с такой шарой - одно мучение, ведь реальной отказоусточивости нет, а все траблы от мультимастер репликации присутствуют. Даже перемещаемые профили пользователей уехали давно с DFS на кластерные шары/Scale-Out/Storage Spaces.
Дальше всякой мелочевки DFS (каталог с несколькими файликами, типа SYSVOL), которой не нужна ни точность точность ни высокая доступность, и которая готова балансироваться и "геораспределяться" DNS (LOL), её использовать не получится.Опять же, зачем городить репликацию между файлами в каталоге на нескольких серверах, если можно собрать их в кластер и сделать отказоусточивую быструю шару. Географически распределенная система в этом случае предполагает гиперкластеризацию с регионами (если речь о виртуализации и данных приложений и БД). Администрирующий кластер у вас управляет другими отказоустойчивыми кластерами и перемещает приложения, виртуалки и данные между кластерами и между регионами. Это как раз достигается путем сочетания RDMA и S2D. При этом наличие конвергентной хранилки никто не отменял. Поверх этого вы уже можете строить любые кластерный шары или отдать один из серверов под Scale-Out. DFS в этом случае еще на уровень выше. Это когда у вас есть 2 шары в разных регионах и вам нужно файлики реплицировать между кластерными шарами... но зачем для этого использовать DFS?! Есть 1001 способ сделать это эффективнее, хотя бы лишь потому что:
- реализация SMB в венде находится в ядре, а DFS - это служба в юзерспейсе.
- DFS работает с полными правами NT ACL и обязана реплицировать и рассчитывать метаданные, SMB работает на низком уровне.
Ссылки то я и сам нагуглить могу. Интересовало описание живого опыта. Но после этого комментария много прояснилось:
> DFS сейчас имеет сейчас еще и другую реализацию. Старый FRS уже 10 лет как заменили на DFRS и эта штука используется не для отказоустойчивости, а для задач репликации.
> Если у вас шара для совместного использования реальными пользователями, то для этого уже 10 лет как используют WebDAV. В чем смысл такой геораспределения шары, если объектами у вас там являются документы? Опять же автономные копии кэш и синхронизация под WebDAV-каталоги работает лучше чем c DFS.This. Основное интересуемое во всем этом ACL. Ну и отказоустойчивое хранилище.
Так эта ядерная реализации реализует доступ к файлам или жуткого монстра со всякими активными директориями и прочей жутью?
Доступ к файлам.Жуткий монстр уже есть, называется Samba 4. Когда реализация SMB переезжает в ядро жуткий монстр начинает использовать ядерную реализацию вместо собственной юзерспейсной.
Опять Microsoft, а давайте засунем дырявый SMB прямо в ядро, а то некоторые сразу удаляют Samba, а так нельзя!
ОТЕись Microsoft
SMB последних версий значительно лучше и проще NFS
пусть делают свой SMB дальше, но в ядро не надо лезть....
Так в ядро лезет все кому не лень.
Причём, как говоришь, что толсто, так сразу в ответ "всё модульно, можно как хочешь скомпилять".
Ну вот компиляй без этого, если не нравится.
Мало вероятно, что самбу включат в ядро, не так много людей её использует на серваках(наверное). Ответ данному господину от сообщества(логичный) - Вы, там у себя в микрософтах, как напишите реализацию нфс-а в ядре... так и мы подтянемся.
Не ну ты че, это же другое.
Собственно единственное настоящее преимущество винды - что ведро отдельно, дрова отдельно, сервисы отдельно.
ага, еще скажи GUI отдельно
> ага, еще скажи GUI отдельноА оно в последних версиях не стало там более отдельно?
Очередная ненужная хрень в ядро.
Ну дык, мразесофт же. Лицемеры корпорасты, у нас в ядре нет nfs а у вас сасамба должна быть.
Ядро скоро лопнет
Смотри чтобы у тебя через дырень остатки мозгов не вытекли.Хотя там и так уже ничего не осталось.
А ты запусти сборку и отойди.
С другой стороны че удивляться, ретрограды и смузибои возвращаются назад в прошлое во времена реального режима запихивая все в привелигированный режим ядра, со всеми вытекающими от сюда... любая софтина может положить ядро
KTLS тот же
И да, больных на голову экспертов впопеннета почему-то вовсе не волнует тот факт, что натуральная юниксовая nfs изначально везде и всюду была задумана и реализована - ну надо же, кто бы мог подумать - в ядре.А единственная попытка очумелых ручек сделать переносимую неядерную реализацию - ganesha-nfs - родила только чудовище со слоновьей головой. Мертвенькое от рождения (потому что религиозные сказки индусов сказками, а в реальности пересадка головы пока и в пределах одного вида только на мышах работает, и то ненадежно)
P.S. но интересно, сколько претензий по замене colour на color родит это предложение. Платиновый спонсор ведь, а не какие-то русские.
То что задумано ядерным, ок, вопросов нет, но вот то что задумано как пользовательским нафиг тащить в ядро?
TLS тот же, это прикладной протокол работающий поверх ядерного TCP/IP, но теперь прикладные протоколы уже в ядре..А что дальше? HTTP? ESMTP? IMAP? XMPP? IRC? И еще тысячу других...
От SSL в ядре я бы не отказался, кстати. Чтобы можно было просто указать, что вот этот порт под SSL, а за портом уже прикладной сервер получал расшифрованный трафик прямо в широко открытый порт.
В теории и HTTP в ядре круто, самый активно дергаемый протокол пользователем, а чем не реализовать его в ядре?Но по такой же логике в ядро можно впихнуть все что угодно(((
> В теории и HTTP в ядре круто, самый активно дергаемый протокол пользователем,
> а чем не реализовать его в ядре?accept_http фильтры в freebsd существуют 20 лет.
К сожалению, по очевидным причинам, пользы от них в нынешнем мире - никакой.
> Но по такой же логике в ядро можно впихнуть все что угодно(((
можно. Если ты платиновый спонсор. Если просто ntfs запилил (которая уже есть но нерабочая) - то не очень легко.
Знаю... у гугла в его версии линукса HTTP ядерный... такие дела... лол
Ну так это ж он нам нешифрованный http попереломал до полной неработоспособности. А себе пакостить не собирается, у него-то работает.
Гугль с Микрософт сговорились, что ли?HTTP.sys supports the following features:
Windows Authentication
Port sharing
HTTPS with SNI
HTTP/2 over TLS (Windows 10 or later)
Direct file transmission
Response caching
WebSockets (Windows 8 or later)
это вообще-то модуль для asp.net, а не то что ты подумал.
Ну может http.sys и для asp.net модуль, но при этом он модуль ядра, в просторечии "драйвер". По крайней мере был, когда я без httpapi.dll на IOCTL делал на нём сервер для статики. Обладатели Десяточки могут уточнить подсистему, глянув заголовок файла.
> От SSL в ядре я бы не отказался, кстати. Чтобы можно было
> просто указать, что вот этот порт под SSL, а за портомktls, к сожалению, на несколько более низком уровне. Так легко и просто не получится - это для пейсбука делали, не для тебя.
Ну в смысле, для него надо расширение openssl/gnutls (их, вроде, и было), а апи останется где был, без него не обойтись.
Ну то есть на "задумки" давно мертвой sun мы будем молиться, а ничего полезного (кто в здравом уме сейчас вообще пользуется nfs для мало-мальски серьезных задач?) нини?Де факто smb победил - это сегодня стандарт и самый эффективный способ раздачи файлов по сети, полностью платформеннонезависимый, ничего лучше не придумали и вряд ли получится (потому что сан сдохла, про novell уже и забыли все, а второй microsoft у нас тоже не будет).
Логично его и иметь в наиболее оптимальном и эффективном виде, а не таскать тот же rdma через юзерлэнд - ни безопасности, ни скорости, ни простоты коду это не прибавит.
ktls если что - тоже ни разу не прикладной протокол. Это сессия. С тем же успехом можно плакать что tcp и udp в ядре, а ведь хватило бы всем и навсегда raw sockets.
(в принципе, я был бы рад если бы всякие sctp полетели из ядра в помойку)Я, конечно, отчасти порадуюсь, если затея не выгорит, поскольку мне кажутся изрядно плачевными перспективы самой самбы в не столь отдаленном будущем, если у нее появится такой конкурент. Там и так остро не хватает рук и желания делать хорошо (я там лазил в код, как раз недавно... бррр... то есть видно что пытались делать хорошо и на перспективу, но рук и времени каждый раз чуть-чуть не хватило, слишком уж огромен комбайн и противоречивы требования "заказчиков" [тех самых, sponsored by...]) - а если ключевые разработчики еще и начнут пилить линукс-only вариант...
Но она скорее всего выгорит - никаких "порежьте помельче и перепошлите" платиновым спонсорам, пожалуй, не предъявят. А отсутствие исходников в lkml не даст возможности любителям "colour" в должной мере проявить фантазию - это ж не письмо в ответ процитировать, снабдив придирками, это надо куда-то клонировать, смотреть, пул-реквест делать...
Да и прислали сразу кому надо. MS, не лохи чай.
NFS мертв это факт с его 1% пользователей, SMB доминирует ибо винда абсолютный лидер на рынке ПКНичего плохого в SMB в ядре я тоже не вижу, проблема в другом что ядро начинают тащить все подряд
> NFS мертв это факт с его 1% пользователей, SMB доминирует ибо винда
> абсолютный лидер на рынке ПКлидер добр, у лидера net use _сам_ разбирается - smb сервер на той стороне, или nfs. Сюрпрайз.
С серверной частью добра все плохо, есть корявая 3d-party userland реализация (все руки не дойдут, но там разработчик мертв, щастье вряд ли возможно) и разной степени недоделки в ядре (nfs4 толком не работает, 3 с некоторыми "особенностями" только в серверных версиях более-менее, причем не ниже 16, про кластеры и параллельный доступ я уж молчу - там с обычной 4 и то не айс)
> Ничего плохого в SMB в ядре я тоже не вижу, проблема в другом что ядро начинают тащить все
> подрядну вот нет. Подождем, конечно, 5.15, но вот увидим ли мы там ntfs3 - ой не факт.
(_год_ монотонной е..ли!)
Тяжело читать... это что ПРОМТ?
Всё в порядке, это поток сознания. Он такой.
> Тяжело читать... это что ПРОМТ?тяжело читать, потому что мозг надо использовать для понимания буковок? Понимаю, понимаю, ну ты не читай, это для умных пишется.
>>> NFS мертв...Чуть не поперхнулся. С ним по производительности на моём железе только iSCSI мог тягаться. SMB же проигрывает любому конкурирующему протоколу.
Да. Но при этом SMB все же действительно на 99% файлопомоек вертится.
Не путай TLS с VPN-омTLS шифрует содержимое IP-пакета
VPN шифрует сам IP-пакет
> Де факто smb победилЭто слишком оптимистично.
Нет, де-факто победил HTTP и проприетарные протоколы поверх него, типа дропбокса или гугл-драйва.
ты хочешь сказать, там есть что-то кроме вареза и прона?!Проблема хететепе - что он чудовищно неэффективен, поскольку ни разу не для разделяемого доступа к файликам был изобретен.
Варианты порезать все в мелкую лапшу и назвать это модным "object storage" - пригодны только для хранения еще более бесполезного мусора чем варез и прон.
> ты хочешь сказать, там есть что-то кроме вареза и прона?!
> Проблема хететепе - что он чудовищно неэффективен, поскольку ни разу не для
> разделяемого доступа к файликам был изобретен.Для прона давно изобретен и прекрасно используется RTSP. Так что мимо.
Не всем же наслаждаться именно онлайн-вуайеризмом, как ты.Некоторые любят вечерком перед... пересматривать избранные места. Вот тут им и пригождается гуглодрайв.
избранные места в порнушке? ну ты извращенец.
> де-факто победил HTTP и проприетарные протоколы поверх него, типа дропбокса или гугл-драйваСогласен, но где-то ещё трепыхается и открытый протокол WebDAV, жаль что мало где.
Я таки надеюсь что ты сейчас расскажеш как для smb3 настроить posix и вменяемые права на файлы?
>А что дальше? HTTP? ESMTP? IMAP? XMPP? IRC? И еще тысячу других...WebSocket, Social API
> но вот то что задумано как пользовательским нафиг тащить в ядро?Вы о чем вообще? С каких пор SMB был задуман как пользовательский? Что srv.sys (smb1), что srv2.sys (smb2+) - всё драйверы.
То, что Samba решила реализовать половину венды разных версий в одном проекте, - это сексуальные трудности разработчиков Samba.SMB должен быть в ядре, хотя бы потому что его современные версии (3.х) должны работать с дисковыми драйверами ядра блочного уровня, и с сетевыми адаптерами. Народ диски диски напрямую расшаривает по сети без прогона через проц силами периферии (RDMA), а на опеннете комментаторы вещают о "пользовательских" протоколах. А сам RDMA по вашему где и насколько он пользовательский? А когда я хочу взять 2 диска с 4-х узлового кластера, соединенных 40-гигабитными адаптерами и построить отказоустойчивый сетевой сторадж, это тоже "пользовательские" протоколы.
Тут в треде перепись необразованных людей, которые на полном серьезе думают, что SMB - это протокол для папочек в сетевом окружении, а Samba 4 - убийца AD. Пришла новость, что SMB наконец-то появится в ядре, так они думают всякую дурь и пишут всякую дичь про пользовательские протоколы, и чему там в ядре место, когда, на-минуточку, современная версия NFS практически имеет паритет с SMB по функционалу...
Опять же пользователям Линуксов это сложно понять, потому что в Linux и NFS работает посредственно.Так что всё правильно делают. Проблема отсутствия вменяемого сетевого стораджа в линуксе, но зато присутствия 1001 бесполезной ФС - это как раз проблема ядра. Его и надо фиксить.
> А единственная попытка очумелых ручек сделать
> переносимую неядерную реализацию - ganesha-nfsНадо же, unfs3.sf.net мне приснился, наверное.
кому интересны васянские хеловроты?
и да, сравни свой хеловрот вот с этим: http://citi.umich.edu/projects/nfsv4/windows/readme.html
(но нет, я не пробовал его собирать, все руки не дойдут. Один хрен, в общем-то, низачем не нужно.)
Собирают Checked Build - значит это бета, а не релиз.
какой релиз нафиг - оно мертвое десять лет как. Написали, защитили своих постдоков, и пошли в microsoft индусам карри подносить.Но список подвигов - внушаить. Даже если на практике окажется что оно не совсем работает.
(на фоне совсем неработающей ganesha в каждой ср-ной бубунте)
NFS не вся в ядре, не все её подсистемы.
Линуксопроблема. Кстати, поэтому оно и тупит на линуксе в сравнении с той же фряхой, например.
Интересно, хотя бы один здравомыслящий человек станет юзать ЭТО (если, конечно, какой-нибудь Canonical не [s]позаботится[/s] подложит свинью, и не сделает, чтобы это добро собиралось и загружалось по дефолту)
А ничего, что NFS точно так же в ядре реализован?
А они не знают зачем он, и считают, что им не пользуются.
> А они не знают зачем он, и считают, что им не пользуются.нет, они им и на самом деле не пользуются. Это надо сервер настроить, откуда у них...
mount -t cifs, с ближайшей винды. Ну или davfs, с облачков мэйлру.
Умеющих в nfs, да еще чтоб более-менее безопасно, а не "rootsquash, а я не при делах" - единицы. Их даже меньше, чем умеющих (умеющих, а не serverfault, ctrl-c/ctrl-v) самбу.
Немодное умение, да и бесполезное по большей части.
А что вебдав на майлрушечке заработал? Не надо только давать ссылку на их потухший мануал - так как там написано давно не работает.
А что, сломался?! (суматошно переключает страничку мониторинга) а, нет, ложный шухер.
Как работало, так и работает. Извините за немодный и несовременный fstab:https://webdav.mail.ru &n... rw,_netdev,dir_mode=0777,file_mode=0666 0 0
(только это teambox, он немного того, небесплатен)
Мануал там был, помнится, для уже почти совсем окончательно готовых любителей дрисктопов. "нажмите кнопку мыши туда и вон туда".. разумеется, в единственно-правильном гоме на единственоправильной бубунточке или что там у нее было единственноправильным. Гомики опять передвинули менюшечки и окошечки и ты, бедолажка, не можешь найти, куда? Мэйлру очень скорбит.
Особенно забавно было - что для макоси и винды он был дублирован командами cli, а пользователям уже почти готового дрисктопа не подфартило.
видимо, предполагалось, что дрисктопцам не поможет, а умеющим пользовать линукс как юникс незачем, они и так знают.
P.S. локи не работают. В смысле, они в davfs2 не работают, а не в одной мэйлрушечке.
Не точно так же. Ты преувеличиваешь.
Самбу в принципе надо выпиливать. Не особо быстрый, не особо надёжный, переусложненный, устаревший протокол, единственное "достоинство" которого это интеграция с мастдаем.
У тебя и тесты есть сравнения смб3 вс нфс со всеми наворотами?
венда умеет нфс со всеми наворотами?!
Ну тупи. Имелось в виду вин с смб3 против лин с нфс. Везде все возможности протоколов использованы по максимуму.
Есть тесты или нет?
>не особо надёжный, переусложненный, устаревший протоколЭто вы про 1-ю версию говорите или 2-ю ?
Так извините,Хр и Виста уже того,непотдерживаемые.
Сейчас 3 версия протокола-а она позволяет кластеризацию и отказоустойчивость,перераспределение нагрузки,шифрование,версирование файлов (файловая опция) и т.д .В общем https://docs.microsoft.com/en-US/troubleshoot/windows-server...
просвещайтесь,единственный недостаток- это заточенность именно под винду,т.е протокол не кросплатформенный.
Так то одна контора занимающаяся виртуализацией хвалилась о написании своей версии смб. Работающей гораздо быстрее стандартной линуховой. За прошедшие пяток лет они часть смб3 сделали. Так что насчёт не кроссплатформенности я бы не горячился.
>Так что насчёт не кроссплатформенности я бы не горячилсяТам слишком труднопортируемые технологии используеться-для обменна файлами это может и не нужно,но есть допустим запуск повершелла.Своя модель бинарного протокола безопасности,свой ACL и т.д.
А самба уже стала многопоточной или всё ещё однопоточная?
> А самба уже стала многопоточной или всё ещё однопоточнаМногопоточность эксперементальная фича,нужно собирать из исходников.Правда можно сделать кластер и на базе него организовать многопоточность, но тогда в большенстве случаев проще настроить люстру и плагин к ней smb.....
1. .NET for Linux
2. Hyper-V for Linux
3. CBL-Mariner
4. Kernel Samba
...
10. Microsoft Linux Server Enterprise Edition
Чо ты ржошь, конь? А прикинь это до твоего сервака доедет?!
> Чо ты ржошь, конь? А прикинь это до твоего сервака доедет?!Во-первых, на моих серваках давно Дебиан, этого пшена там даром не надь.
В-нулевых, кто вам сказал, что я шучу? Это, имхо, довольно очевидный и довольно реалистичный план. Давно пора, прямо скажем.
> Чо ты ржошь, конь? А прикинь это до твоего сервака доедет?!А что плохого?
Не смешно. Боже упаси!
Если будет работать лучше - почему нет? Только по умолчанию не включать.
Но это все сказка. Так не бывает. Только в ядро пристроят, как в самбвх и ко все к этой хрени прибьют шурупами и все - досвиданья.
20 лет ждал, и вот уже в двух шагах от груды сказочных богаств
Бог подаст.
Хитрый шанс.
Потому так любит зритель этот дивный жанр
Технологии придуманные Майкрософ нам не нужны!
ExFAT на выход? Флэшки не нужны? А ну еще древний FAT тоже, он же мелкими придуман
> ExFAT на выход? Флэшки не нужны? А ну еще древний FAT тоже,
> он же мелкими придуманконечно, у л@...х есть же ж б-жественная f2fs. Она правда на самом-то деле не портит только флэшки от сасунг, причем - в телефонах сасунг, а не любые. Но они истово верующие, их это не остановит.
Как и то что кроме их локалхоста эту флэшку ни на чем не прочитать.
У меня ext2 уже лет 10 на флешке и до сих пор не испортила её.
УМВР- синдром. Мало ли что у тебя и 98 винда небось стоит, которую никто не трогал и она работает.
Правильно приготовленная ext2, в принципе, не самый худший (хотя и неэффективный) выбор для флэшки. Только вот я сомневаюсь что он ее умеет правильно готовить, особенно с учетом десять лет вжопыта. То есть он ее начал использовать тогда, когда этого делать было вообще нельзя ни для чего.Ну и разумеется, васяну с локалхостом низачем не нужно чтобы эта флэшка читалась чем-то кроме его локалхоста. Все равно ни сам васян, ни его файлы совершенно никому нахрен не сдались.
А некоторым еще interoperability подавай, зажрались, продали васяна с потрохами корпорациям (зла!)
Ващет, я речь вёл про то, что линуксовая ФС флешки не портит. А ты сюда локалхосты приплёл к чему-то.
А разве кто-то утверждал что портит?
Ну я утверждаю. То есть ей все равно что портить, hdd тоже можно. Раз он использует ext2 с 2010го - там было минимум две истории с "massive filesystem corruption" (и еще одна в 2005м). Причем прикол в том, что их быстренько-поправили, упавшим не считать, в ext4, а вот сбэкпортировать в true ext2 (с которой они были общие) все как-то руки не доходили, и, по-моему, так и не дошли вообще. Поскольку гугель и так у себя попатчил еще в 2006м, а остальные перетопчутся.А читать ext2 драйвером ext4 в 2010м еще было не принято, он и сам-то только-только выкарабкивался из экспериментальных версий.
потому что прекрасно портит, и не только флэшки. Но ты за пределы локалхоста не выходи, и у тебя все будет хорошо.
У меня USB-флэшка Mirex с F2FS и она не портится.
Держи нас в курсе.
У кендузятника поха подгорело от мысли. что Виндовс не нужен.
Не "предложена", а уже смёрджена в 5.13.И то что её не рандомный анонимус, а Samsung пилит, как-то не упомянуто.
И Стив Френч только сделал пулл, а код написал Namjae Jeon.
Так а какая, в общем разница. Линусу (ну или Грегу или кто там мейнтейнер этой подсистемы), нужно чтобы у кода был сопровождающий. Стив заявился сопровождающим. Код рабочий и общим правилам удовлетворяет, проект выглядит как кому-то нужный, сопровождающий заявился - ну ОК, замерджили.
Ты еще скажи что внимательно весь этот немаленький код прочитал и проверил правописание комментариев, как масса васянов это делали с ntfs3.
Кстати, да, вот что значит от кого надо PR!2021-08-30 0:32 Steve French [this message]
2021-08-31 16:41 ` pr-tracker-bot
(has been merged into torvalds/linux.git)И никаких требований мамой поклясьтся, что будет, гад, майнтейнить, и никаких предложений заменить color на colour и наоборот. И вообще НОЛЬ комментариев.
Код идеален!
Сколько негатива. Народ реально не шарит, что такое SMB и насколько это реально классная штука? Да, она ахрисложная. Но в итоге Samba помогает нам плавно уходить от венды.
PS: Всё жду, когда в линуксе появятся нормальные ACL, как (или лучше чем) в винде.
Вот тебе ещё один в linux уже есть нормальные ACL, а про то что ты называешь нормальным даже Эндрю Триджелл сказал, что - "Никто не знает как работают Windows ACL"
я знаю.
если не наворачивать в три слоя, то работают хорошо, делают именно то что заявлено.
> PS: Всё жду, когда в линуксе появятся нормальные ACL, как (или лучшеждите, ждите.
А пока и posix acl's через сосамбу без стакана не пробросить.
Кстати, напомните мне, как там с поддержкой unix extensions?От винды они ушли, ага. К винде и придете. Только шва...нахаляву. Поэтому все глючит и тормозит.
> А пока и posix acl's через сосамбу без стакана не пробросить.Ставте Novell eDirectory главныи Ldap и проблем практически не будет.
(Понимаю что NSS фичами по сравнению с Btrfs не обладает,но проблем с правами доступа там тоже не было,лучшая как я считаю реализация Acl.Чего она не понравилась разрабам ядра не понятно....)
простите, а нахрена мне костыль и подпорки от фирмы-трижды банкрота, если у меня и так проблем нет?
(я уж молчу что вы и проблему не поняли, и не имеете ни малейшего представления о ее решениях, ldap тут вообще ни с какого бока, он другую родовую проблему линуксячьих поделок решает)> Чего она не понравилась разрабам ядра не понятно..
тем что новел - трижды банкрот, например.
> (я уж молчу что вы и проблему не поняли, и не имеетеПросто у новеловского лдап есть схема с внешним Acl,это конечно костыль,но костыль работающий.Похожея схема была в самбе3 с схемой внешней Бд с правами Acl (эмуляция виндовых прав доступа), но скорость доступа увы,невелика.
>трижды банкрот, например.Не знал что они 3 _ды банкроты,но опыт сетевых фс у них был.По удобству Acl нечего близкого до сих пор нет,просмотрите документацию на эту фс,единственная существенная недостача по нынешним временам что нет контрольной суммы для данных.
С COW для нагруженной сетевой фс не так все одназначно,красные не зря за XFS борються,хотя и собираються приделать эту возможность как опцию.
да не в схеме же проблема, проблема как ее до fs донести чтоб ничего при этом не сломалось, рассчитанного на "07777". Это одной самбой не победить.Смеялись когда-то над виндузятниками, у которых все сломалось при переходе с 95 на NT ? Ну вот, теперь их очередь. Нинавижю.
примерно там же смеялись над UUID в mountvol вместо /dev/hda в fstab. Можно посмотреть в любой современный fstab теперь и внезапно увидеть UUIDы
> примерно там же смеялись над UUID в mountvol вместо /dev/hda в fstab.
> Можно посмотреть в любой современный fstab теперь и внезапно увидеть UUIDыНу тупизна в очередной раз победила разум, дальше -то что?
На тех серверах, которые я для себя настраиваю - никаких uuid'ов нет.
пример systemd заразителен. Засунуть свою поделку во все щели, а затем диктовать свои хотелки.
Им мало khttpd?
хочу nginx-unit в ядре. без шуток.
Может тогда проще какой баре-металл собрать с нджинксом? Ведь там котиков не надо, не?Наоборот: из ядра надо вытащить вообще всё. И отправить уровнем ниже. Надо эффективное взаимодействие служб? Запускать как один процесс. О чём это я?! Ведь это уже давно всё есть.
Эффективные способы коммуникации между ядром и юзерспейсом пилить надо, на манер io_uring, но лучше ещё эффективнее. Например FUSE с зирокопи какой-нибудь
Пилите. Адрес, куда присылать пулреквесты - там по ссылке скопипастите.
Совсем уже чекнулись. Такими темпами скоро mysql встроят прямо в ядро вместе с php.
Наконец-то на линуксе просто чтобы расшарить по сети файл не придётся поднимать целую локальную актив директори с днс-сервером. Двадцать лет пролетели незаметно.
На линуксе двадцать лет чтобы "просто расшарить по сети файл" совместимым с другими операционными системами способом - не нужна была никакая active directory с dns сервером впридачу.Внезапно, для работы samba это все вовсе необязательно.
Неосиляторы такие неосиляторы...
А вот in-kernel реализация пригодится в первую очередь тем, у кого все это и так уже есть. Потому что только у них есть и нагрузки, достаточные чтобы эффект оказался стоящим всего геморроя с пиханием частей самбы в ядро.
> "просто расшарить по сети файл" - не нужна была никакая active directoryщас пойдут сказки про вебдав, ssh, однострочные http-серверы на баш, ftp не умеющие в безопасность или нфс с копро-архитектурой? Никакого колхоза не забыл?
> Внезапно, для работы samba это все вовсе необязательно.
Ага, обязателен только надмозг-конфиг на несколько экранов, разбросанный по пятку разных файлов. Помню, помню.
Все ждали четвёртой версии с модульностью, чтобы winbind стал менее упоротым и т.д., но всех налюбили и сделали за кой то чёрт весь приоритет на AD-контроллер. Как будто без этой бутылки невозможно было smb3 добавить.
>> "просто расшарить по сети файл" - не нужна была никакая active directory
> щас пойдут сказки про вебдав, ssh, однострочные http-серверы на баш, ftp ненет, чувак, все это - обеспечивала самба. Версии 3.0
Причем - из коробки.>> Внезапно, для работы samba это все вовсе необязательно.
> Ага, обязателен только надмозг-конфиг на несколько экранов, разбросанный по пятку разныхснова нет. Достаточно принимать вовремя таблеточки (нет, упорина ты нажрался зря), и галлюцинации как рукой снимает.
grep -Ev '^[;#]|^ *$' /etc/samba/smb.conf|wc -l
23И там большую часть можно было не трогать.
< ;[homes]
< ; comment = Home Directories
< ; browseable = no
---
> [homes]
> comment = Home Directories
> browseable = yes199c200
< ; read only = yes
---
> read only = noвот по сути все различия с дистрибутивным. Где половина строк закомментарена, а вторую половину лучше самому выпилить (нам совершенно не нужно давать пользователям возможность запускать удаленно passwd и прочие чудеса для альтернативно-одаренных любителей дрисктопа, которых там понавключали)
Я понимаю, линукс икс-перту с попеннета это очень, очень сложно.
То ли дело, действительно, в винде - правой кнопкой мышы тык, хачю-хачю-хачю! И вылазит полезный и нужный wizard который тут же делает неведомую х-ню, которую ты потом не знаешь как найти и выключить.
> Все ждали четвёртой версии с модульностью, чтобы winbind стал менее упоротым и
нет, не все ждали. Я вот спокойно пользовался третьей и (там где она еще жива) продолжаю.
Строчек в конфиге чуть больше, но тех что требуется раскомментировать или изменить по прежнему нет и десятка. Особенно если тебе "dns нинужна" и ты гордо smbclient //127.0.0.1 запускаешь. Да, можно и так.
> т.д., но всех налюбили и сделали за кой то чёрт весь приоритет на AD-контроллер. Как будто без
> этой бутылки невозможно было smb3Полноценно - невозможно. Он на ad и керберос намертво прибит.
Так ли уж нужен нам был smb3 - вопрос отдельный. По-моему больше была нужна нормальная поддержка posix семантики и может мапинг Acl'ей без необходимости держать отдельные перпендикулярные, но пипл хотел "каквенда затобисплатна" - пипл получил.
> снова нет. Достаточно принимать вовремя таблеточки (нет, упорина ты нажрался зря)
> И там большую часть можно было не трогать.Воу. Что, и charset уже можно не шаманить? Помнится были проблемы с закорючками.
И min protocol= SMB2 не нада? Ванакрай не напрягает? krb5.conf и pam.d тоже сами себя не заполнят (хотя в бубунте может уже дошли до этого, не интересовался)> read only = yes
А ну яснопонятно. Вы ещё небось у себя NTLMv2 до сих пор используете. Как перейдёте с Windows 98 наберите. У нас вот тупо запрещены соединения от клиентов без проверки подлинности. Потому что в инфре ты либо валидирован, либо ты чужеродная субстанция. Zero-Trust во все поля.
> То ли дело, действительно, в винде - правой кнопкой мышы тык, хачю-хачю-хачю!
> И вылазит полезный и нужный wizard который тут же делает неведомуюВот это кстати афигенно. В одном ЕДИНСТВЕННОМ меню для компа в домене я за 10 секунд настраиваю все права доступа для групп. И не нужно мне думать над тем как соединить пол десятка разных модулей вместе и гадать, толи памд глючит, толи idmap опять слетели, толи winbind опять сегфолтнулся.
Чтобы сделать то же самое на самбе (без копипасты готовых конфигов) мне понадобится бутылка пива и DND на телефоне как минимум.> Я вот спокойно пользовался третьей и (там где она еще жива) продолжаю.
Ну я бы может тоже, если бы туда smbv3 завезли. Но без неё как-то грустно.
P.S. Согласен, что кернел-модуль никак не решает проблемы интеграции с керберосом и АД-шными группами. Просто это в своё время для меня была прям боль. А вот для работы всяких SAN кернел модуль будет отличным решением.
Я в ядро зачем впиливать файл сервер?Ну, кроме смеха и развлечения, зачем чужеродное смешивать.
> Я в ядро зачем впиливать файл сервер?Это _Модуль_ или по-вашему "драйвер". Они крепятся сбоку и в них нет ничего плохого.
Почему близко к ядру тоже понятно: Производительность. SMB это не чтобы в общаге кунтерстрайк расшаривать. Сейчас SMB это решение номер один для подсоединения СХД, вместо устаревших AoE, iSCSI или мертворождённого FCoE.
Зато сейчас в линуксе очч удобно, либо править каждый раз конфиг со всякими шизанутыми взаимоисключащими параграфами менящимися от версии к версии. А если делать через UI поднимаются всякие webdav и httpd апачи...
Самба в ядре не отменяет шизанутого самба конфига с шизанутыми параметрами который нужно править.
Все программы надо засунуть в ядро для повышения эффективности. Начнем с тетриса
рецепт для проталкивания любой дичи в ядро:1. берём 10 феминисток;
2. добавляем дичь;
3. делаем вид что феминистки написали эту дичь;
4. "предлагаем" ввести эту дичь в ядро;
5. если Торвальдс не соглашается - обвиняем его в связи с малолетками и заменяем на Балмера
6. дичь в ядре.
Балмер дичи не допустил бы.
феминисток мало
без нестандартных не прокатит
10 феминистов;
Ну наконец-то конкурент eBPF подтянулся!)) Я прям чой-та заскучал на последней неделе))
Ksmbd - я сначала подумал, что это реализация самбы, заточенная только под КДЕ...
Это чтобы DRM ограничения пользака на уровне ядра проще проводить?Иначе в ядре файловый сервер не нужен.
P.S. Microsoft - сделают быстро, плохо, только для себя. Точнее - для внутренних механизмов продаваемых решений. Не для людей затея.
Как было указано в новости - одна из областей - устройства с ограниченными ресурсами.Не знаю, какие там реально требования - но бахнуть функциональность в ядро позволяет убрать часть накладных расходов на обслуживание процесса.
> Как было указано в новости - одна из областей - устройства с
> ограниченными ресурсами.ну это ж microsoft - корпорация, зла.
Врет и не краснеет. Ну что ты собрался шарить еще с поддержкой rdma со своего adsl модема?
> Не знаю, какие там реально требования - но бахнуть функциональность в ядро
> позволяет убрать часть накладных расходов на обслуживание процесса.так вот они актуальны-то только когда ресурсы ограничены не устройством, а прожорливостью потребителя. В предположении что узкое место именно самба, а не отдача с физической fs или сетевуха-через-usb-в-soc. А для того чтоб упереться в самбу - нужна очень откормленная раздавалка.
Ей собственно демона запустить - тьфу.
Это всё полумеры. Когда уже будет ядро в ядре?...Yo dawg! I heard you like kernels, so I put a kernel into your kernel so you can panic while you panic.
> Это всё полумеры. Когда уже будет ядро в ядре?...uml вроде выпилили?
А ты все проспал. Двадцать лет.
UML не позволяет "panic while panic" (при падении он не тащит за собой host). Это несерьёзно ©
EBPF!
Это вы сейчс смеетесь. А потом у вас с вашими квантовыми компьютерами будет один вопрос - чем бы нагрузить эту квантовую хрень, что бы в доме подняьт температуру градуса на два, и что б с пользой для всех. А, вот же, давно всеми забытое развлекалово - samba, мать ее, ди-жанейро.
А ещё скринсейвер в режиме ядра будет быстрее картинки менять. Давайте скринсейвер в ядро добавим
> А ещё скринсейвер в режиме ядра будет быстрее картинки менять. Давайте скринсейвер
> в ядро добавиму тебя драйвер видеокарты и так давно в ведре. А когда-то смеялись над NT.
Хм... самодостаточное ядро, которое может похвастаться отсутствием связи с графикой, которое не выносит себе мозг юзерспейсными приблудами, которые далеко не каждому то и нужны, теперь - фтп сервер...
Юниксвеем можно подтереться. Планомерное выпиливание людей которые боролись за свободу, опенсорс, безопасность и личное пространство поль-зователя в частности, теперь словно мезозойская эра... когда то было.
Что ты несёшь. В ядре линукс всегда была графика. Открой уже исходники хотя бы раз в жизни и посмотри:
https://github.com/torvalds/linux/tree/master/drivers/gpu/drm
Это управление графическим контроллером, а не графика. Графика это Mesa, Xorg и win32k.sys.
А ну если речь про рендеринг, тогда да. Я-то думал про графику. Я не очень слежу за развитием Windows Core, но думаю что там лет через десять тоже уже можно будет только по ssh работать.
Пока насколько я видел там всё тоже самое, только с максимально отключенными свистелками. Видимо отталкивались от Safe Mode и дальше резали остальное
win32k.sys рисует графические примитивы. В NT5 можно переполнить таблицу объектов GDI, создавая их в цикле из двух процессов -- это разрушит Рабочий Стол.
Ну оно модульное же. Хотя не знаю, что бывает с самодостаточными независимыми модулями.
А можно собрать утёкшие исходники XP как модуль ядра? Там по моему есть подходящий уровень абстракции - Windows Native Api, похоже суть в том, что вызовы ядра это Native Api и есть прослойки, которые имеют свой api, и сами вызывают Native Api.
Ядро Linux будет реализовывать Native Api, потребуются разные другие прослойки и трансляторы, конечно нужно будет транслировать звук Windows > ALSA, Что-то там > DRI (если не путаю) и видимо другие правки. Некоторые вещи связанные с драйверами работать не будут, это нужно будет учесть.
Суть в том, чтобы запустить оригинальные файлы и библиотеки Windows на ядре Linux. Совместимость будет потрясающей, я думаю.
(Я ламер, не гоните...)
Native API это примерно как libc в Linux. Подсистема Windows (Win32 API) реализована в NT точно так как и WinE в Linux - обёртками вокруг "родного" интерфейса. Потому WinE не эмулятор.)
Можно. Разработчики давно помершего Lindows именно так и делали.
Столько хейта в камментах. Чую скоро будет дефолтной реализацией повсеместно.
> Столько хейта в камментах. Чую скоро будет дефолтной реализацией повсеместно.повсеместно как раз и не будет. В линoops - конечно, да. Зачем л@п4@-м вторая самба, действительно...
Лишь подтверждение что ныняшняя архитектура - туфта.
апач ещё запилить в ядро и будет щастье
2022: Для ядра Linux предложена реализация Windows API
Реализация Windows API даже для ядра Windows отсутствует. Учите матчасть.