The OpenNET Project / Index page

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



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

Оглавление

Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD, opennews (??), 07-Янв-21, (0) [смотреть все]

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


36. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  –4 +/
Сообщение от Кир (?), 07-Янв-21, 17:44 
ZFS нужна ECC память для надежной работы.
Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Онаним (?), 07-Янв-21, 19:00 
ECC память, ECC на всех внутренних шинах и т.п.
Сферическая ситуация в вакууме, для которой существует специальное железо.
В общем же случае что ZFS, что RAID с чётностью - один фиг.
Ответить | Правка | Наверх | Cообщить модератору

50. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +2 +/
Сообщение от Онаним (?), 07-Янв-21, 19:03 
Упреждая "онашазфстакаясквозноцелостная" - в 99% реальных случаев данные будут повреждены ещё _до_ записи. И запишутся уже повреждёнными. Со "сквозной целостностью", угу.

А от повреждения данных на дисках и шинах к таковым RAID с двойной чётностью допустим страхует достаточно.

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

123. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Аноним (-), 09-Янв-21, 19:19 
Эксперименты с btrfs показали что таки тот неплохо детектит идиотские взбрыки железа и даже ухитряется более-менее чинить все это из второй копии, если она есть. Прикол ситуации в том что так оно загаживается намного медленнее чем ФС с одной копией данных/метаданных, ухитрившись заметить и парировать порядочно сбоев железа. Хоть это и без гарантий совершенно.
Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +4 +/
Сообщение от xm (ok), 08-Янв-21, 02:03 
Любой файловой системе нужна ECC для надёжной работы. Просто другие об этом не пишут.
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

121. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  –1 +/
Сообщение от Аноним (-), 09-Янв-21, 19:16 
> Любой файловой системе нужна ECC для надёжной работы. Просто другие об этом
> не пишут.

А какой смысл им об этом писать? EXT4 без полного журнала вообще плевать хотел что там с данными случится при крахе. А раз так какой смысл париться ECC памятью? :)

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

139. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от пох. (?), 09-Янв-21, 20:03 
> А какой смысл им об этом писать? EXT4 без полного журнала вообще
> плевать хотел что там с данными случится при крахе. А раз
> так какой смысл париться ECC памятью? :)

такой, что, внезапно, она не от крахов, а от штатной записи мусора вместо данных или метаданных.

От крахов в ext4, внезапно, fsck.

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

147. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Аноним (-), 09-Янв-21, 20:22 
> такой, что, внезапно, она не от крахов, а от штатной записи мусора
> вместо данных или метаданных.

А смысл улучшать на полшишечки EXT4 который на integrity данных заведомо клал? Блин, да даже с RAID если у тебя копии разойдутся ты даже не узнаешь какая из них правильная. Чего хочешь - то и делай. Btrfs скажет csum error, corrected и поедет дальше. Посмотрев по чексумме какая из копий правильная. Так прикольнее.

> От крахов в ext4, внезапно, fsck.

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

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

206. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  –1 +/
Сообщение от пох. (?), 11-Янв-21, 09:26 
> Btrfs скажет csum error, corrected и поедет дальше. Посмотрев по чексумме какая из копий
> правильная.

а обе неправильные. Потому что чексумма посчитана по уже битому блоку. Или, еще смешнее - блок не битый, битик уплыл в чексумме. И так и записался, разумеется, обоими копиями.

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

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

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

Впрочем, как там ниже некоторые убедились, оно примерно этим и кончается, если уж дело дошло до btrfsck.

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

278. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Онаним (?), 15-Янв-21, 20:39 
RAID с чётностью внезапно тебе вообще ничего не скажет.
Просто пофиксит кодом коррекции, и всё.
Узнаешь в логах.
Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

153. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от псевдонимус (?), 09-Янв-21, 20:47 
>> Любой файловой системе нужна ECC для надёжной работы. Просто другие об этом
>> не пишут.
> А какой смысл им об этом писать? EXT4 без полного журнала вообще
> плевать хотел что там с данными случится при крахе. А раз
> так какой смысл париться ECC памятью? :)

Что ты несёшь? Ецц нужна чтобы мусор вместо данных не записывался.

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

182. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Аноним (181), 10-Янв-21, 03:43 
> Что ты несёшь? Ецц нужна чтобы мусор вместо данных не записывался.

Если ФС может данные профакать без ложной скромности, поскольку EXT4 видите ли не парится о довольно большом количестве проблем ведущих к порче данных - смысл платить за ECC достаточно маргинальный. Это заткнет один путь разрушения данных а еще куча останется.

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

Или если был супер-дупер RAID но диск вместо того чтобы скопытиться совсем бэды изволил выдать с мусором - как определить которая копия вообще правильная? Теоретически, конечно, гад должен IO error (UNC) наверх пульнуть, но практически это зависит от приколов его фирмвари и бывает весьма по разному. От ухода в себя на неопределенное время до тихой отгрузки наверх какой-то трухи, возможно лобового результата чтения как есть, с пофигом что FEC не сжевал столько и это труха.

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

207. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от пох. (?), 11-Янв-21, 09:43 
> Ну например EXT4 с полным журналом тормозной как слоупок. А без него - вырубленая на середине
> запись оставит полуперезаписаный файл, который ни вперед, ни назад. И чего потом с ним делать?

Удалить, заново начать работать с резервной копией. Все равно неизвестно, что там записалось, а что нет. Я понимаю, гораздо приятнее и проще когда за тебя его удалит и вернет к предыдущей копии чудо-fs, но, к счастью, юниксный софт и так обычно неплохо справляется - пока не изуродовали.

> практически это зависит от приколов его фирмвари и бывает весьма по разному.

практически я за очень уже немалую профессиональную жизнь видел ровно два варианта - диск дохлый, сразу же возвращается ошибка, и диск уходит в себя, хорошо если ненадолго, прежде чем вернуть ошибку. От второго не помогают даже энтерпрайзные контроллеры и энтерпрайзные диски с управляемым tler.
Очень занятно, что (поскольку чудо-fs в линухе никогда не знают, что там ниже - то ли диск, то ли высокоуровневая херня типа lvm, то ли md, то ли ентер-прайсный контроллер и ничего не могут с этим сделать) обработка этих событий сделана у вас на от...сь, и единственный способ помочь системе - выдрать диск на ходу, смотри не перепутай, какой.

(В zfs все еще смешнее, придет deadman и вызовет kernel panic. Чую я тут лапы девляпсов, непривычных ни в чем разбираться, и "некогда читать всякую муру на консоли, работать надо", но лень искать первоисточник.)

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

228. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Онаним (?), 12-Янв-21, 10:20 
В общем случае достаточно ordered при рабочем механизме write barrier.
Перезаписывать файлы по частям вообще так себе затея, и те, кому это реально нужно (СУБД и т.п.) - ведут свои собственные журналы так, как им надо и им оптимально. Этим достаточно только собственно наличия или отсутствия записи.

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

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

236. "Выпуск OpenZFS 2.0.1, реализации ZFS для Linux и FreeBSD"  +/
Сообщение от Онаним (?), 12-Янв-21, 10:42 
(да, старые данные с CoW - возможно - найти ещё можно, но вот какой конкретно чекпоинт искать у софта, который сделал 100500 write'ов по 4K в этот файл, и на 100501 из 1005000 обломался - это уже для ниндзя)
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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