LINUX.ORG.RU

Линус Торвальдс высказался о ZFS

 , ,


4

5

В процессе обсуждения планировщиков ядра Linux пользователь Джонатан Данти пожаловался, что изменения в ядре сломали важный сторонний модуль — ZFS. Вот что написал в ответ Торвальдс:

Имейте в виду, что тезис «мы не ломаем пользователей» относится к программам пространства пользователя и к ядру, которое я сопровождаю. Если вы добавляете сторонний модуль вроде ZFS, то вы сами по себе. У меня нет возможности поддерживать такие модули, и я не отвечаю за их поддержку.

И, откровенно говоря, я не увижу ни одного шанса на включение ZFS в ядро, пока не получу официальное сообщение от Oracle, заверенное их главным юрисконсультом или, лучше всего, самим Ларри Эллисоном, в котором говорится, что всё ок, и ZFS теперь под GPL.

Некоторые думают, что добавить код ZFS к ядру — неплохая идея, и что интерфейс модуля нормально с этим справляется. Что ж, это их мнение. Я же не чувствую такое решение надёжным, учитывая спорную репутацию Oracle и проблемы, связанные с лицензированием.

Поэтому мне абсолютно неинтересны штуки вроде «слоёв совместимости ZFS», которые, как некоторые думают, изолируют Linux и ZFS друг от друга. Нам от этих слоёв никакой пользы, а учитывая склонность Oracle судиться из-за использования их интерфейсов — я не думаю, что это реально решает проблемы с лицензиями.

Не используйте ZFS. Вот и всё. По-моему, ZFS это больше баззворд, чем что-то ещё. Проблемы с лицензированием — только ещё одна причина, почему я никогда не стану заниматься этой ФС.

Все бенчмарки производительности ZFS, что я видел, совершенно не впечатляют. И, как я понимаю, ZFS уже даже толком не сопровождается, и никакой долгосрочной стабильностью здесь не пахнет. Зачем вообще её использовать?

>>> Подробности

Deleted

Проверено: a1batross ()
Последнее исправление: Deleted (всего исправлений: 1)

Ответ на: комментарий от mv

В миллионы!

Пожалуй соглашусь, вполне реальная оценка для некоторых случаев с огромным количеством мелких файлов.

Кластеры-шмастеры… Видишь, ты уже внутренне согласился, что ZFS для надёжности нужен какой-то HA.

Так это нужно для любой системы, не только файловой.

В облаке, в самом низу, есть такое понятие, как минимальный blast radius. Идеально, когда всё работает в пределах одного гипервизора и ни от чего не зависит, чтобы когда он упадёт, то вокруг ничего другого не сломалось.

Пожалуйста, попо дробнее. Когда упадет гипервизор без HA, то виртуалки внутри него сломаться не должны?

a_buchinskiy
()
Ответ на: комментарий от a_buchinskiy

Я уже объяснял, что при EMI атаке ни контроллер ни диск не в состоянии полностью уследить за целостностью, даже промышленный SAS. ZFS может (точно проверенно).

Прими уж таблеток и почитай про SerDes, Соломон-Рида и прочие основы защиты данных. Нарушение целостности в железе системах хранения данных происходит примерно постоянно.

mv ★★★★★
()
Ответ на: комментарий от burato

Ну как бы это и подразумевалось под спектрумом в отличии от IntelME в глубоком бункере :)

a_buchinskiy
()
Ответ на: комментарий от mv

Лучше объясни в кратце, что ты имел ввиду.

Я тебе пишу о том, что наблюдал в своей практике.

Зачем мне твой Соломон, если ZFS рапортует, что он облажался?

a_buchinskiy
()
Ответ на: комментарий от splinter

Что-то вроде «вау-словечка». Типа: «ну ты и лошара, у тебя смартфон прошлого поколения, а у меня последний Сяоми с нейросетями!». «Нейросети» в данном случае - баззворд.

Deleted
()
Ответ на: комментарий от a_buchinskiy

Пока

ZFS рапортует, что он облажался

нормальные системы хранения просто исправляют ошибки.

Вопрос. Вот тебе zfs раопротовал, что облажался, и что ты сделаешь? Выйдешь в окно?

Чексуммы на уровне файловой системы - это паранойя, не имеющая под собой никакого основания.

anonymous
()
Ответ на: комментарий от anonymous

Чексуммы на уровне файловой системы - это паранойя, не имеющая под собой никакого основания.

Слова дурачка любителя NTFS!

нормальные системы хранения просто исправляют ошибки.

Как и ZFS

deadplace
()
Ответ на: комментарий от anonymous

Все, что мешает вредить ганстолкерским бандитам - шиз и паранойя.

a_buchinskiy
()
Ответ на: комментарий от deadplace

