The OpenNET Project / Index page

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



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

Оглавление

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

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


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
Добавить, Поддержать, Вебмастеру