The OpenNET Project / Index page

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



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

Оглавление

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

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


32. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +2 +/
Сообщение от менеджер отдела везения (?), 01-Дек-23, 11:10 
вы наняты!
Ответить | Правка | Наверх | Cообщить модератору

35. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Аноним (6), 01-Дек-23, 11:16 
просто дай мильён баксов, а то опять работать заставляешь
Ответить | Правка | Наверх | Cообщить модератору

58. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от User (??), 01-Дек-23, 11:53 
> вы наняты!

Или я просто звИзд0б0л. Или этих данных у меня было 2,5 байта - поставил на виртуалку, выключил\включил - ничего и не потерялось. Или... да много чего "или".
Абсолютизировать свой, скорее всего, нерепрезентативный личный опыт - невеликого ума занятие.

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

73. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –1 +/
Сообщение от Аноним (24), 01-Дек-23, 13:14 
Ну почему же, просто не стоит говорить за всех. Это невеликого ума занятие. Вот лично я испытал куда больше повреждений ext4, чем 100% прочих пользователей ext4. И в процессе экспериментов, и в процессе тестирования, и в процессе использования в самых разных условиях. Даже обнаружил, что существуют странные баги, которые почему-то осознанно игнорируются десятилетиями. Но потери данных вещь достаточно невероятная (хотя и реалистичная), в основном, из-за новых багов ядра можно ожидать. Самое страшное -- это повреждение журнала, при этом структуры окажутся повреждены совершенно непредсказуемо, и проверка fsck займёт достаточно много времени (ещё и несколько раз перезапустится в процессе). А вот с xfs у меня терялись данные, например, хотя большинство её поклонников будут уверять, что это невозможно (несмотря на официально регулярно повторяющиеся ситуации с потерями файлов). Правда, файловые системы без fsck… Нет, не стоит.
Ответить | Правка | Наверх | Cообщить модератору

80. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –1 +/
Сообщение от User (??), 01-Дек-23, 13:38 
>[оверквотинг удален]
> и в процессе использования в самых разных условиях. Даже обнаружил, что
> существуют странные баги, которые почему-то осознанно игнорируются десятилетиями. Но
> потери данных вещь достаточно невероятная (хотя и реалистичная), в основном, из-за
> новых багов ядра можно ожидать. Самое страшное -- это повреждение журнала,
> при этом структуры окажутся повреждены совершенно непредсказуемо, и проверка fsck займёт
> достаточно много времени (ещё и несколько раз перезапустится в процессе). А
> вот с xfs у меня терялись данные, например, хотя большинство её
> поклонников будут уверять, что это невозможно (несмотря на официально регулярно повторяющиеся
> ситуации с потерями файлов). Правда, файловые системы без fsck… Нет, не
> стоит.

Уф. Оценить "репрезентативность выборки" и "релевантность условий" на основании собственного опыта примерно "нельзя". Как соотносятся "надежность ФС" на физическом сервере в кладовке под нагрузкой "аждымицца!" и надежность той же самой ФС на виртуалке в ЦОДе в составе LB-кластера с автомасштабированием? Да никак не соотносится - в одном случае может регулярно сыпаться с последствиями, в другом - стабильно работать годами.
В общем случае - "надежность работы ФС" оказывает не то, чтобы большое влияние на надежность хорошо спроектированной _системы_. Ну вот заглючил на СХД два месяца назад FC-порт - расфигачило SQL-сервер с 10 Тб данных - повлияло это на работу системы? Да нет, автоматом переключилось на другую геореплику, пересоздали виртуалку, залили бэкап, догнали лог - и даже не уверен, переключили ли нагрузку обратно. Чем\как бы тут помогла btrfs, fsck или другая абэвэгэдэ?
Не то, чтобы мне было "совсем пофиг" на "надежность ФС" при проектировании ИС - но "примерно пофиг", да. Даже в отдельную строчку модели угроз не выделяем идет в составе "вероятность выхода из строя узла" или как-то так.

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

82. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +1 +/
Сообщение от Аноним (24), 01-Дек-23, 13:44 
Я конечно понимаю желание отдельных индивидов игнорировать проблемы, заваливая их деньгами (и резервированием), но, что случится, когда автоматика подведёт? А это произойдёт, рано или поздно.
Ответить | Правка | Наверх | Cообщить модератору

84. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от User (??), 01-Дек-23, 13:55 
> Я конечно понимаю желание отдельных индивидов игнорировать проблемы, заваливая их деньгами
> (и резервированием), но, что случится, когда автоматика подведёт? А это произойдёт,
> рано или поздно.

Ну, примерно то же, что и в этом тредике с ZFS и чексуммами, которые вот беда-то! Внизапна! нипамагли, хотя казалось бы. Пойду бэкап поднимать - а вам с верой в "надежные-фс-и-чексуммы" ну... удачи, что ли.

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

87. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Аноним (24), 01-Дек-23, 14:12 
Бтрфс всё же имеет определённые преимущества. Если говорить о хешировании, то это незначительный сайд-эффект, однако, именно он позволяет обнаружить проблему раньше конкурентов (и во многих случаях избежать потери данных). Могут быть даже ситуации, когда при разрушении проедет гораздо дольше конкурентов (сохраняя фактическую исправность). До тех пор, пока по какой-либо причине не посыпется сама фс, тут уже как повезёт.
Ответить | Правка | Наверх | Cообщить модератору

94. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от User (??), 01-Дек-23, 14:59 
> Бтрфс всё же имеет определённые преимущества. Если говорить о хешировании, то это
> незначительный сайд-эффект, однако, именно он позволяет обнаружить проблему раньше конкурентов
> (и во многих случаях избежать потери данных). Могут быть даже ситуации,
> когда при разрушении проедет гораздо дольше конкурентов (сохраняя фактическую исправность).
> До тех пор, пока по какой-либо причине не посыпется сама фс,
> тут уже как повезёт.

Да - но так же и определенные недостатки в виде пригодности COW-семантики к ряду нагрузок. Плюс, если говорить за энтерпрайз и коммерческий саппорт - то тут будут играть роль дефолты базовой ОС и непосредственные рекомендации вендора ПО. Опять же, общий дизайн системы... я более, чем уверен, что facebook сделал правильный выбор... для facebook'а, и совершенно убежден, что пытаться повторять куски его технических решений у себя мне не следует :).
Как-то так.

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

214. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  –1 +/
Сообщение от Аноним (110), 02-Дек-23, 16:30 
Ну что вы, черт побери, такое несете?! Если Facebook использует BTRFS у себя в проде - это высокая гарантия качества этой файловой системы при любом применении и нагрузках! В самом деле, как дети...
Ответить | Правка | Наверх | Cообщить модератору

216. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +1 +/
Сообщение от User (??), 02-Дек-23, 17:27 
> Ну что вы, черт побери, такое несете?! Если Facebook использует BTRFS у
> себя в проде - это высокая гарантия качества этой файловой системы
> при любом применении и нагрузках! В самом деле, как дети...

Охтыж. Знаменитая "экспертиза opennet" in action. Или система спроектирована таким образом, что на сохранность данных каждой конкретной ноды настолько "пофиг", что просто "пофиг" - а вот дедуп экономит вполне реальные деньги. Пуркуа бы не па...

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

226. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Аноним (110), 03-Дек-23, 03:33 
Мне следовало добавить плашку "Сарказм"?
Ответить | Правка | Наверх | Cообщить модератору

239. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от User (??), 03-Дек-23, 12:10 
Капсом. И джва раза - для тех, которые "Я" :)
Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

243. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Аноним (110), 03-Дек-23, 13:45 
Каюсь. Не распознал... видимо, из-за того, что крепко-крепко приболел. Так себе "отмазка", но хотя бы является правдой.
Ответить | Правка | К родителю #239 | Наверх | Cообщить модератору

270. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от edo (ok), 04-Дек-23, 10:11 
> Ну, примерно то же, что и в этом тредике с ZFS и
> чексуммами, которые вот беда-то! Внизапна! нипамагли, хотя казалось бы.

А что тут странного? Чексуммы — не серебряная пуля, ошибки в реализации фс они, очевидно, не могут исправить.
Зато ошибки в железе/прошивках они обнаруживают, а зачастую и дают исправить

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

336. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Tron is Whistling (?), 06-Дек-23, 09:25 
Ахтунг, чексуммы научились исправлять баги в прошивках!!!111
Ответить | Правка | Наверх | Cообщить модератору

342. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от edo (ok), 06-Дек-23, 11:10 
> Ахтунг, чексуммы научились исправлять баги в прошивках!!!111

исправлять баги — нет, конечно.
испралять data corruption, вызванные (в том числе и) багами в прошивке за счёт чексум и избыточности — да. и одной избыточности тут недостаточно, в случае с raid 1, например, мы можем только узнать что копии расходятся, но не можем сказать какая верная. то же самое и с raid 5.
raid 6 теоретически может исправить ошибку, но только пока он не в degraded состоянии.

у zfs таких ограничений нет, всегда можно сказать верна ли запись на конкретном диске или нет (и, более того, за счёт merkle tree можно сказать актуальная она или нет; если нет, то можно откатить фс в предыдущее консистентное состояние)

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

356. "Обновление OpenZFS 2.1.14 и 2.2.2 с устранением ошибки, прив..."  +/
Сообщение от Аноним (-), 08-Дек-23, 15:28 
> в случае с raid 1, например, мы можем только узнать что
> копии расходятся, но не можем сказать какая верная. то же самое
> и с raid 5. raid 6 теоретически может исправить ошибку, но только пока он не в
> degraded состоянии.

Во, edo понял трабл - и чем райд+чексум лучше чем просто raid. Но в размазанном на layer'ы дизайне оно, вероятно, в self heal вообще не смогет. Инфо на стыке layer'ов потеряется - и упс, то что btrfs делает в крейсерском режиме, вообще не требуя конфигурации, вон там - жуткий рокетсайнс - если возможно вообще. Пусть этот свистун и пользуется такими технологиями сам.

> можно сказать актуальная она или нет; если нет, то можно откатить
> фс в предыдущее консистентное состояние)

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

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

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

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




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

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