Чексуммы на уровне файловой системы - это паранойя, не имеющая под собой никакого основания.

Слова не дурачка, а троля :)

a_buchinskiy
()
Ответ на: комментарий от deadplace

нормальные системы хранения просто исправляют ошибки.

Как и ZFS

И как он это делает? Чексуммы не могут корректировать ошибки. Для коррекции ошибок применют что-то другое, например, коды коррекции ошибок Рида-Соломона.

Слова дурачка любителя NTFS!

Слова безмозглого фанатика, умеющего только в громкие базворды.

anonymous
()
Ответ на: комментарий от anonymous

Вопрос. Вот тебе zfs раопротовал, что облажался, и что ты сделаешь?

Предприму меры: укорочу кабели диска, сделаю клон последнего целостного снэпшота, попытаюсь сделать на него rsync –checksum последнего состояния из текущей FS, почти всегда проходит удачно. Проверю какие файлы изменились с момента последнего целостного снэпшота, если какие-то важные типа Outlook или базы данных, то прогоню проверку целостности внутри приложения.

Кому-то достаточно и вовсе rollback

Выйдешь в окно?

Выйдет в окно тот, данные кого не были защищены ZFS. Он будет гадать какие его файлы изгажены всю оставшуюся до окна жизнь.

a_buchinskiy
()
Ответ на: комментарий от anonymous

И как он это делает? Чексуммы не могут корректировать ошибки. Для коррекции ошибок применют что-то другое, например, коды коррекции ошибок Рида-Соломона.

В ZFS возможно дублирование дисков даже 3x и наверно больше.

Кроме того даже на одном диске можно указать количество хранимых копий одинаковых блоков больше одной.

a_buchinskiy
()
Ответ на: комментарий от a_buchinskiy

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

a_buchinskiy
()
Ответ на: комментарий от e7z0x1

Про оффлайновую я знаю, но это не сильно подходит для ситуации если сервер перегружается достаточно редко.

Оффлайн, это не означает, что нужно отмонтировать.

aidaho ★★★★★
()
Ответ на: комментарий от a_buchinskiy

Предприму меры: укорочу кабели диска…

Слова админа подкроватного сервера, и то неудавшегося.

Выйдет в окно тот, данные кого не были защищены ZFS.

И как защитил zfs твои данные? Бекап в другой системе - это не заслуга облажавшегося zfs. Ах да, с таким же успехом твой бекап может оказаться в другой облажавшейся zfs.

anonymous
()
Ответ на: комментарий от aidaho

Если это снапшоты, то нещитово.

Если быть точным, то отправленный на другой компьютер снапшот имеет право называться бэкапом. Но у меня обычные резервные копии, borg и rsync.

anonymous
()
Ответ на: комментарий от anonymous

И как он это делает? Чексуммы не могут корректировать ошибки. Для коррекции ошибок применют что-то другое, например, коды коррекции ошибок Рида-Соломона.

Из RAID или копий

deadplace
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от a_buchinskiy

В ZFS возможно дублирование дисков даже 3x и наверно больше.

Дублирование с чексуммами не дает никакой предсказуемой гарантии и даже может существенно испортить данные при коллизии чексуммы.

В то время, например, коды Рида-Соломона гарантируют, какие ошибки могут определить и какие - исправить.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

ЯННП, что ты несёшь, но это не имеет отношения к сетям и кластерам, ты просто не в курсе, что такое send/receive. Их можно делать хоть в локальный файл / из файла.

anonymous
()
Ответ на: комментарий от anonymous

Что не доказывает, что я не прав. Посылать можно хоть в виртуалку. Что такое слать/получать понимают не только якобы крутые админы с бородой.

anonymous
()
Ответ на: комментарий от anonymous

Дублирование с чексуммами не дает никакой предсказуемой гарантии и даже может существенно испортить данные при коллизии чексуммы.

Если выбрать сложный хэш для чексумм (не CRC32), то представь какая вероятность сбоя? 1 раз в миллиард лет?

Ну предположим произошла коллизия, пострадал один бэкап и внезапно именно нужный нам! (невероятно? но допустим).

Потеряли ли мы данные? Конечно нет, а почему? А потому что мы еще храним и архивные логи базы данных на другом ZFS хранилище без дедупликации.

Так, и что же мы делаем при невероятном сбое?

Восстановимся из более раннего бэкапа, и накатим на него архивных логов не за полдня, а за полтора. Дольше? - конечно, но данных мы не потеряли. А экономия от дедупликации бэкапов DB2 огромна!

a_buchinskiy
()
Ответ на: комментарий от anonymous

Что не доказывает, что я не прав.

Просто твои заявления нерелевантны, безотносительно их корректности.

anonymous
()
Ответ на: комментарий от a_buchinskiy

