The OpenNET Project / Index page

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



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

Оглавление

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

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


46. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  –1 +/
Сообщение от Аноним (46), 23-Ноя-23, 13:21 
>ошибка, которая может привести к повреждению файлов

Да несколько лет назад в течение довольно длительного времени в реализации ext4 в ядре Linux была ошибка, приводящая к повреждению фс, включая повреждение файлов, как системных, так и в home. В качестве вокрараунда я ставил полную проверку ФС на каждый перезапуск через добавление файла в корень через systemd unit и перезагружался почаще (каждая перезагрузка занимала долгое время). Если не перезагружаться почаще - можно было возможно вылететь, и после - загрузиться в initrd и полсистемы через пакетный менеджер переустанавливать. Я ещё подозревал аппаратные проблемы с жёстким диском, но диск был хитачи и имел хорошие SMARTы. Хорошо что купить новый диск я не мог, это были бы потраченные на ветер деньги.

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

55. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (153), 23-Ноя-23, 13:49 
Похоже, только там были не нули в файле, а сам файл тупо обрезался до нулевой длины. Если я о том же баге вспомнил. Их тоже было не мало.
Ответить | Правка | Наверх | Cообщить модератору

64. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 23-Ноя-23, 14:08 
Если не работает write barrier - это и сейчас может происходить.
Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

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ообщить модератору

209. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (-), 24-Ноя-23, 01:29 
> Да несколько лет назад в течение довольно длительного времени в реализации ext4
> в ядре Linux была ошибка, приводящая к повреждению фс, включая повреждение
> файлов, как системных, так и в home. В качестве вокрараунда я
> ставил полную проверку ФС на каждый перезапуск через добавление файла в
> корень через systemd unit и перезагружался почаще (каждая перезагрузка занимала долгое
> время). Если не перезагружаться почаще - можно было возможно вылететь, и
> после - загрузиться в initrd и полсистемы через пакетный менеджер переустанавливать.
> Я ещё подозревал аппаратные проблемы с жёстким диском, но диск был
> хитачи и имел хорошие SMARTы. Хорошо что купить новый диск я
> не мог, это были бы потраченные на ветер деньги.

...а чтобы не заниматься всей вот этой НЕВМЕНЯЕМОЙ ХРЕНЬЮ вместо эксплуатации систем я и юзаю btrfs ;).

Там если железо сбоит - вопли "csum error" сразу покажут что хардвар дурит. Даже если винч исправный, это не доказывает что проц, чипсет и память ведут себя как надо. И какая разница кто из них битик вон там крутанет или неправильно посчитает. В результате можно получить факап и очень плохо если это - ВНЕЗАПНО. Гадать корректно ли работает железо это булшит, end to end проверки с чексумами - EPIC WIN, и по этой фиче я полностью согласен с ZFS'никами.

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

Про то что онлайн проверка и вообще-то scrub, а желательно с self heal из избыточной копии, если она есть - это хорошо и правильно - даже и упоминать неудобно. Автралопитеки с EXT4 с бамбуковым самолетом вообще не понимают прелестей бортового компьютера (из бамбука он фигово эмулируется, увы).

В этом аспекте я таки понимаю ZFSников. А subj - ну, они что-то нагнули в процессе разработке и таки какие-то проблемы с "общим качеством кода" кажется пошли.

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

238. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 24-Ноя-23, 09:54 
Та же проблема: как только у тебя факапнется метадата в силу программной ошибки - больше ты оттуда вообще ничего не выгребешь. На экстах хотя бы просто сканированием можно кое-что вытащить, файлы мешаниной по диску не размазаны.
Ответить | Правка | Наверх | Cообщить модератору

289. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (289), 24-Ноя-23, 20:09 
> Та же проблема: как только у тебя факапнется метадата в силу программной
> ошибки - больше ты оттуда вообще ничего не выгребешь.

1) Вообще, сэр, я Data Recovery на полупро уровне с уклоном в линух занимаюсь малость, себе по кайфу. Поэтому "I know what I'm doing".
2) Мне тут это уже лет 10 чтоли обещают. А оно все никак, так что для других только вот рекавери делаю.
3) Лучший Data Recovery - который не потребовался. А именно
- Сбои как правило ведут к "csum error" ДО того как это станет более крутой проблемой.
- На схемах с избыточностью зачастую оно могет в self repair.
- Оперативное устранение факапов железа очень способствует вон тому.
- С качеством софта и интеграцией в майнлайн у них имхо сильно лучше вон того позора, имхо.
4) Если вдруг - ну я более представляю себе структуру этой штуки, знаю рекавери опции, знаю где живет офлайн парсер (для EXT4 такая прелесть вообше доступна только в коммерческих виндовых прогах, на минутку) - а поскольку это cow, есть сильно более 1 точи входа. И можно попытаться довольно много чего ДО того как всякими testdisk и photorec колупаться.
5) Если вдруг вон того окажется мало - я таки знаю где и как спросить "помощь зала". И да, я вполне в состоянии флипнуть битик в хексэдиторе и чего там еще, мануально вправив метаданным мозг за глючным железом. Если вдруг так надо.

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

Угу. А при полном отказе накопителя вы вытаскиваете - например, что? А на RAID1 и с таким жить можно. Да что там, с DUP на сыпучей флехе btrfs - вот - изумительно крутит теорвер в мою пользу. А EXT4 там в труху за месяц - легко! При том без чексум не то что self repair нет, но и диагностики, просто в какой-то момент он умрет, без предупреждений. В общем совсем другой уровень технологий. Со знаком минус. За отсутствие диагностики и ранних предупреждений.

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

293. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 24-Ноя-23, 21:59 
С перфокарт рекаверишь?
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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