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)

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

Чем ему ReFS не угодил? Она еще моложе и там больше шансов проебать все полимеры

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

Nastishka с ЛОРа так сказала.

Ну что вы, мне просто повезло это в вики прочесть. https://en.wikipedia.org/wiki/Copy-on-write#In_computer_storage

Там понятным по белому написано «The original storage is never modified. When a write request is made, it is redirected away from the original data into a new storage area. (called «Redirect-on-write» or ROW)»

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

Теперь прочти по пунктам, обнови знания как делает снепшот лвм. Только внимательно и увидишь там ROW. Поверь, ты возьмешь слова обратно..

И тогда, если в ZFS был бы принцпи ROW ‘original storage is never modified’, то пул бы заполнялся до предела через какое то непродолжительное время имея на борту небольшое количество данных.

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

Не позволяет. md при чтении не сверяет контрольные суммы.

Ну здрасьте, как это md при чтении в RAID-конфигурации может не заметить искажения данных?

Вот это по нашему. Хочу батл «Должен ли raid заниматься тем, для чего он не задумывался и чего от него не требуется».

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

Этот mv вообще какой то сказочник

Сам-ты сказочник.

Это вполне себе нормалный «батл», потому что самой идее RAID сто лет в обед. Но чтобы присобачить проверку целостности к raid, не потерявь изначальных преимуществ raid - это достаточно сложная инженерная работа. Я не из таких, мне было бы интересно

anonymous
()

Зачем мне эта поделка от васяна линукс, если есть божественный Openindiana с ZFS?

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

Ну читай

Сам читал? Какие проблемы решает? Написано что создает дополнительные проблемы: основная - тесная интеграция с фс. Опять эта паранойя с чексуммой (sha), которая ничего не гарантирует, но преподносится как серебряная пуля. Ты тоже очередной проповедник чексумм?

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

Избыточность md позволяет на уровне пользователя не замечать искажение. Твои CRC в ZFS позволяются только иметь геморрой с разворачиванием бэкапа.

Мне важна также возможность отслеживать искажения и без избыточности.

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

А шифрование - это вообще ужас. Что будет, если ключ нечаянно испортится?

Бэкапы ключей же.

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

Одним неправильным битом угробили в десятки тысяч раз больше битов.

А надо было тихо мирно проглотить один испорченный бит? Например в бинарнике ядра и жить с этим дальше?

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

Целостность данных на диске должны гарантировать диски: диск либо работает полностью, либо не работает полностью.

Дооааа, хороший ты теоретег, а еще бывает третье состояние, когда ошибки видит только ZFS, собственно в этом-то и проблема аппаратных контроллеров.

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

Есть ли на вашем RAID контроллере батарея?

Разработчики ZFS гарантируют нормальную работу только при отключении write cache контроллера, так что батарейка ненужна.

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

не стоит перекладывать эту задачу на ЦП и основную память. Оно реально того не стоит.

Когда контроллер не справляется, то стоит, других вариантов собственно и не остается.

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

Это у вас на ZFS источник сильно фрагментированный, потому то по иному это порождение мутного гения не умеет.

ZFS с фрагментацией работает достаточно хорошо.

Фрагментация базы данных происходит из ее природы в том смысле, что запись идет в разные таблицы в разные записи.

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

Правда, такой не дает снапшотов.

LVM разве не снэпшотит?

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

Реплики же на других хостах: zfs send | ssh host2 «zfs receive»

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

А реплик нету?

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

Фрагментация базы данных происходит из ее природы в том смысле, что запись идет в разные таблицы в разные записи.

«Глубокое» понимание.

Владимир

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

Зачем мне эта поделка от васяна линукс, если есть божественный Openindiana с ZFS?

у ZFS on Linux 350 контрибьюторов, сколько у OpenZFS?

Даже фрюха стала брать код у Linux версии.

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

Ну конечно на это накладывается еще ZFS COW если база расположена ,например, на zvol.

Впрочем DB2 REORG решает проблему фрагментации базы достаточно хорошо.

zfs send | receive решает проблему сильной фрагментации ZFS после полугода-года ее использования (около 70-80%).

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

ext4, а если надо highload и бешеные размеры вместе с их перелопачиванием, то придумали HDFS и иже с ним, где у тебя не один комп, а много.

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

Разработчики ZFS гарантируют нормальную работу только при отключении write cache контроллера

а пруфы есть?

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

Сколько БП на ваших серверах?

Обычно сервера идут с 2-4 блоками, этого недостаточно?

А что один блок уже не подойдет для ZFS?

Память ECC? Если да, есть ли возможность memory mirroring?

Использую ZFS дома вообще без ECC уже на протяжении 8 лет, все нормально, не считая последние пару лет атаки на SATA канал, решаемых укорочением кабелей. Но такое происходило и на ECC сервере, так что для EMI атак фактор наличия ECC незначителен.

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

BTRFS и ZFS это НЕ CoW. Они RoW. Снапшоты LVM - это CoW

Я так понимаю, RoW — это типа «redirect on write»? Забавное замечание, но кому и где это вообще важно? Системы типа WAFL (btrfs, zfs, reiser4) во всём мире считаются разновидностью CoW.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от sky92

Теперь прочти по пунктам, обнови знания как делает снепшот лвм. Только внимательно и увидишь там ROW

В отличие от вас, я знаю как делает снапшот LVM. И делает он его классическим CoW (copy on write, точнее copy on first write), когда в снапшот записываются старые данные при первом их изменении.