Причем экономия не раз в миллиард лет, а ежедневная на объем базы данных. Записывается дедуплицированный бэкап ессно тоже быстрее, потому что он почти не пишет :)

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

a_buchinskiy
()
Ответ на: комментарий от kott

Это было логичное, пусть и ошибочное, предположение. ☺

mord0d ★★★★★
()
Ответ на: комментарий от a_buchinskiy

А как же мы определим наличие коллизии? Ах да, DB2 ведь тоже хранит свои собственные чексуммы, вот так-то.

a_buchinskiy
()
Ответ на: комментарий от a_buchinskiy

Если выбрать сложный хэш для чексумм (не CRC32), то представь какая вероятность сбоя? 1 раз в миллиард лет?

Слова академика выдуманной академии паранормальных наук.

Прежде чем считать вероятности надо либо собрать статистику (которой у тебя нет, так как у тебя даже рабочего подкроватного сервера нет), либо теоретически вывести (этой теории у тебя тоже нет, потому что ты даже не выдуманный академик).

anonymous
()

что опять? а так нахваливали...

amd_amd ★★★★★
()
Ответ на: комментарий от anonymous

Ну я лично наблюдал, как 22 июня 2015 года на сервере Kraftway относительно дорогой на момент его покупки RAID контроллер Adaptec SAS не видел никаких проблем со своими дисками, а ZFS заметила CRC ошибки на одном из vdev одного из zmirror.

Я заменил диск, после resilvering стало все хорошо.

Потери данных не было, несмотря на то, что контроллер облажался, диски были отдельным массивами с точки зрения Adaptec.

a_buchinskiy
()
Ответ на: комментарий от a_buchinskiy

Увеличиваем длину хэша по максимуму.

Что дает увеличение члена хеша?

Чисто теоретический эксперимент.

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

anonymous
()
Ответ на: комментарий от a_buchinskiy

Причем до этого ZFS отработал на этом сервере полтора года без каких либо замечаний в zpool status.

a_buchinskiy
()
Ответ на: комментарий от intelfx

В смысле не умение? По дефолту динамический.

anonymous
()
Ответ на: комментарий от anonymous

которые миллиарды лет считал за миллирад шекелей в день?

Ну если ты такой богатый писатель фантаст, то наверно, найдешь пару копеечек деньжат (на фоне твоей вселенской задачи) закинуть их в проект ZFS on Linux, чтобы персонально для тебя туда впилили новые алгоритмы супердлинных хешей на фоне которых вероятность коллизии за миллиард лет померкнет и тебе придется работать уже на периодах миллиард в сотой степени лет?

a_buchinskiy
()
Ответ на: комментарий от anonymous

При коллизии чексуммы между живой копией и случайно испорченной? Не смеши.

intelfx ★★★★★
()
Ответ на: комментарий от anonymous

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

Нулевая. ZFS не content-addressable, коллизии там у тебя или нет — это вообще не важно. Хеши там используются для того, чтобы отличить живую копию блока от испорченной, а не для того, чтобы отличить один файл от другого.

intelfx ★★★★★
()
Ответ на: комментарий от anonymous

Просто твои заявления нерелевантны, безотносительно их корректности.

По-русски не способен уже? Ты о чем там вообще?

Цитируем википедию

(англ. relevance — актуальность, уместность)

Релева́нтность в информационном поиске — семантическое соответствие поискового запроса полученному документу.

Существует несколько подходов к оценке релевантности. Содержательная релевантность — соответствие ответов информационному запросу, определяемое неформальным путём. Формальная релевантность — соответствие, определяемое путём сравнения образа поискового запроса с поисковым образом ответа по определённому алгоритму.

Цели и средства должны соответствовать и никто в здравом уме не будет форсировать установку ZFS или жестких дисков в одноплатные компьютеры с 256 мегабайтами оперативной памяти. Область применения данной файловой системы не ограничена одним компьютером. А ее инструменты позволяют организовать бесперебойную работу без вмешательства непосредственно в организацию копирования данных куда-либо. Вот представь себе поток данных какой-нибудь сотовой компании. Количество различных атак и количество администраторов готовых эти проблемы решать круглосуточно. Они контейнерами закупали всякие сервера. А ты тут про релевантность учудил. Где же все эти якобы супер профи руками решающие каждую проблему? Тут понтов у каждого с гору. Только они не могут внятно ничего доказать. Потому что не по месту обсуждают применение файловой системы локально. Всю эту чушь оставь девочкам ничего не понимающим в информационных технологиях.

anonymous
()
Ответ на: комментарий от anonymous

ZFS

Да ты задрал со своей ZFS.

По-русски не способен уже?

Задай этот вопрос себе, а потом найди, где я говорил о ZFS.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.