The OpenNET Project / Index page

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



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

Оглавление

В ядре Linux 6.3 всплыла проблема, приводящая к повреждению метаданных ФС XFS, opennews (??), 26-Май-23, (0) [смотреть все]

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


200. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +4 +/
Сообщение от пох. (?), 28-Май-23, 00:12 
Линукс это давно уже сборник шаманских практик а не инженерия.

Никто не знает точно как работает xfs (или любое другое большое нечто в ядре)

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

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

222. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +1 +/
Сообщение от birdie (ok), 28-Май-23, 12:49 
Баг закрыли, потому что туда посыпался спам - я не про комментарии, я про обычный email spam:

https://i.ibb.co/3Wx78Wd/spam.webp

Баг я отрыть могу, потому что есть права на kernel bugzilla:

Konstantin Ryabitsev 2020-03-04 01:33:32 UTC

> I'm making this bug private to prevent more spam from being added to it.

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

236. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от пох. (?), 28-Май-23, 17:25 
ну полно сказочки-то рассказывать. Баг не просто закрыли, страницу багзилы сделали недоступной для недопущенных к столику. Есть миллион более простых способов заблокировать спам, но был выбран именно этот - попрятать крошки под ковер.

К сожалению есть вебрахив и он всех палит.

P.S. админские навыки владельцев кернельной багзилы, конечно тоже на высоте, но что-то никто и не удивлен.

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

240. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от birdie (ok), 28-Май-23, 17:55 
> ну полно сказочки-то рассказывать. Баг не просто закрыли, страницу багзилы сделали недоступной
> для недопущенных к столику. Есть миллион более простых способов заблокировать спам,
> но был выбран именно этот - попрятать крошки под ковер.
> К сожалению есть вебрахив и он всех палит.
> P.S. админские навыки владельцев кернельной багзилы, конечно тоже на высоте, но что-то
> никто и не удивлен.

1. Bugzilla открыта для new bug reports - you're welcome
2. Reproducible test case - где?

Вместо этого "Буду обижаться, ненавидить, говорить, что де "закрыли и спрятали, гады"".

Всё, что нужно знать о фанатах Open Source.

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

243. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +2 +/
Сообщение от пох. (?), 28-Май-23, 18:22 
> Reproducible test case - где?

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

Сейчас, извини, доставать из под шкафа ту самую 2.6.13 где бага нет, собирать обратно ржавый пень3 и предлагать тебе воспроизводимый сценарий просто нет никакого смысла. Код двести раз переписали, проблема никуда не делась, только замылилась потому что современное железо чаще может ее переварить более-менее без последствий.

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

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

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

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

248. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от birdie (ok), 28-Май-23, 19:18 
>[оверквотинг удален]
> могли понять почему он иногда работает неправильно. Число патчей было еще
> вполне счетным. Но давать заднюю эти ребята были не обучены -
> ведь на их локалхосте все работало даже лучше чем до того.
> Учитывая кто и сколько времени потратил в попытках не меняя главного подкостылить
> и подпереть локальные проявления проблемы - я не очень верю в
> то, что сейчас еще можно что-то исправить.
> Для отдельных кейсов - наверное можно (сколько раз проблему объявляли исправленной -
> теперь желающие могут посмотреть сами). Вылезет у меня еще где-нибудь -
> принесу показать. Но вряд ли уже - я практически перестал использовать
> линуксы в повседневной жизни. Какой-то я давно уже антифанат этого фресофтваре.

Ждём-с.

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

302. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (-), 30-Май-23, 02:52 
> 1. Bugzilla открыта для new bug reports - you're welcome
> 2. Reproducible test case - где?
> Вместо этого "Буду обижаться, ненавидить, говорить, что де "закрыли и спрятали, гады"".
> Всё, что нужно знать о фанатах Open Source.

