LINUX.ORG.RU

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

 , , ,


3

4

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

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

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

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

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

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

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

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

Deleted

Проверено: a1batross ()

Re: Что-то мне подсказывает, что товарищ mv криворук

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

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

Ну короче да, полезна она, но для чего-то специфического, а оперативы хочет много

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

Снэпшоты ZFS прекрасно переживают EMI атаки, что изрядно подбешивает ганстолкерских бандитов.

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

Только для метаданных.

Не совсем так,да это относят к метаданным но частично покрываються и данные Смотрим .https://www.opennet.ru/opennews/art.shtml?num=33996
и видим > рассчитываются для суперблока, inode, битовых карт блоков, блоков дерева экстентов, htree-узлов, MMP-блоков, директорий и блоков с расширенными атрибутами.

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

Бывает, что несколько достаточно разных веток одного проекта живут (в разных организациях) и, тем не менее, постоянно синхронизируются друг с другом. Это называется merge-friendly.

вот индиана, openzfs и zol по этому принципу и существовали:)

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

Ну короче да, полезна она, но для чего-то специфического, а оперативы хочет много

У меня на рабочей станции с Core2Duo - 6ГБ RAM!

ZFS уживается с TrinityDE на хосте и несколькими тяжелыми браузерами, запущенными в виртуалках KVM и это даже БЕЗ SSD свопа на хосте. +Еще аутглюк в WINE и куча других программ.

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

Издеваюсь над фанатиками, слежу за скатыванием Линукс-десктопа и просто весело провожу время, конечно же.

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

Данных в списке нет. Как только в ext4 или XFS появляются контрольные суммы данных — я тут же выкидываю Btrfs без раздумий, чесслово. Ну или когда будет более искоробочная поддержка dm-verity (хватит и режима без двойной записи в паре с dm-crypt, пока он только «отдельно», как я понимаю из документации).

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

Кодируй данные в base64 и записывай в имена каталогов.

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

Спасибо, но мой мозг ещё не разъело постоянным ЭМ-облучением.

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

А что нитак?

Если производительность ZFS+ext4/XFS, то скорее всего ты просто не умеешь ее готовить.

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

И — изобретательность!

Кроме шуток, идея забавная и даже можно найти под неё сценарии. Но если сходить с ума, то практичнее будет использовать пустые файлы с сохранением данных в xattr.

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

Где в этом перечне данные?

Я же не говорю что данные под контрольной суммой,но если размер файла -метаданные c информацией про иноды с контрольной суммой не совпадает это не говорит что с файлом что то не ладно?В inode тоже же информация о файле содержиться.У меня бывает редко очень что в логах пишет что чек сумма не совпадает, данные восстановлены.

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

Ну у меня на нетпуке она стоит (по дефолту), а там 2 Гб. Просто prefetch не работает. Но речь-то про дебубликацию. Как ты говоришь, хороша она только при каком-то специфическом шаблоне использования

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

размер файла

В типичном сценарии с bit rot размер не меняется.

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

Стоит проверить оперативную память и SMART накопителей, в норме такого быть не должно.

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

виртуалка с виндовозом 10(не бейте, по работе нужна)

(не бейте, по работе нужна)

Нахрена ты оправдывается?

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

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

8 гиг рама было очень мало после накопления дедупнутых бэкапов за несколько месяцев, чтобы хотя бы удалить старые снэпшоты, проще было раз в полгода скопировать инкремент датасета и грохнуть старый пул, чем дожидаться удаления снэпшотов и даже сервер подвисал при попытке удаления дедупнутых снэпшотов, но это был еще старенький ZFS v0.6.x

Думаю, с 36-128 гига под дедупный пул было бы вполне комфортно на моих задачах.

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

Информация о файле это и есть метаданные

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

а веб разрабам нынче пофиг на память юзеров

Уволил бы их всех как профнепригодных. Но, к сожалению, профстандарты им устанавливают такие же профнепригодные деятели.

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

dm-verity

То есть dm-integrity, никогда не перестану путать.

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

Ну тебе пытаются объяснить, что остается 99% случаев, когда твои данные на ext4 могут крякнуть и ты даже этого сразу не заметишь, а когда заметишь, то будет уже очень поздно.

Кроме того, увидев такие сообщения на твоем месте я бы срочно переходил на ZFS или хотябы на Btrfs, чтобы не остаться в один «прекрасный» момент с разбитым корытом и осознать это только через полгода-год.

