Комментарии 38
Обращение в тех поддержку
мы составили обращение к службе сетевого обслуживания Linux,
Taking things upstream
we wrote a good summary of what we knew so far and what we supposed was happening, and reached out to the Linux networking maintainers
Список рассылки netdev — это не техподдержка.
Я бы перевёл это так:
Обращение к разработчикам
мы подытожили всё, что успели узнать, и предполагаемые причины происходящего, и обратились к сопровождающим сетевого стека Linux
«служба» подразумевает, что кто-то там что-то делает по долгу службы. Там таких нету, мейнтейнеры поддерживают подсистему в рабочем состоянии, но это не техподдержка
Кто-то в своё свободное время прочёл ваш отчёт об ошибке, сказал «ох ты ж блин», и исправил. Это не обслуживание, не надо так.
Это не служба. Более правильное название — список рассылки. Что они сделали — связались с мейнтейнерами ядра.
сопровождающему сетевой стек персоналу
Опять мимо. Мейнтейнеры — не персонал. Мейнтейнеры могут быть персоналом каких-либо огранизаций, но в ядре они просто сопровождающие/мейнтейнеры.
А как исправили-то?
Как возможно, что TCP-ошибка, которая ведет к зависанию соединений, оставалась незамеченной на протяжении 24 лет?
Я дал ответ на этот вопрос, в своей статье: habr.com/ru/sandbox/149580
(за которую даже инвайт на хабре не получил)
И если, ОС не определяла правильную последовательность пакетов. То до приложения пользовательского уровня. Дойдёт такая строка: «World !Hello »
Я сколько вижу такие опечатки — никак понять не могу, как можно умудриться их делать. Я даже с клавиатуры на смартфоне не могу случайно предложения рубить точками. И это не раз и не два, постоянно вижу эти точки посреди предложений. Как?
Форматирование сбилось. И я быстро, внёс исправления, какие увидел.
Может и заметил опечатки и ужас форматирования, после публикации. Но исправлять ничего не стал. т.к. После очередного исправления текста, (мне как новому участнику) приходится ждать дней этак 5, чтоб статью одобрил модератор.
Форматирование и опечатки, яб в норму привёл. Да, нужно было статью опубликовать. Ведь смысл статьи, не в её внешнем виде, а в том, какой смысл я старался донести.
И да) Мне тоже режет глаз «такие опечатки». Но, увы и ах. После каждого внесённого исправления статьи, ждать несколько дней проверки модератором, я не стал.
яб в норму привёл. Да, нужно было статью опубликовать. Ведь смысл статьи, не в её внешнем виде, а в том, какой смысл я старался донести.
Понимаете, когда так криво всё написано — и глаз спотыкается, и читать неудобно, и смысл ускользает. Где-то есть критическое число ошибок, после которого годная статья превращается в статью, которую неприятно читать (по содержанию, по-моему, у вас вполне годная статья, только почти в каждом предложении языковые ошибки). Так что в том, что вам не дали инвайт, можете винить, в частности, и ошибки, и опечатки.
Такие тексты и на самом деле очень сложно читать. На простое их прочтение тратится в разы больше времени, чем должно, а иногда даже не хватает сил, чтобы дочитать. Потому что прочтение каждого предложения превращается в угадывание, что же на самом деле хотел сказать автор. И если один комментарии можно просто пропустить, а другой прочитать, если количество ошибок будет меньше критического, то у статьи есть все шансы «пролететь» целиком. Вы хотели что-то сказать, но форма высказывания привела к его, высказывания, пропуску и Вы остались неуслышанным.
Да, ждать пять дней. Но, мне кажется, это должно быть стимулом для проверки до публикации. Возможно, с привлечением помощи, раз не получается сделать всё самостоятельно.
Два пробела подряд превращаются в точку на большинстве смартфонов.
У меня стойкое ощущение, что следующие фразы означали совсем иное у автора до перевода:
— «сбой прогнозирования заголовка быстрого пути»
— «попытка упростить код, удалив из него прогнозирование заголовков и связанные с ним пути файлов»
Данная оптимизация актуальна и по сей день: относительно недавняя попытка упростить код, удалив из него прогнозирование заголовков и связанные с ним пути файлов, потерпела неудачу по причине снижения производительности.
Было
² This optimization is still relevant today: a relatively recent attempt to remove the header prediction code and associated fast paths to simplify the code was reverted on performance regression grounds.
Извините, но раз взялись, то не говорите, что не сдюжили
И ещё — в оригинале не «пути файлов», а вполне “fast path”, что означает механизм упрощенной обработки пакета для более быстрой обработки
Прогнозирование заголовков — это тоже пять. Так, извините, не переводят. Хотя бы «предсказание» лучшее слово, а может и вовсе построение фразы надо переделать
— «сбой прогнозирования заголовка быстрого пути»
Тоже с коллегой соглашусь, что это не сбой предсказания, а скорее «неудачное предсказание» (по аналогии с бранч предикшн в процессорах)
У меня вопрос к знатокам. Что вообще имеется в виду в оригинале под "header prediction"?
У меня ощущение после гугления, что это про упрощённый анализ заголовков пакета для принятия решения по какому пути его пустить: slow vs fast.
И prediction здесь состоит в том, чтобы минимальными проверками угадать и значение прочих заголовков пакета.
Верно?
Если я верно понял суть, то возможно и переводить надо без слова предсказание/прогнозирование вообще. Если это не устоявшийся термин конечно.
Получится:
"header prediction code" -> "упрощённая классификация пакетов" (на быстрый путь/медленный путь)
"failed fast path’s header prediction" -> "ошибочно послали пакет по быстрому пути" (в контексте) или "ошибочная маршрутизация пакета по быстрому пути"...
Извините за тон.
Во-первых я ни разу не переводчик. Возможно я придираюсь местами.
Давайте первый переведённый абзац разберём.
we provide each developer with a writable database snapshot
мы обеспечиваем каждого разработчика перезаписываемыми снимками базы данных
Если без контекста, то перевод слова writable (перезаписываемый) верный.
Но в английском была однозначность: database snapshot with write access.
А в русском создается второе значение, где сам снимок БД перезаписывают для каждого разработчика в процессе обеспечения его этими снимками.
И мне при первом прочтении увиделось вот это искаженное значение.
These snapshots are updated daily through a pipeline that involves… step1… step2… step3
Обновление при этом происходит ежедневно в виде конвейера, который включает… step1… step2… step3
Как-то не по-русски этот "конвейер" тут. Хотя дословно слово верно переведено.
Возможно потому что часто в русском оставляют кальку "пайплайн". А может было бы ещё лучше превратить во что-нибудь вроде "последовательность шагов". Или вообще переформулировать без перевода этого слова. "Обновление состоит из этапов/шагов".
copy-on-write при переводе исчезло. Не уверен как правильно и понятно перевести.
немного непоследовательно описание данных пайплайна: "данные среды", потом "датасет" передающийся "на серверы базы данных".
.....
===================================
Давайтея попробую сам эту лямку потянуть.
Оригинал:
As part of our standard toolkit, we provide each developer at Skroutz with a writable database snapshot against which she can develop. These snapshots are updated daily through a pipeline that involves taking an LVM snapshot of production data, anonymizing the dataset by stripping all personal data, and transferring it via rsync to the development database servers. The development servers in turn use ZFS snapshots to expose a copy-on-write snapshot to each developer, with self-service tools allowing rollback or upgrades to newer snapshots.
Ваш перевод:
Здесь в Skroutz в составе нашего стандартного набора инструментов мы обеспечиваем каждого разработчика перезаписываемыми снимками базы данных, которые он использует в разработке. Обновление при этом происходит ежедневно в виде конвейера, который включает формирование LVM-снимков данных производственной среды, анонимизацию этого датасета путем удаления всей личной информации и его последующую передачу через rsync на серверы базы данных разработки. Серверы, в свою очередь, предоставляют ZFS-снимок каждому разработчику вместе с инструментами, позволяющими выполнять переход на новые снимки или делать откат к старым.
Мои правки по вашему переводу:
Здесь в Skroutz частью нашего стандартного набора инструментов является обеспечение каждого разработчика снимками базы данных с возможностью записи, которые он использует в разработке. Обновление при этом происходит ежедневно в виде пайплайна, который включает формирование LVM-снимков производственной базы данных, анонимизацию этих данных путем удаления всей личной информации и их последующую передачу через rsync на серверы базы данных разработки. Серверы, в свою очередь, предоставляют ZFS-снимок с копированием при записи каждому разработчику вместе с инструментами, позволяющими выполнять переход на новые снимки или делать откат к старым.
И всё ещё хочется это переписать, сделав предложения более простыми, без сложноподчинённых (а-ля художественный, но для технического текста):
У нас в Skroutz есть стандартный набор инструментов для разработчиков. Частью набора является личный снимок производственной базы данных с возможностью локальной записи. Обновления происходят ежедневно путём создания LVM-снимка производственной базы данных, анонимизации этих данных путем удаления личной информации, а также и их последующей передачи через rsync на серверы базы данных разработки. Серверы, в свою очередь, предоставляют каждому разработчику ZFS-снимок с копированием при записи вместе с инструментами, позволяющими выполнять переход на новые снимки или делать откат к старым.
2. Пайплайн как раз не по-русски, а значение у пайплайн — трубопровод. Конвейер — это устоявшийся термин в среде разработки и значение у него вполне себе понятное. Хотя мне изначально оно тоже не очень заходило, привык. Это программирование, тут много подобных слов и выражений, которые обывателю могут показаться странными и «не по-русски звучащими». Можете поискать по тому же поиску CI/CD-конвейер.
3. Copy-on-write исчезло, потому что болталось лишним. ZFS-снимок сам по себе подразумевает этот термин в своем техническом смысле.
4. Делается снимок среды (ее данных) — обрабатывается датасет (набор этих снимков данных) — передается на серверы. Что тут непоследовательного. Если слово датасет не нравится, просто писать данные несколько раз подряд будет совсем неуклюже, а датасет тоже домашний термин в программировании.
Отдельно по прогнозированию заголовка — это именно прогнозирование (термин очень распространенный в области ПО, погуглите на досуге), а не предсказание (из области шаманов и провидцев).
Вот ссылка www.freesoft.org/CIE/RFC/1323/17.htm
Здесь более-менее про предикшен расписано. Может это и не такое прям прогнозирование, как в моделях МО, например, но суть та же. Задается вопрос «является ли сегмент (пакет) следующим в последовательности?» Отсюда делается вывод и соответствующая обработка.
А вот еще точнее картинка faculty-web.msoe.edu/yoder/cs2911/lab1res/Lab1Example.pdf
Тут вообще вопросы отпадают.
:) Настаивать не буду. Я не технический переводчик ни разу.
По прогнозированию у меня отдельный пост есть тут в комментах.
Да, я знаю что в английском это устоялось именно так пышно называть ту однострочную упрощенную проверку пакета на то посылать ли его по быстрому пути. И возможно действительно правильно переводчику дословно и переводить.
Можете поискать по тому же поиску CI/CD-конвейер.
в моем окружении никто не говорит конвейер — это выглядит как заумь, которая может быть в формальной документации для госорганов. В народе говорят пайплайн — и все понятно. И если уж докапываться — либо конвейер и "набор данных", либо "пайплайн" и "датасет".
- Copy-on-write исчезло, потому что болталось лишним. ZFS-снимок сам по себе подразумевает этот термин в своем техническом смысле.
нет, не подразумевает. Молодец, Вы исказили смысл
Отдельно по прогнозированию заголовка — это именно прогнозирование (термин очень распространенный в области ПО, погуглите на досуге), а не предсказание (из области шаманов и провидцев).
чушь. Я уже приводил пример с branch prediction в процессорах, который ближе к топику, и переводится именно как "предсказание", а не "прогнозирование".
С остальным согласен :)
«сбой прогнозирования заголовка быстрого пути»
Если память не изменяет, то скорее всего тут имеется введу изменение заголовка TCP пакета. Т.к. когда начинается обработка TCP пакета, то первым делом в сетевом стеке определяется, как его следует обрабатывать. По «slow_path» или по «fast_path». Почти все пакеты обрабатываются по «быстрому пути». В функции tcp_rcv_established. В этой функции, решение, о том следует ли попасть в «slow_path» определяется на основании указанного времени отправки последнего пакета сервером tp->rx_opt.rcv_tsval. TP- это структура tcp соединения. Вообще, можно формировать любые пакеты tcp с любым временем (таким чтоб пакеты не отбрасывались при проверки), играться с значениями syn ack urg в пакетах. И тогда, можно увидеть далеко не "зависание соединения"
Вот бы кто-то ещё отладил похожую мистику с подвисанием соединений WireGuard. Это точно не данный баг, к сожалению, потому что там UDP. (Судя по tcpdump, пакет от клиента приходит на сервер, сервер на него отвечает, но до клиента ответ не доходит. При этом похоже, что теряются пакеты от сервера исключительно с порта WireGuard сервиса на порт WireGuard клиента — пакет отправленный ручками с другого порта сервера на тот же порт клиента доходит нормально. Перезапуск клиента через wg syncconf приводит к смене порта клиента и всё снова работает. До подвисания соединения по нему тоже успевают гигабайты набегаться, и случается это не каждую неделю, так что отлаживать сложновато.)
В inetd была бага 10 лет дающая DoS и норм :)
Припоминаю (видимо) аналогичный случай с нашей "полковой кобылой": ~10 лет назад (до докера) была своя мини-ферма для CI, где сборочные chroot-ы подтягивались/синхронизировались rsync-ом. И вот rsync иногда действительно подвешивался, то только при работе на серверах самой фермы (10G на локальном свиче). На рабочих станциях (с 1G) воспроизвести не смогли, поэтому грешили на сферу и/или свичи...
Как мы раскрыли 24-летний баг в ядре Linux