Пох такой себе фанат опенсорса, который назло бабушке уши отмораживает и винду ректамит. Его юниксвэй для него же и не сработал. Настолько что он рекламит винду. Так что учитывать его мнение в контексте опенсорса - лучше просто проигнорить. Хотя иногда, примерно в 5% случаев он дело говорит. Но фильтровать 95% бездарного спама или протухшей информации 10+ лет свежести утомительно и если вы не знаете его причуды - лучше совсем игнорьте. Потому что ткнув в профайл можно заметить что это эксперт по прострелу пяток под линухом. Хотите так же? Нет? Вот и не делайте как он! Это же элементарно, Ватсон :)

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

231. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от onanim (?), 28-Май-23, 16:50 
> Линукс это давно уже сборник шаманских практик а не инженерия.
> Никто не знает точно как работает xfs (или любое другое большое нечто
> в ядре)
> Собственно - 12309, баг о котором достоверно известно в какой версии его
> точно нет - так и не выявлен. Тоже похоже, вроде бы,
> произведен рефакторинг и вообще давайте закроем и запретим смердам смотреть туда.
> А то дискредитируют, гады.

12309 у меня до сих пор бывает при копировании крупных файлов, на NVMe диске, хотя раньше "решением" было "купите NVMe SSD вместо SATA SSD", а ещё раньше "решением" было "купите SSD вместо HDD"

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

233. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от birdie (ok), 28-Май-23, 17:01 
>> Линукс это давно уже сборник шаманских практик а не инженерия.
>> Никто не знает точно как работает xfs (или любое другое большое нечто
>> в ядре)
>> Собственно - 12309, баг о котором достоверно известно в какой версии его
>> точно нет - так и не выявлен. Тоже похоже, вроде бы,
>> произведен рефакторинг и вообще давайте закроем и запретим смердам смотреть туда.
>> А то дискредитируют, гады.
> 12309 у меня до сих пор бывает при копировании крупных файлов, на
> NVMe диске, хотя раньше "решением" было "купите NVMe SSD вместо SATA
> SSD", а ещё раньше "решением" было "купите SSD вместо HDD"

Версия ядра? Вывод `free`? Вывод `vmstat 1 5`?

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

284. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +1 +/
Сообщение от onanim (?), 29-Май-23, 12:51 
>[оверквотинг удален]
>>> Никто не знает точно как работает xfs (или любое другое большое нечто
>>> в ядре)
>>> Собственно - 12309, баг о котором достоверно известно в какой версии его
>>> точно нет - так и не выявлен. Тоже похоже, вроде бы,
>>> произведен рефакторинг и вообще давайте закроем и запретим смердам смотреть туда.
>>> А то дискредитируют, гады.
>> 12309 у меня до сих пор бывает при копировании крупных файлов, на
>> NVMe диске, хотя раньше "решением" было "купите NVMe SSD вместо SATA
>> SSD", а ещё раньше "решением" было "купите SSD вместо HDD"
> Версия ядра? Вывод `free`? Вывод `vmstat 1 5`?

разные дистрибутивы, разные относительно свежие LTS ядра, разные диски (SATA SSD и NVMe), оперативы от 16 до 64 гб, и везде копируешь тяжёлый файл - получаешь тормоза в гуе.

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

303. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (-), 30-Май-23, 02:56 
А ядра то надеюсь десктопные, low latency? :) Т.е. как минимум preempt_dynamic/preempt_rt. Не, это надо не только тем кто с звуком работает. Но и всем кто предпочитает отзывчивый десктоп а хотя-бы и ценой потери пары пунктов в бенчмарках.

Видите ли обычные ядра - для серверов и они bulk performance ценят выше чем латенси. А вот юзер ожидающий переключения задачи или что там еще может быть сильно иного мнения на этот счет.

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

379. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Неуклюжий танцор (?), 01-Июн-23, 21:02 
> А ядра то надеюсь десктопные, low latency? :) Т.е. как минимум preempt_dynamic/preempt_rt.
> Не, это надо не только тем кто с звуком работает. Но
> и всем кто предпочитает отзывчивый десктоп а хотя-бы и ценой потери
> пары пунктов в бенчмарках.
> Видите ли обычные ядра - для серверов и они bulk performance ценят
> выше чем латенси. А вот юзер ожидающий переключения задачи или что
> там еще может быть сильно иного мнения на этот счет.

Сколько раз пробовал ставить лоу латенси ядра - никакого эффекта нигде не ощутил, даже измеримого

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

407. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (373), 04-Июн-23, 00:20 
> Сколько раз пробовал ставить лоу латенси ядра - никакого эффекта нигде не
> ощутил, даже измеримого

Это в основном под нагрузкой ощущается. Под тяжелым IO и тому подобным. Если вы это не делаете то и разницы не будет особой.

Технически есть довольно большая разница: вырубить по линии кернела длинный синхронный сискол в середине и потом доделать, временно свалив в другую задачу, или до упора динамить всех в шедулере пока он не закруглится - для неспешного IO может занять энное время, а таск при этом uninterruptable и пусть весь мир подождет. Такая вот многозадачность - подождите пока вон те тормозное IO доделают, потом задачу переключим. Это хреново если реальное время и низкая латенси интересовали, поэтому в -RT или Dynamic Preempt ядрах разрешили переключать задачи и в случае если оно долго в сисколах отвисает, вырубая это на стороне ядра. Потому и preempt - это про возможность преемптнуть начинку ядра, если стало надо. Это не совсем халявно и теряет пару процентов производительности системы, в обмен на заметно более низкий латенси под нагрузкой.

В самых новых ядрах типа 6.2-6.3 понятие реалтайма сильно поменялось - там вообще пытаются сделать "жесткие" гарантии поведения на манер RTOS, внедряя патчи RT_LINUX. И когда это доделают оно вообще будет RTOS. Но за вот тот реалтайм уже приличная цена в виде оверхеда. Зато он гарантированный - это конечно не столько десктопам надо, там юзер накрайняк и подождет, сколько управляющим системам и эмбедовке (управляемый промкомпьбтером процесс в реальном мире ждать никого не будет, нет в реальном мире паузы). И тут мы уже постепенно сможем сказать привет QNX и VxWorks у которых иные идеи насчет реалтайма. Но тут стоит понимать что соответствие жесткому реалтайму это очень комплексное мероприятие и совсем не факт что вы СТОЛЬКО счастья хотели. Это уже в т.ч. ценой приличного оверхеда, если так надо для обеспечения гарантий.

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

381. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от пох. (?), 01-Июн-23, 21:51 
> Видите ли обычные ядра - для серверов и они bulk performance ценят
> выше чем латенси. А вот юзер ожидающий переключения задачи или что

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

Независимо от bulk performance самой этой операции.

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

408. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (414), 04-Июн-23, 00:28 
> сервер, перестающий обрабатывать запросы потому что очень занят сбросом буферов на диски
> - немного так себе сервер.

Да как тебе сказать? Если сервак протупит 500 мс с запросом по HTTP ты можешь особо и не заметить. А если твой десктоп будет дергаться по 500 мс с реакцией на мыша и клаву, беситься ты будешь неимоверно, имхо.

А вон тем, compute only которые получают батч на счет, потом цать минут его жуют и проч, вообще плюс-минус 5 секунд клина - ни о чем. А 5% перфоманса не лишние. Юзер же не смотрит на это все, оно там каким-то диспетчером очереди раскидывается, он программа, ему пофиг.

> Независимо от bulk performance самой этой операции.

Тем не менее, ряд дистров по дефолту вкатывают ядра оптимизированые на бенчи а не юзер экспериенс. А юзерам нехило понимать что UX и маркетинг с бенчами 2 большие разницы :). Туда же и космонавтов от интеля с их рекламой и фейковым TDP и нанометрами.

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

421. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от пох. (?), 05-Июн-23, 11:32 
> Да как тебе сказать? Если сервак протупит 500 мс с запросом по HTTP ты можешь особо и не
> заметить.

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

Если сервак начнет тупить внезапно и никто не вмешается - сложится сперва сервак, а потом и весь кластер.

> Тем не менее, ряд дистров по дефолту вкатывают ядра оптимизированые на бенчи а не юзер
> экспериенс.

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

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

427. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  +/
Сообщение от Аноним (-), 06-Июн-23, 00:58 
> увы, у меня не финтех переводящий ресурсы в ненужные криптозакорючки, с бесконечным
> числом инстансов в амазон, у меня олдскул бизнес.

И все же если ты мониторил когданить под нагрузкой это добро то знаешь что есть характерное распределение запросов по времени выполнения. И вопрос о том как будет выглядеть worst case.

Если HTTP серв протупит даже и секунду в хучшем варианте - 1 юзер из скадем 1 000 000 будет считать сайтик немного тормознутым. Поскольку веб и так не особо скоростной и low latency, никто особо не заметит. И можно все же bulk ядра гонять без особых предъяв - они немного маскируются неидеальностями сетей, тормознутостью сайтов и проч.

А если у тебя мыша словит клин на секунду, это уже будет конкретно бесить. Потому что от десктопа с нормальными обычными программами мы все же ожидаем какой-никакой интерактив. В идеале того уровня который QNX Demo Disk показывал, но за такое достаточно большой hit по перфомансу уже, увы. И вообще линь под такое сразу не делался и там довольно много что икается когда хочется реалтайм, цуко, в серьез, с _жесткими_ гарантиями годными для _реалтайм_ систем. Мне оно надо и я поэтому немного трекаю те грабли. И пока там есть весьма отличные от идеала аспекты, и их не все зарулили. Это и клинит прием оставшихся RT_LINUX патчей: оно имеет смысл только если гарантии будут реально работать.

> Если сервак начнет тупить внезапно и никто не вмешается - сложится сперва
> сервак, а потом и весь кластер.

Так он тупить же не по "среднему" числу RPS будет а по "хучшему времени отклика". В этом случае ничего не сложится, просто у особо невезучих юзеров время выполнения запроса будет великовато. RPS при этом в целом будет вполне ок. Но вот на десктопе такой номер не очень работает. Даже если в среднем все резво пашет но раз в час на миллион-хренадцатьпервом сисколе мышу на секунду якорит - где юзеры такой десктоп видали? Это неприятно в использовании, и возможность преемптнуть кернел чтобы другие задачи выполнить даже если чье-то IO хорошо встряло очень хорошая идея так то :)

> к сожалению это сферические бенчи в вакууме. В результате и юзерэкспириенс дерьмо,
> и сервер дерьмо. Привыкайте, в копроэкономике по другому уже не будет.

У меня были другие идеи на этот счет, я не стал прогибаться под изменчивый мир и прогнул его под себя. И теперь умею в создание правильных образов систем для себя любимого. На случай если копро ну вот не хочется. Да, я научился билдить кернелы, а заодно и познал радости взаимодействия с ядерщиками. И да это не совсем простой путь. Но вообще это прикольно. И с этим вполне реально сделать весьма годную операционку. Потому что в целом они адекватны и любят свое дело. Просто знаний не всегда и не всем хватает.

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

395. "В ядре Linux 6.3 всплыла проблема, приводящая к повреждению ..."  –1 +/
Сообщение от Анннннно (?), 03-Июн-23, 15:29 
> разные дистрибутивы, разные относительно свежие LTS ядра, разные диски (SATA SSD и
> NVMe), оперативы от 16 до 64 гб, и везде копируешь тяжёлый
> файл - получаешь тормоза в гуе.

https://www.opennet.ru/openforum/vsluhforumID3/130607.html#322

Ссылку на *официальное* ядро 6.2.8 от *RedHat* для *CentOS-7*, или ты п***абол.

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

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

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




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

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