The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

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

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


35. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  –1 +/–
Сообщение от нах. (?), 07-Фев-24, 17:14 
> А почему бы и нет?
> Вот за столько лет openzfs стала надежной и стабильной?
> А не за сколько, ахаха, с ней до сих пор данные теряются!

Но они там не теряются из-за попытки удалить несуществующую фс, даже если ты упор(ен) и сделаешь это дважды.
И она не крэшит ядро из-за закрытия файла.

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

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

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

Не ФС а subvol. Subvol - это дерево, типа директории. Точка входа. Просто менеджится независимо от остального, тепер в ФС может быть более 1 / что и делает всякие снапшоты и проч удобными.

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

> И она не крэшит ядро из-за закрытия файла.
> Чтобы именно потерять данные - надо в ней сделать с пулом какую-то
> очень стремную операцию, и, как правило, одновременно дернуть питание.

Вот именно в случае CoW - дерг питания обычно приводит дизайн в несколько более старое состояние и профакивается только то что не было синкнуто, тут уж пардон. А вот сломать CoW сам по себе именно так - весьма экзотично. Разве что если сломается еще и фирмвара накопителя и профачит допустим Eraseblock - а вот тут уже мало кто готов к тому что чушку в 16...64 мега целиком пролю, за то что "те данные лежали в этом регионе". Это нарушает семантику - но на SSD так то нельзя сдергивать питание в произвольный момент времени, это нарушение их условий эксплуатации и логиится в смарт.

> И даже в этом случае тебе должно еще и сказочно неповезти - пришедшие
> к успеху обычно не один раз такое сделали.

У меня есть накопитель где внеплановые шатдауны более 100 раз были - а btrfs там так и не помер. Видимо не оч кривая фирмварь и ворочание eraseblock'ов сделано относительно вменяемо.

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

52. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +3 +/–
Сообщение от нах. (?), 07-Фев-24, 19:06 
> Не ФС а subvol. Subvol - это дерево, типа директории.

директория - это французское правительство времен контр-революции.
А в zfs аналог ваших "subvol" - filesystem.

> Случай когда пытались грохнуть именно subvol, да еще не существующий, дважды - все же при
> практических сценариях достаточно специфичный

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

А вот случаи когда люди прямо совсем необратимо теряли пулы zfs - это действительно несчастные случаи. Трудно назвать счастливчиком человека, который при восстановлении _уже_ поврежденного громадного пула ловит внезапно попадание молнии в трансформатор. (Да, он в принципе зря стал это делать, но полагаю у него просто не было столько лишних денег на второй такой же.)

> Вот именно в случае CoW - дерг питания обычно приводит дизайн в несколько более старое
> состояние и профакивается только то что не было синкнуто

а теперь представь что это операция не банальной записи пары бит в конец файлика, а реконфигурация всей системы. Точно-точно ли при этом можно профакать то что не было синкнуто, особенно с учетом привычки дисков к write reordering? Авторы zfs вот видимо думали что можно. Оказалось - нельзя, ну или во всяком случае в текущем состоянии кода нельзя, а способных его чинить уже нет.
Ну и отсутствие fsck таки очень плохая, вообще никуда негодная идея, разумеется - вытекающая из предыдущей неверной гипотезы.

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

64. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +/–
Сообщение от PnD (??), 07-Фев-24, 22:13 
В btrfs местный fsck тоже примерно полностью нерабочий. О чём, впрочем, авторы честно предупреждают.
Зато есть механизм экспорта данных через разматывание журнала от начала до точки слома.
Этого (или хотя бы внятного инструмента отката указателя, hexedit не предлагать) в современной zfs реально не хватает.
* А вот reflink в последнем выпуске, внезапно, осилили. Минус 1 повод поканючить о продолбанных компетенциях.
Ответить | Правка | Наверх | Cообщить модератору

79. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +/–
Сообщение от нах. (?), 08-Фев-24, 01:17 
txg можно откатить без хексэдита (ее, правда, угадать тот еще гемор). Ходят слухи что это кому-то даже помогало импортировать неимпортящийся пул хотя бы в r/o и слить данные.

> А вот reflink в последнем выпуске, внезапно, осилили.

они там даже добавление в raidz6 (который целиком неосилен линуксятками) осилили, чего я от них совсем не ждал. (правда оно малость кривоватое, но это можно считать фичей)

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

100. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +/–
Сообщение от Аноним (100), 08-Фев-24, 10:38 
> они там даже добавление в raidz6 (который целиком неосилен линуксятками) осилили, чего я от них совсем не ждал. (правда оно малость кривоватое, но это можно считать фичей)

А можно поподробнее?

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

123. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +/–
Сообщение от нах. (?), 08-Фев-24, 13:53 
>> они там даже добавление в raidz6 (который целиком неосилен линуксятками) осилили, чего я от них > А можно поподробнее?

https://github.com/openzfs/zfs/pull/15022#issuecomment-18024...

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

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

135. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  –1 +/–
Сообщение от Аноним (-), 08-Фев-24, 14:48 
> Я даже предлагал местным горе-писакам запилить про это новость (когда она еще
> была - новостью) но им неинтересно, то ли вот дело про
> ненужный скрипт на ненужном язычке - это куда важнее.

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

Твой путь и твоя версия будущего отличаются от того что я хочу видеть - и это твоя участь создавать его, или бесславно слить, если тебе так удобнее. Мне ZFS не нужен.

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

138. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +/–
Сообщение от нах. (?), 08-Фев-24, 14:53 
> Просто для понимания - некий анон наколотил про сабж основные тезисы для Чиркова.

ну мне было лень стараться (потому что все что я хотел бы увидеть - и так было по ссылке, а копипастой мне неинтересно заниматься) в этот раз (все равно обычно мои новости не публикуют as is, а после замены всего мата обтекаемыми выражениями становится неясным о чем новость)

Тем более что я ни тем ни твоим кентам ничего и не задолжал.

А опеннет давно уже не про новости а про т-пой троллинг и скрипты удаляющие сообщения методом рандомного тыка.

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

166. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +/–
Сообщение от Аноним (-), 08-Фев-24, 16:28 
>> Просто для понимания - некий анон наколотил про сабж основные тезисы для Чиркова.
> ну мне было лень стараться (потому что все что я хотел бы
> увидеть - и так было по ссылке, а копипастой мне неинтересно
> заниматься) в этот раз (все равно обычно мои новости не публикуют
> as is, а после замены всего мата обтекаемыми выражениями становится неясным
> о чем новость)

А я решил оставить себе подобным месадж - "стоит обновить кернел", если они юзают вон то. Надеюсь спасет их от пары грабель.

Мой интерес в этом? "А зачем мне багованая файлуха?!". Вот зачем небагованый современный CoW дизайн - придумаю эн вариантов. В идеале сие простимулирует кого-то присоединиться к процессу.

> Тем более что я ни тем ни твоим кентам ничего и не задолжал.

Это моя персональная дань уважения упрямому чуваку на самом деле. Если я могу сдвинуть мир на миллиметр в его пользу - something to chew on!

> А опеннет давно уже не про новости а про т-пой троллинг и
> скрипты удаляющие сообщения методом рандомного тыка.

Ну вот бот подбешивет, да. И все же - если тебя интересует направление и его взлет логично в этом участвовать. Ну или кто это должен делать? Мне ZFS с его свойствами - просто не требуется. Тратить время на технологию которой не пользуешься странная идея. Тем более что так легко нагнать с 3 короба.

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

113. "В ядре Linux 6.8 исправлены две серьёзные проблемы в bcachef..."  +/–
Сообщение от Аноним (-), 08-Фев-24, 12:26 
> директория - это французское правительство времен контр-революции.

Вот оно что! Юниксоиды - буржуазная контра стало быть?!

> А в zfs аналог ваших "subvol" - filesystem.

А ты уверен что 100% аналог? Скажем новый снапшот ZFS - будет технически именно новым filesystem в тех терминах? Или скажем filesystem можно удалить через системные вызовы? Ну там rm обычным и проч? Снапшоты (и сабволы вообще) btrfs/bcachefs можно отменеджить не только родной утилсой - но и просто F8 в миднайте каком. Поскольку это в принципе лишь независимая иерархия, нет особых проблем ее - снести, как диру почти, с довольно небольшими отличиями.

> банально опечатался, получил ошибку, не понял в чем дело и повторил команду.

Ну вот видимо кто-то и заметил что фигня какая-то получается. Фигня досадная но не фатальная.

> Или того проще, ошибка в скрипте вычисляющем имя того что нужно удалить,

Я бы в общем случае побаивался юзать скрипты с ошибкой вычисления сносящие subvol, имхо. Хотя любителям bumblebee понравится. Особенно если у...ть нужный снапшот (для аутентичных ощущений).

