The OpenNET Project / Index page

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



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

Оглавление

В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachefs, opennews (??), 07-Фев-24, (0) [смотреть все]

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


19. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +2 +/
Сообщение от Шарп (ok), 07-Фев-24, 15:55 
Да всё он вывозит. Просто в сишке нет RAII, чтобы запилить блокировку, которая сама снимается при выходе из зоны видимости.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

29. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +/
Сообщение от Аноним (-), 07-Фев-24, 16:55 
> Да всё он вывозит. Просто в сишке нет RAII, чтобы запилить блокировку,
> которая сама снимается при выходе из зоны видимости.

Совсем не факт что ты хотел в ФС именно вот это вот. ФС это такой весьма многопоточный "handler" и будет очень не круто если разные части ФС друг с другом столкнутся, делая конфликтующие операции. Это идет несколько дольше RAII, и являет собой "очень продвинутый арбитраж ресурсов".

Там еще есть например фоновые воркеры и ядерные треды - которые работают параллельно/асинхронно/дефернуто - и еще перфоманс всего этого очень критичен, иначе на скоростном стораже встревает на именно блокировках, и - "system is thrashing". Т.е. она ничего не делает, туповейтит в блокировках большую часть времени. Что не есть гуд.

Совсем без блокировок тоже нельзя - взаимо-конфликтующие параллельные операции столкнутся.

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

57. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +/
Сообщение от Аноним (41), 07-Фев-24, 20:16 
> Совсем без блокировок тоже нельзя - взаимо-конфликтующие параллельные операции столкнутся.

Можно. Неблокирующие структуры данных и упорядочивание операций спасут от блокировок. Для баз данных работает, значит и для ФС будет работать.

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

70. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +/
Сообщение от Аноним (-), 08-Фев-24, 00:00 
>> Совсем без блокировок тоже нельзя - взаимо-конфликтующие параллельные операции столкнутся.
> Можно. Неблокирующие структуры данных и упорядочивание операций спасут от блокировок.
> Для баз данных работает, значит и для ФС будет работать.

Простите, а как например GC параллельно с этим всем гонять - не наступая себе на хвост? В базе зачастую ответ - "никак" но cow-файлухе так не катит. Почему-то. Bcachefs таки слизал ряд идей БД и bcache - но вообще совсем без блокировок все же не получилось хотя автор явно в курсе тех идей. Если вы такие умные - покажите мастеркласс, м?

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

47. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +1 +/
Сообщение от Аноним (47), 07-Фев-24, 18:27 
> RAII

Ее и в ассемблере нет.

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

106. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +/
Сообщение от Аноним (106), 08-Фев-24, 11:30 
Как же вы достали.
Во первых есть расширение на уровне компиляторов.
Во вторых - никто не мешает организовать это на уровне макроса-структур и менеджера памяти.
В третьих, 90% проблем ловится статическим анализом, а то что не ловится - проблема в логике от которой не защитит НИКАКОЙ яп.  
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

142. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +/
Сообщение от Аноним (-), 08-Фев-24, 14:58 
> Как же вы достали.
> Во первых есть расширение на уровне компиляторов.
> Во вторых - никто не мешает организовать это на уровне макроса-структур и
> менеджера памяти.

В третьих в линухе даже и круче есть - там подобие деферов сделали, это даже более крутой и универсальный механизм. Только вот он не замена блокировок в том виде каком это ФС актуально. В ФС происходит несколько параллельных, независимых действ, в практически независимых сегментах кода (e.g. ядерном треде или wq) и надо чтобы они сообща - не наломали дров, наехав друг другу на хвост.

> В третьих, 90% проблем ловится статическим анализом, а то что не ловится
> - проблема в логике от которой не защитит НИКАКОЙ яп.

Отладка сложного кода с нетривиальными параллельными взаимодействиями вообще не универсальный топик без серебряных пуль. Скажем какой-нибудь тред GC - по сути почти отдельная программа в каком-то роде. Работает независимо от всего остального, логически декорелирован - чтобы кодер не спятил случайно от уровня сложности действа - но он не должен столкнуться при своей работе с иной активностью, потенциально происходящей в его регионах интереса по другим поводам. И тут оказывается что совсем без блокировок - ну вот упс. И если кто думает что файлушники их любят или делают это по приколу - да вот фиг.

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

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

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




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

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