The OpenNET Project / Index page

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



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

Оглавление

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

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


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.dev/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
Добавить, Поддержать, Вебмастеру