> Судя по тому что сразу же и нашли - то либо другое у кого-то и было.

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

> А вот случаи когда люди прямо совсем необратимо теряли пулы zfs -

Так там речь о потере данных вообще не идет. Только о обидном локапе в кишках фс.

> (Да, он в принципе зря стал это делать, но полагаю у
> него просто не было столько лишних денег на второй такой же.)

Ну я вот как-то рестрайпил некий btrfs - и питание улетело. Технически примерно то же самое по смыслу. В общем случае balance являет собой недеструктивную операцию. Конечно любое кантование данных несет некие риски, но т.к. cow сперва создает копию а потом "указатели перевешивает", крах в общем случае не вызывает больших проблем. То что записалось сохраняется, то то не записалось авто-отменяется за отсутствием "указателей" на это. А сам дизайн нормально относится к смеси разных типов block groups, ну ему и пофиг было. Прекрасно маунтится и работает, так что пнуть операцию еще раз - он и доконвертит что еще не успел. Мне вот повезло - flawless conversion, даже после poweloss. Scrub никаких траблов не увидел и все как часики.

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

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

Если я что-то такое затеваю - тебе не приходило в голову что снапшот по его смыслу это такой мануальный "barrier" на тему состояния ФС в этой точке пространства времени? Я сигналю что считаю это состояние ценным. Это мой key frame в таймлайне. Я требую его не разрушать GC, чтобы иметь возможность на него вернуться.

...а после этого можно хоть "eatmydata apt upgrade" влупить, и если он даже сгорит синим пламенм, мне совершенно не важно что там отъедет, я снапшот "атомарно" в старое состояние верну вместо колупания в деталях факапа. Сэкономив дочерта времени на парировании проблемы. А потом можно попытаться операцию еще раз. "All or nothing" можно заимелементить совместной игрой с машиной, так сильно эффективнее. Ибо я лучше знаю определения "all" и "nothing" в этом контексте.

> Точно-точно ли при этом можно профакать то что не было синкнуто, особенно
> с учетом привычки дисков к write reordering?

Если команды сброса буферов работают как должны, то само по себе это имхо не проблема. А если нет - там с любой ФС при случае гамна можно будет откущать ибо они ВСЕ на эту семантику уповают.

Есть еще всякие совсем левые вещи - типа продолба eraseblock который in-flight при powerloss, но вот тут - сорян, если чушка в 16-64 мега испарилась, любая ФС может дать дуба. У особо неудачливых, с голимым накопителем, глупой фирмварой и неудачным расположением - вместе с партишном заодно. А те кто поумнее догадываются отступить на флешатине от начала девайса достаточно почтенный 2^N (64MiB или более) чтобы партинш в своем eraseblock'е лежал и его не ворочали лишний раз. Т.к. там interleave, это erase group на самом деле, его могут ворочать весь сразу, и он крупнее 1 eraseblock'а, откуда и округление.

В случае "испарения чушки" очень кстати если была избыточность, даже DUP даст нехилые шансы потрепыхаться. По той же причине суперов и у кента и у бтрфс несколько. Что-нибудь да выживает, а дальше self heal по полной версии задумки. На практике - в btrfs рековери суперов таки маниуальная операция. Но вроде недавно таки сделали и опцию автоматически чинить убитый основной супер из запасных.

> Авторы zfs вот видимо думали что можно. Оказалось - нельзя, ну или во всяком
> случае в текущем состоянии кода нельзя, а способных его чинить уже нет.

Вообще фирмвари накопителей делают очень много всякой весьма странной фигни, там дочерта quirks, out of spec поведения и левизны. Ну вон у самса например были траблы с trim, вплоть до того что это могло девайс угробить. Не по спекам, но юзеру с дохлым девайсом же не объяснишь, он будет вопить что это ацтой. Имея некий пойнт. Так что там костылей в libata и проч - очень даже. У btrfs'ников кстати описаны "типовые" факапы сторажей в их доках, по их опыту.

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

С практической точки зрения - на серваках - да и моих одноплатниках - этот fsck запускать решительно некому. Так что это как баг - так и фича. Ибо дочерта систем работает, натурально, в режиме автопилота.

И там мы хотим self heal до последнего - пока это можно, с диагностикой и статистикой. А потом - потом система потребует мануальное внимание и это mission failed что так что сяк, детали уже не очень важны. Железки стояли не для того чтобы там fsck запускали. Вообще совсем.

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

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

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




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

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