The OpenNET Project / Index page

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



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

Оглавление

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

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


62. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  –1 +/
Сообщение от Tron is Whistling (?), 23-Ноя-23, 14:03 
Чего, простите?
RAID5/6 собственно и позволяет проверить целостность...
Ответить | Правка | Наверх | Cообщить модератору

112. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от fidoman (ok), 23-Ноя-23, 15:58 
> Чего, простите?
> RAID5/6 собственно и позволяет проверить целостность...

RAID5 позволяет восстановить недостающий диск, но не позволяет корректно восстановить данные, если один диск выдаёт неверные и неизвестно, какой.

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

139. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от аНОНИМ (?), 23-Ноя-23, 17:31 
> RAID5 позволяет восстановить недостающий диск, но не позволяет корректно восстановить данные, если один диск выдаёт неверные и неизвестно, какой.

А вот RAID6 теоретически позволяет (если битые данные на одном диске из всех), но опять же нихрена такого mdraid не делает. Я проверял.

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

226. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (-), 24-Ноя-23, 03:12 
>> RAID5 позволяет восстановить недостающий диск, но не позволяет корректно восстановить данные, если один диск выдаёт неверные и неизвестно, какой.
> А вот RAID6 теоретически позволяет (если битые данные на одном диске из
> всех), но опять же нихрена такого mdraid не делает. Я проверял.

А на btrfs такое даже работает, я для RAID1 и DUP проверял - таки просекает какая копия битая, чинит, и продолжает работать как ни в чем ни бывало. Даже на сыпучей флешке выживает. Выглядит как потрошеный окунь в живой воде у стругацких, но при всем этом - еще и работает. Крутануть теорвер в свою пользу - по своему забавно.

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

228. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +1 +/
Сообщение от аНОНИМ (?), 24-Ноя-23, 09:09 
> А на btrfs такое даже работает, я для RAID1 и DUP проверял - таки просекает какая копия битая, чинит, и продолжает работать как ни в чем ни бывало. Даже на сыпучей флешке выживает.

На бтрфс с миррорами -- работает. С раид5-6 когда я проверял (довольно давно) -- НЕ работало. Отдавало примерно половину файлов или меньше, остальные io error. А вот OpenZFS что с миррорами, что с рейдZ1/2 -- тоже железобетонно всё отдавало.

Я проверял очень просто -- писал файлы, потом делал dd if=/dev/urandom of=/весь/девайс/из/рейда и монтировал ФС взад. ZFS усралось спамить в dmesg, но всё железобетонно отдало. А после скруба стало как новое. btrfs с raid5/6 обломался.

Допускаю, что сейчас там raid5 починили и он уже всё отдаст. Но проверить пока негде.

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

323. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (319), 26-Ноя-23, 01:16 
>> А на btrfs такое даже работает, я для RAID1 и DUP проверял
> На бтрфс с миррорами -- работает.

А я умею читать документацию, и если нечто озвучено как экспериментальная фича - ну я и делаю определенные выводы.

Впрочем - там можно и более продвинуто. Скажем если метаданные RAID1 (или даже RAID1C3 для фанатов RAID6) а данные RAID5/6 - это уже более интересное комбо. Потому что write hole перестает импактить метаданные, а остальное - все же менее проблемный топик. Если метаданные живые, все намного оптимистичнее в плане перспектив.

На самом деле write hole там можно аннулировать scrub после краха, но это неудобное требование. Более полное решение требует изменение структур ФС для логинга write intent и все такое.

> С раид5-6 когда я проверял (довольно > давно) -- НЕ работало.
> Отдавало примерно половину файлов или меньше, остальные io error.

RAID5 таки довольно заметно пофиксили - хоть и ценой потери перфоманса в ряде операций, ибо полный RMW страйпа делается чаще. В паре с RAID1 для метаданных, можно уже даже попробовать потрепыхаться. Но официально все равно experimental, и если что - ну, девы честно сказали как оно. Мне честное описание свойств - больше нравится чем красивые сказки. Меньше неприятных сюрпризов. Больше места для информированных осознанных решений.

> А вот OpenZFS что с миррорами, что с рейдZ1/2 -- тоже железобетонно всё отдавало.

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

> Я проверял очень просто -- писал файлы, потом делал dd if=/dev/urandom
> of=/весь/девайс/из/рейда и монтировал ФС взад.
> ZFS усралось спамить в dmesg, но всё железобетонно отдало.
> А после скруба стало как новое. btrfs с raid5/6 обломался.

Ну вон то какой-то не особо реалистичный случай отказа. Чему в реальном мире ЭТО соответствует?

> Допускаю, что сейчас там raid5 починили и он уже всё отдаст. Но проверить пока негде.

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

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

У вас - ну вы все 3 копии супера вынесли. В реальных сценариях, от них или что-то останется, или это полный отказ и замена девайса с полным ребилдом соответственно. Разработчики btrfs все же на реалистичные сценарии ориентировались. А как там какая тушка с оторваной головой бегает - ну, не очень интересно, имхо. Интереснее чтобы с типовыми факапами железа справлялось.

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

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

168. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Аноним (165), 23-Ноя-23, 19:44 
Я смотрю ты шаришь. Не объяснишь по простому, что такое write gap у RAID5/6?
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

182. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 23-Ноя-23, 22:58 
Не объясню - это ошибочный термин.
Ответить | Правка | Наверх | Cообщить модератору

183. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +/
Сообщение от Tron is Whistling (?), 23-Ноя-23, 23:00 
И применять его в контексте рейда не следует, термин write gap действительно существует - но он относится к аппаратуре записи магнитных накопителей, а вовсе не к рейду, и не имеет прямого отношения ни к надёжности, ни к производительности, хотя влияет на оба параметра.
Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

204. "В OpenZFS выявлена ошибка, которая может привести к поврежде..."  +1 +/
Сообщение от Аноним (204), 24-Ноя-23, 01:04 
Тогда мне поясни за wright hole.
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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