И тогда, если в ZFS был бы принцпи ROW ‘original storage is never modified’, то пул бы заполнялся до предела через какое то непродолжительное время имея на борту небольшое количество данных.

Принцип ROW в том что, данные не перезаписываются in-place, а реализуется записью в свободное место, после чего ранее занятое объявляется свободным (или принадлежащим снапшоту, при необходимости).

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

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

А надо было тихо мирно проглотить один испорченный бит? Например в бинарнике ядра и жить с этим дальше?

Этот испорченный бит не в данных, а в чексумме, который приписала параноидальная фс.

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

еще бывает третье состояние, когда ошибки видит только ZFS

еще бывает такое состояние, когда ошибки приписыватся самим zfs.

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

До танцев на ушах с (i)SCSI я ещё не дорос. %)

А с моей точки зрения iSCSI очень полезен для повышения надежности реплицируемого псевдокластера на базе ZFS.

Берем два сервера backup1 и backup2.

На каждом из них, к примеру, 4 диска:

b1d1, b1d2, b1d3, b1d4

b2d1, b2d2, b2d3, b2d4

На сервере backup1 создаем пул Backup1:

mirror1: b1d1(локальный для backup1) + b2d1(по iSCSI с backup2)

mirror2: b1d2(локальный для backup1) + b2d2(по iSCSI с backup2)

На сервере backup2 создаем пул Backup2:

mirror1: b1d3(по iSCSI с backup1)+b2d3(локальный для backup2)

mirror2: b1d4(по iSCSI с backup1)+b2d4(локальный для backup2)

Пулы автоматически реплицируем по крону.

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

Этот испорченный бит не в данных, а в чексумме, который приписала параноидальная фс.

Ога, у ZFS постганстолкерский синдром Клерамба Кандинского.

Давайте, дружно отправить ZFS в психушку.

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

Давайте, дружно отправить ZFS в психушку.

Я психоаналитик в 4-ом или 5-ом (уже подзабыл) поколении.

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

еще бывает такое состояние, когда ошибки приписыватся самим zfs.

Может быть и бывают раз в сто (или миллиард) лет.

А бывает, что ZFS не видит никаких проблем годами, а потом внезапно 22 июня 2015 года опа на и ZFS видит сотни CRC всего за 1 день! на одном из SAS дисков, он начинает дико тормозить пул при этом.

SAS контроллер не видит ровным счетом ничего, т.е. рапортует, что все прекрасно.

Меняем диск, ZFS ресилверит пул целые сутки и потом опять полный штиль в zpool status.

ZFS - шиза, да? ведь он подлюка все испортил для вредителей, акт вредительства неудался, ах ах, как обыдна.

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

Системы типа WAFL (btrfs, zfs, reiser4) во всём мире считаются разновидностью CoW

Ну если рассматривать два случая - полную перезапись блока и частичную, то полная это чистый ROW, а частичная похожа на COW. Отсюда и путаница

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

SAS контроллер не видит ровным счетом ничего, т.е. рапортует, что все прекрасно.

Иногда сигара - это всего лишь сигара.

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

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

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

Этот испорченный бит не в данных, а в чексумме, который приписала параноидальная фс.

А это не важно. Вариантов тут два:

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

более сложное это определить через контрольную сумму контрольных сумм (дерево хэшей, которое насколько помню тоже есть в ZFS когда блоки в которых лежат хэши также накрываются хэшами и так итерационно, отчего получается дерево - на эту тему вроде даже кто то PhD делал) где ошибка - в данных или не только в данных. В любом случае скатывается всё в к первому варианту

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

Вот не пойму или лучше держать все 4 диска локально на каждом сервере?

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

более сложное это определить через контрольную сумму контрольных сумм (дерево хэшей,

И оказалось, что ошибка в корневой чексумме…

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

Вот что будет, если в такой схеме выйдет из строя, например, оперативка сервера backup1?

Судя по описаниям ZFS + bad RAM, тогда локальный пул Backup1 может сдохнуть целиком как на проблемном сервере backup1, так и на исправном backup2 (iSCSI блоки).

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

Значит, такая затея получается глупой?

Реплицируемые пулы нужно хранить полностью отдельно друг от друга, как я и делал ранее на работе, чтобы все их диски были локальными, рассчитывая на то, что в любой момент времени может сдохнуть сервер целиком вместе с пулом. Т.е. например, выход из строя RAM на сервере backup1 убъет пул Backup1, но при этом обе части зеркал пула Backup2 на другом сервере backup2 останутся целыми.

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

А вы психоаналитик по папе или по маме?

Как чексумма ляжет.

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

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

Ну мне лень, превозмогая специально для тебя:

Using a write-back is dangerous and puts your data at risk. Out-of-order execution of I/O may also cause corruption in case of a reset/crash; some newer I/O requests did make it to disk while some older I/O requests did not.

To use a controller safely with ZFS it needs to support BIO_FLUSH; write-back likely ignores these requests. Basically you’re playing with fire. You also lose most of the ZFS benefits, such as Self Healing and protection against BER/corruption. For all intents and purposes; ZFS treats your array as being non-redundant.

I’d say ZFS is one good example of how Software RAID can be superior to Hardware RAID in a fundamental level.

https://forums.freebsd.org/threads/raid-controller-cache-and-zfs.13720/

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