Причиной потери данных может быть даже длина SATA кабеля и электромагнитная обстановка в твоем помещении. Контроллеры и SMART к сожалению такие ошибки частенько пропускают, а ZFS их отлавливает.

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

Кроме того, увидев такие сообщения на твоем месте я бы срочно переходил на ZFS или хотябы на Btrfs

Спасибо, уже покушал Btrfs, только чтение.Все утилиты для восстановления тупо падают в сегмент корку......
Я же говорю это очень редко пишеться, смарт нормальный.Я считаю что самая надежная файловая система для важных тебе данные -3 копии на разных носителях, не разу еще не подводила :-).для особоважные данные архив с избыточными данными для восстановления или iso образ.

maximnik0 ★★ ()
Последнее исправление: maximnik0 (всего исправлений: 1)
Ответ на: комментарий от a_buchinskiy

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

man duplicity. Прекрасно работает с любой линуксовой ФС общего назначения. Но т.к. у меня дома надёжные технологии в виде md, dm и ext4, то нужды восстанавливать не было. Так, пару раз выдёргивал кое-чего, потерянное в приступах админского энтузиазма.

mv ★★★★★ ()

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

#артемийлебелевпукнул

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

Я считаю что самая надежная файловая система для важных тебе данные -3 копии на разных носителях, не разу еще не подводила :-).для особоважные данные архив с избыточными данными для восстановления или iso образ.

Только уследить за их целостностью без ZFS нереально, поэтому все то, что ты написал, но еще и с ZFS.

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

Только для метаданных. Контрольные суммы для данных есть только в Btrfs.

А ещё есть диски с поддержкой контрольной суммы вообще для всего. Те, которым сектор на 520 байт надобно форматировать. Обычно такие диски раздаются с предлагаемых тут чёрных ящиков за полмиллиона.

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

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

duplicity - это что-то похожее на rsync?

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

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

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

Покажи на кукле, куда инопланетяне нарушали твою целостность

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

С zfs все понятно, а что скажите про xfs. Как оно?

Сейчас не знаю, 15 лет назад на куче дикого китая выживало хуже, чем ext3 :) Опять же, статистика, никаких эмоций. xfs нам очень хотелось использовать, т.к. ext3 тормозила, но слишком уж часто потери данных случались.

Потом, ЕМНИП, xfs таки починили. Но я её, честно, 15 последних лет не использовал.

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

На крупных объемах, такой дублизити может бэкапить часами

Упирается в скорость накопителя.

в то время как ZFS сделает реплику за пару минут.

Чудес не бывает: ZFS тоже с диска данные надо прочитать и кучу контрольных сумм и хэшей посчитать.

В ZFS ты бы заметил нарушение целостности чуть менее, чем сразу.

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

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

Только уследить за их целостностью

Ну не настолько уж резко все дохнет, даже на RAW системах (видиозапись) сбой случался у нас 2 раза за 3 года.CRC иногда вообще чудеса творит.С ftp wget с докачкой по гребанному edge качал ядро с модулем,где у сотового провайдера обрыв линии по скачке 2 мгб,да и так рвалось соединение....
Итог 2 с чем то тысяч обрывов,4 суток но все нормально скачалось ........

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

А как это замечает md? У него тоже есть контрольные суммы?

У md есть избыточное кодирование N+M, когда при потере части данных не только это заметить можно, но и восстановить.

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

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

Упирается в скорость накопителя.

Ну ессно при прочих равных условиях ZFS на крупных объемах будет в сотни раз быстрее твоего duplicity.

Чудес не бывает: ZFS тоже с диска данные надо прочитать и кучу контрольных сумм и хэшей посчитать.

Контрольные суммы и хэши блоков в ZFS посчитаны заранее ОДИН раз в отличии от duplicity (каждый раз?). Ничего вычитывать ZFS ненужно кроме метаданных при формировании фрагмента для очередной реплики.

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

Так это из-за твоей криворукости и отсутствия правильной настройки кластера High Availability.

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

Это до тех пор пока ваше видеонаблюдение не захотят обойти или уничтожить те, о существовании которых вы знаете только из фильмов про Джеймса Бонда.

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

А чексумм в XFS ведь тоже нет?

В 5 версии появились но только для методанных, кстати опция Cow тоже появилась,но действует сразу на том.

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

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

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

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

Ну чексумм только для метаданных на сегодняшний день явно недостаточно.

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

Ну ессно при прочих равных условиях ZFS на крупных объемах будет в сотни раз быстрее твоего duplicity.

В миллионы!

Так это из-за твоей криворукости и отсутствия правильной настройки кластера High Availability.

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

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

mv ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)