The OpenNET Project / Index page

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



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

Оглавление

Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, приводящей к повреждению файлов, opennews (??), 01-Дек-23, (0) [смотреть все]

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


67. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –1 +/
Сообщение от DEF (?), 01-Дек-23, 13:03 
Выводы таковы, что ты дилетант. ext2/3/4 могут молча хавать битые данные и продолжать как-бы "работать". Потому что у нех нет механизмов проверки целостности данных (cow, checksums, etc). Данные повреждены, а ФС работает. Надо же какое счастье для тебя.
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

75. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –1 +/
Сообщение от Аноним (24), 01-Дек-23, 13:15 
О том, чтобы данные были не повреждены, прекрасно заботится прошивка носителя. Так что, идея хешировать только метаинфу вполне здравая. А если данные повредятся по причине неисправности железа, никакие проверки тебе не помогут в итоге.
Ответить | Правка | Наверх | Cообщить модератору

78. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от DEF (?), 01-Дек-23, 13:25 
Прошивка носителя ничего не знает ни о ФС, ни о данных, ни о метаданных. Это днище. Если на Btrfs данные окажутся битыми, об этом разу будет известно. А ext4/XFS при рассыпании носителя, молча схавают это и дальше молча продолжат работать, как ни в чем ни бывало (silent data corruption). Данные тоже должны хешироваться, что есть в Btrfs.
Ответить | Правка | Наверх | Cообщить модератору

81. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +1 +/
Сообщение от Аноним (24), 01-Дек-23, 13:40 
Только silent data corruption не имеет ровно никакого отношения к повреждению носителя. Которое прошивка замечательно обнаружит после цикла самодиагностики (или даже сразу при обращении). Гораздо большая проблема это повреждение данных в процессе их записи, консистентность обеспечить может быть трудно даже при при наличии политики безумных повторных проверок. И файловые системы с нездоровым оверхэдом тут не особо помогут (а при совмещении с "лучшими практиками" ситуация становится ещё более абсурдной). Способность бтрфс сдохнуть и невозможность восстановления хоть чего-нибудь при серьёзных повреждениях, фактически множит на нет все её преимущества.
Ответить | Правка | Наверх | Cообщить модератору

95. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от DEF (?), 01-Дек-23, 15:05 
Поврежденные данные должны чекаться на уровне ФС. При записи должна быть сгенерирована хэш-сумма и потом периодически эта хэш-сумма должна сравниваться со сгенерированной хэш-суммой при скрабе. Прошивка тут ничем не поможет. Она не знает ни о ФС и тем более не имеет к внутренностям ФС. Btrfs давным-давно надежно и не дохнет на нормально работающем железе. А если и сдохнет, то данные восстанавливаются из бэкапа. Бэкапы надо делать в любом случае, даже если создадут супер-пупер надежную ФС. Эта ФС не спасет от пожара в хате или от сдохшего БП, который пропустит 220 вольт и сожгет все носители.
Ответить | Правка | Наверх | Cообщить модератору

113. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Аноним (24), 01-Дек-23, 16:24 
Кроме как добавить энтропии во вселенной этот подход ничего не несёт. Бесполезные операции ради бесполезных операций. Хотя, если нет возможности задействовать самодиагностику дисков (к примеру, при подключении через китайский переходник), то, может быть.

>на нормально работающем железе

на нормально работающем железе никогда не понадобится ничего сложнее ext4.

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

134. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Аноним (134), 01-Дек-23, 18:38 
На большом масштабе подход с чексуммами срабатывает:
https://www.cs.toronto.edu/~bianca/papers/fast08.pdf
https://indico.cern.ch/event/13797/contributions/1362288/att...

Вопрос в оправданности в конкретном случае.

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

358. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Аноним (-), 10-Дек-23, 12:40 
> Кроме как добавить энтропии во вселенной этот подход ничего не несёт. Бесполезные
> операции ради бесполезных операций. Хотя, если нет возможности задействовать самодиагностику
> дисков (к примеру, при подключении через китайский переходник), то, может быть.

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

