The OpenNET Project / Index page

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



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

Оглавление

В OpenZFS выявлена ошибка, которая может привести к повреждению файлов, opennews (??), 23-Ноя-23, (0) [смотреть все]

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


70. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от пох. (?), 23-Ноя-23, 14:14 
> Если не работает write barrier - это и сейчас может происходить.

write barrier ни от каких повреждений файлов не спасает. Он спасает от автоотката на состояние фс до сотворения мира при крэше.

А silent data corruption (опять неумельцы пользуются поиском по сайту или идут найух) - он всегда с тобой.

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

80. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 23-Ноя-23, 14:20 
Почитай повыше - о чём речь. Речь об обрезке метаданных. В основном сие случается, когда кусок журнала с новыми метаданными потерян. А если нет write barrier - ты хоть как ужом вертись.

Ну и да, silent data corruption - это вот то самое, чем ZFS в описанном в новости случае и занимается.

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

247. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от нах. (?), 24-Ноя-23, 11:23 
> В основном сие случается, когда кусок журнала с новыми метаданными потерян. А если нет write
> barrier - ты хоть как ужом вертись.

write barrier всего лишь делает этот кусок ограниченным во времени (ценой потери производительности)

ничего не меняя по сути.

> Ну и да, silent data corruption - это вот то самое, чем ZFS в описанном в новости случае и
> занимается.

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

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

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

292. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (-), 24-Ноя-23, 21:52 
> write barrier всего лишь делает этот кусок ограниченным во времени (ценой потери
> производительности)

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

> ничего не меняя по сути.

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

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

Ну как бы да. Однако тут тоже "копии" без анонса получаются левые какие-то. А фича пошла в массы и вон те уже и по дефолту это стали. Ах, представляете какие наглецы, еще и пользуются фичами. Подразумевая что они еще и работать должны!

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

Какие корралы на этот раз Клара украла у Карла?

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

210. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (-), 24-Ноя-23, 01:33 
>> Если не работает write barrier - это и сейчас может происходить.
> write barrier ни от каких повреждений файлов не спасает. Он спасает от
> автоотката на состояние фс до сотворения мира при крэше.

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

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

> А silent data corruption (опять неумельцы пользуются поиском по сайту или идут
> найух) - он всегда с тобой.

С чексумами и избыточностью то - его как раз можно нехило замахать. В чем пойнт этой академической гребли и состоит.

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

239. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 24-Ноя-23, 09:56 
> Немного не так. Если у тебя это не работает в железе -

Ну и я о том же. Write barrier должен работать от ведра до конечного диска.

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

301. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (-), 24-Ноя-23, 23:40 
>> Немного не так. Если у тебя это не работает в железе -
> Ну и я о том же. Write barrier должен работать от ведра
> до конечного диска.

Ну как бы это сказать? В идеале, фс, особенно с избыточностью, должна бы переживать и lost write/reordered write/труху в тех или иных секторах и прочие странные загоны накопителей.

Другое дело что вылезти за допущения дизайна все же можно, да и стресстестить логику selfheal лишний раз - ну в общем то не очень умная идея. Даже если обычно и прокатывает. И каких-то реально эффективных гарантий почему все это ОБЯЗАНО сработать, с произвольными факапами железа - ну, вот, нет при нарушении той семантики. Просто потому что то что файлуха пыталась и то что по факту получилось может оказаться двумя довольно большими разницами, и насколько это втиснется в допущения дизайна - вопрос интересный.

Но я вот юзанул BTRFS с схемой DUP в ряде мест - и очень радикально пересмотрел теорвер, теперь я проигрываю не "если 1 бэд вынес критичные структуры" а "если два бэда накрыли две копии блока". А это вообще совсем другое допущение, и вот так мне теорвер и игра в ту рулетку нравится намного больше. Почему-то. Да, это не 100% решение. Но на практике так намного лучше работает. А Вы можете переставлять операционку после того как libc6 не прочитался, я совершенно не против, если такой булшит бинго будет у вас.

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

306. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 25-Ноя-23, 10:07 
> А Вы можете переставлять операционку после того как libc6 не прочитался,
> я совершенно не против, если такой булшит бинго будет у вас.

Я за 15 лет на всей инфре ни один раз в бэкап не залез по причине повреждения данных, такие дела...
Но бэкапы делаются исправно. Потому что есть прочие задачи - например найти, когда юзер себе что-то снёс и плачет.

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

320. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (319), 25-Ноя-23, 23:53 
> Я за 15 лет на всей инфре ни один раз в бэкап
> не залез по причине повреждения данных, такие дела...

Это может свидетельствовать о самых разных вещах, как минимум...
1) Удачливый тип.
2) Админ локалхоста с полутора тазиками и статистикой под стать.
3) Информация была не очень то и нужная, никто и не парился.
4) Если вам кажется что дела идут хорошо, возможно вы просто чего-то не заметили. С какимнить EXT4 - легко. Ему все пофиг, включая и целостность данных.
5) Тепличные условия, типа упсов, не очень активных операций, идеального железа, пофигистичных юзерей, ... .

А также много чем еще. Если вы хотели сказать что к тому были какие-то логические предпосылки и ваши заслуги - это неплохо бы обосновать. С учетом любви к примитивным ФС мне кажется что это ближе всего к пункту 4) может оказаться. А как вы вообще глобально проверяете живость всех данных? А, никак? Это хитрый план. Нет integrity check, нет факапов с ним, кто б спорил. Но мне кажется что в логике страуса с закапыванием бошки в песок есть какая-то подстава.

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

Ну дык. А я вот как-то скатался из-за 1 сраного бэда раз в дофига лет вылезшего под либц6 в знатные перди в авральном режиме. Не понравилось! Я и пересмотрел подход к созданию систем, когда соотношения сильно иные и куда больше в мою пользу. В том числе и по линии теорвера. Который таки не пустой звук - особенно по мере роста емкостей, скоростей, да еще подпертого желанием вон тех - чтоб это все еще и за копейки. В этом месте идея гонять на антикварной файлухе без self repair и чексум начинает выглядеть для меня не очень хорошим планом, ибо тест следствий законов Мерфи из пункта 4) прямо на себе - не кажется мне отличной идеей.

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

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

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




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

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