>>на нормально работающем железе
> на нормально работающем железе никогда не понадобится ничего сложнее ext4.

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

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

360. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Аноним (24), 10-Дек-23, 12:57 
Упоминание ссд тут очень характерно и показательно на самом деле.
Ответить | Правка | Наверх | Cообщить модератору

184. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Аноним (-), 02-Дек-23, 01:07 
> О том, чтобы данные были не повреждены, прекрасно заботится прошивка носителя.

...которая у SSDшников, флешек, sd карт и прочей флешатины зачастую совсем не прочь отгрузить какую-то левую труху, особенно при приближении к лимиту записей. Очень доставляет любителям bcache (не путать с bcachefs), которые это юзают в нагруженых конфигах ради перфоманса - и потому нередко приближаются к лимиту записей даже с энтерпрайзными девайсами. После чего - ну, btrfs то красиво орет в логи на csum failed заранее, они вылезают с вопросами, и если не очень тупят - успевают заменить девайс(ы) ДО того как все разлетится окончательно. И по крайней мере не могут сказать что их не предупреждали о факапах их хардвара.

А вот фанов EXT4 и прочих XFS в этом месте по сценарию ВНЕЗАПНО зашибает роялем. И они вылезая из дырки удивленно - что за фигня? Где мои данные?! А там раз - труха на половине файлухи уже.

> Так что, идея хешировать только метаинфу вполне здравая.

Ну может тогда данные и хранить не стоит? Раз уж они не нужны. Ext4 все равно о их сохранности не парится, особенно без полного журнала (который тормозной как улитка из-за дублирования записей).

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

1) Таки помогают.
2) Прекрасно чинят битую копию из избыточной.
3) Это еще и дружественно к ремапу сбойных секторов фирмварой накопителя.

А ext4 будет насиловать нечитаемый сектор до упора. Данные же хочется, больше взять неоткуда, а запись в этот сектор чтобы его еще и ремапнуть - можно не дождаться. Скорее, если не повезет - можно искусственно догнать read error rate до потолка, накопитель решит что ему плохо, уйдет в safe mode - и вот тут вам уже СЮРПРИЗ! И да, все это шоу - из-за 1 гребаного бэда который можно было ремапнуть и забыть о нем.

И даже если RAID1 какой сделать - ну вот видите вы что 2 копии не совпало. И чего? Какая правильная в результате? С чексумами то ответ тривиальный. А сделать из EXT4 райд с чексумами ну не то что совсем нельзя, но админ предпочтет застрелиться при нужде это менеджить.

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

245. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Хм (?), 03-Дек-23, 15:56 
> А ext4 будет насиловать нечитаемый сектор до упора.

...
> И даже если RAID1 какой сделать - ну вот видите вы что 2 копии не совпало. И чего? Какая правильная в результате?

А разве не очевидно, что правильная та, которую один из накопителей прочитал без ошибок?
Вроде об этом было исходное утверждение.


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

337. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Аноним (-), 06-Дек-23, 09:30 
>> И даже если RAID1 какой сделать - ну вот видите вы что 2 копии не совпало.
>> И чего? Какая правильная в результате?
> А разве не очевидно, что правильная та, которую один из накопителей прочитал
> без ошибок? Вроде об этом было исходное утверждение.

Так сложно понять что фирмвари (в основном у флешастых штук) в последнее время взяли моду возвращать при чтении какую-то труху - без отлупа IO error при этом? И вот у вас 2 разные копии - а теперь попробуйте угадать которая из них была правильная!

С чексумами то это как 2 байта переслать - где совпало, тот девайс и нормальный. А вон тот, гамнюк, гонит, вот ему перезапись этого блока. А если такое часто - он, наверное протерся/сыпется/кривой и это вообще лучше заменить ASAP. При этом по крайней мере известно что проблема есть. А на какомнить EXT4 данные будут рандомно факапаться, никто ничего не заметит пока что-то не навернется как следует, в заметном виде.

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

271. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от edo (ok), 04-Дек-23, 10:14 
> О том, чтобы данные были не повреждены, прекрасно заботится прошивка носителя.

Или не прекрасно, личный пример факапа я уже размещал в этом обсуждении.

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

83. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +1 +/
Сообщение от User (??), 01-Дек-23, 13:52 
> Выводы таковы, что ты дилетант. ext2/3/4 могут молча хавать битые данные и
> продолжать как-бы "работать". Потому что у нех нет механизмов проверки целостности
> данных (cow, checksums, etc). Данные повреждены, а ФС работает. Надо же
> какое счастье для тебя.

Да нет, это вы на локалхосте не подозреваете, что data integrity может контролироваться как на уровне выше, так и ниже ФС. Объясните, нахрена мне например развертывать ноды кассандры поверх btrfs с её мейджик чексуммами, м? Вот чтобы что?
А кластеризованный postgres развернутый поверх raid6 в btrfs нуждается? Ох, бида - бегу переделывать. Заодним на бэкапах сэкономлю! Счастье то какое! Спасибо, друк!

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

97. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от DEF (?), 01-Дек-23, 15:11 
То что выше - костыли. То что ниже - не data integrity, а дно, ибо аппаратура не имеет доступа к внутенним кишкам ФС и ее структурам данных. Ты тут ляпнул про PostgreSQL (которая, у меня крутится на Btrfs с отключенным COW). Ну так вот, в БД целостность данных контролируется и обеспечивается этой же самой БД, а не делегируется ФС и еще каким-нибудь днищенским сервисам. По такому принципу должна наботать и ФС, ибо она по сути тоже БД.
Ответить | Правка | Наверх | Cообщить модератору

114. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Аноним (110), 01-Дек-23, 16:28 
Сейчас бы крутить PostgreSQL на BTRFS...
Ответить | Правка | Наверх | Cообщить модератору

143. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от User (??), 01-Дек-23, 20:21 
> То что выше - костыли. То что ниже - не data integrity,
> а дно, ибо аппаратура не имеет доступа к внутенним кишкам ФС
> и ее структурам данных. Ты тут ляпнул про PostgreSQL (которая, у
> меня крутится на Btrfs с отключенным COW). Ну так вот, в
> БД целостность данных контролируется и обеспечивается этой же самой БД, а
> не делегируется ФС и еще каким-нибудь днищенским сервисам. По такому принципу
> должна наботать и ФС, ибо она по сути тоже БД.

Ага. То, что выше - костыли, postgres - выше ФС, postgres это хорошо, по этому ФС должна быть как postgres. "Л" - логика! Я понял.

Кстати, а вы в курсе, что " Nodatacow implies nodatasum"? А что в postgresql чексумминг на уровне страниц надо включать отдельно? Впрочем, о чем это я, право слово. "Поздравляю тебя, Шарик - ты..."(ц)
Вопросы _когда именно_ проверяются включенные чексуммы в postgresql, что происходит при выполнении резервного копирования (С мастера, кстати - или с реплики?), поддерживается ли этот сетап энтепрайз-бэкапилками и тэ дэ - оставляю для самостоятельного изучения. Рекомендую провести его ДО факапа, а не после - но тут уж хум хау.

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

359. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Аноним (-), 10-Дек-23, 12:47 
> Кстати, а вы в курсе, что " Nodatacow implies nodatasum"? А что
> в postgresql чексумминг на уровне страниц надо включать отдельно?

Базы априори пытаются делать большую часть работы ФС, начиная с журналирования. Плюс-минус еще и чексуммы - логичное продолжение банкета. А зачем считать чексумы дважды? Если кто хотел косплеить ФС - пусть и косплеит. Даже вот фича такая есть.

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

361. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от User (??), 10-Дек-23, 14:16 
>> Кстати, а вы в курсе, что " Nodatacow implies nodatasum"? А что
>> в postgresql чексумминг на уровне страниц надо включать отдельно?
> Базы априори пытаются делать большую часть работы ФС, начиная с журналирования. Плюс-минус
> еще и чексуммы - логичное продолжение банкета. А зачем считать чексумы
> дважды? Если кто хотел косплеить ФС - пусть и косплеит. Даже
> вот фича такая есть.

И какое отношение этот спич имеет к истории Шарика выше, который вместе с COW, роняющей перформанс БД (mvcc субд + cow ФС, м-ммм!) отключил чексуммы на ФС, а в БД - внезапно - не включил, и рассказывает всем про супер-уровень-защиты-волосы-стали-длинными-и-шелковистыми, м?
А если "никакого" - то может лучшие собаководы расскажут, куда в таком сетапе ставить btrfs (Или не btrfs?), где включать чексуммы, как с этим взаимодействует репликация (Streaming или logical? Или может вообще не включать - двух контрацептивов заглаза?), к чему цеплять EMC Avamar (Или не цеплять? Защищено ж все!) - ну и что сделать, чтобы этот чудо-сетап в реальной жизни отставал от mssql на фуууу! немодной ntfs хотя бы процентов на 20, а не каквсигда?

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

273. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от edo (ok), 04-Дек-23, 10:19 
> Да нет, это вы на локалхосте не подозреваете, что data integrity может
> контролироваться как на уровне выше, так и ниже ФС.

На уровне ниже фс, внезапно, случаются факапы.
На уровне выше фс тоже не всё так просто, обычно софт ожидает консистентность от фс (например, что версия файлов данных бд соответствует версии wal).

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

288. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от User (??), 04-Дек-23, 12:49 
>> Да нет, это вы на локалхосте не подозреваете, что data integrity может
>> контролироваться как на уровне выше, так и ниже ФС.
> На уровне ниже фс, внезапно, случаются факапы.
> На уровне выше фс тоже не всё так просто, обычно софт ожидает
> консистентность от фс (например, что версия файлов данных бд соответствует версии
> wal).

Да. И уровень ФС, как мы видим, от факапов нифига не застрахован. Более того, лишнаяя сложность не бесплатна и сама по себе повышает вероятность возникновения в том числе новых (классов) ошибок. Три презерватива не работают в три раза лучше одного, да?

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

291. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от edo (ok), 04-Дек-23, 12:58 
> Да. И уровень ФС, как мы видим, от факапов нифига не застрахован.
> Более того, лишнаяя сложность не бесплатна и сама по себе повышает
> вероятность возникновения в том числе новых (классов) ошибок. Три презерватива не
> работают в три раза лучше одного, да?

с моей точки зрения, обеспечение консистентности — это совсем не лишняя функциональность у фс.
а факапы с потерей данных были с у ext4, и у xfs, про btrfs я вообще молчу

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

296. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +1 +/
Сообщение от User (??), 04-Дек-23, 16:01 
>> Да. И уровень ФС, как мы видим, от факапов нифига не застрахован.
>> Более того, лишнаяя сложность не бесплатна и сама по себе повышает
>> вероятность возникновения в том числе новых (классов) ошибок. Три презерватива не
>> работают в три раза лучше одного, да?
> с моей точки зрения, обеспечение консистентности — это совсем не лишняя функциональность
> у фс.
> а факапы с потерей данных были с у ext4, и у xfs,
> про btrfs я вообще молчу

Ну, теоретически - если "забесплатно" или "очень-очень-дешево", то конечно "ДА!!!". Если дорого, сложно и с COW в нагрузку - то уже ХЗ. Хватит ли чексуммы метаданных в качестве компромисса - тоже вопрос.
Ответ на это все - varies от системы к системе. Как-то так.

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

159. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Tron is Whistling (?), 01-Дек-23, 21:54 
Ну вот ZFS нули в файлах не хавала, да?
Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

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

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




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

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