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)

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

Devuan Ascii вполне достаточно в качестве очень стабильного хоста с ZFS, чтобы запускать любые KVM виртуалки с Beowulf, Ceres, Alpine, GUIX и т.п.

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

Ты придираешься. Если речь о нестабильной ветке — то такое случается сплошь и рядом.

А то я не знаю. Я ровно для этого примеры и привёл - в разработке ПО это не то чтобы норма, но случается. И ZoL здесь не исключение.

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

Круть. Скорости конечно нереальные.. Хотя думаю тут нашлись бы люди которые даже половины не смогли бы выжать из этого. Вот кстати там точно нужна чексум зфс

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

Настало время офигительных историй ) Кривой движок у облака, но виновата zfs.

Ваще не виновата. Её надо было держать там, где её место: на помойке :)

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

Ага, щщас… Нетаппы всякие спят и видят такие сны, чтобы втюхивать свои чёрные ящики за полмуля с дисками на 20 тыщ =)

mv ★★★★★
()

Непонятна мотивация тех, кто затаскивает ZFS на Linux.

  1. Возможно они не знают что Оракл не откажется от патентов
  2. Возможно они думают что Оракл подобреет
  3. Возможно они индиффирентны к мнению правообладателя

Нормально работающую ZFS видел на Solaris. Всё остальное сорта г. В БСДях некое нормально работающее подмножество, доведённое до состояния при котором его можно юзать 24*7. В Linux использую LVM.

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

Сам отвечай на свой вопрос.. ) Патенты это не про использование Васей из Моршанска на законных основаниях технологий. Это про возможность давить когда надо и кого надо. А по поводу границ действия законодательства это скорее к югистам.

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

Можно по подробнее, какая именно производительность и где именно просадки были? На чтение или запись? Какие типы данных хранились?

Просто если честно, звучит как ветхозаветная история какая то, компания из трех букв под названием Лот бежала из Содома и Гомморы, а не про популярную фс и конкретных ошибок..

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

В Linux использую LVM.

И как ты только умудрился сравнить провайдера логических томов с файловой системой…

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

использование Васей из Моршанска

Proxmox Server Solutions GmbH == Вася из Моршанска. У вас гарбейдж колектор похоже дал сбой, товарищь.

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

Патенты это не про использование Васей из Моршанска на законных основаниях технологий. Это про возможность давить когда надо и кого надо. А по поводу границ действия законодательства это скорее к югистам.

Ну и как ты собрался давить патентами пользователей на территории РФ? Они пошлют тебя в пешее эротическое путешествие на законных основаниях.

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

Можно по подробнее, какая именно производительность и где именно просадки были? На чтение или запись? Какие типы данных хранились?

На всё.

В облаках бесперебойников у каждого сервера не бывает, поэтому всё IO идёт без кэша. Тут-то ZFS и обгаживается со своими метауказателями на метауказатели на метауказатели и сопутствующим IO amplification.

Кроме того, ФС спроектирована и наглухо написана в эпоху энтерпрайзных HDD и мощных серверов на 2-4 ядра, поэтому ей ничего не светит даже на каком-нибудь жалком 64-ядерном Интеле с SAS SSD. Я даже не говорю про современные AMD Rome и NVMe.

Всё в коде очень плохо, никакой параллельности. Никогда не будет быстро работать.

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

И как ты только умудрился сравнить провайдера логических томов с файловой системой…

Ну zvol, как бы, блочное устройство. А если попишешь datapath’ы, то не будешь видеть особой разницы между ФС и менеджером логических томов со всякими обычными плюшками, thin provisioning, compression, dedup и т.п.

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

Всё в коде очень плохо, никакой параллельности. Никогда не будет быстро работать.

Btrfs лучше?

Производительность ZFS с HDD пулом достаточно хорошо фиксится добавлением L2ARC на быстром промышленном SSD.

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

Btrfs лучше?

Без понятия. Поделками если пользуюсь, то только своими.

Производительность ZFS с HDD пулом достаточно хорошо фиксится добавлением L2ARC на быстром промышленном SSD.

У нас NVMe с 750k IOPS на старте, а ты про HDD… Это изделие 100k выдавало локально, а если добавить ещё сетевого и прочего лейтенси, то падало до 12к, когда до виртуалки доходило.

И я не помню, 100к эти оно на одном NVMe выдавало, или на страйпе из 14 NVMe, где «голых» IOPSов намерялось 5M - дальше дохлый проц не мог.

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

Не обратил внимание что в облаке. Там еще куча абстракций до того как ты что то запишешь в файл, начиная с аппаратного рейда скорее всего. Ну аппаратный рейд + рейд зфс = это явно чтение доков по диагонали.

В облаках бесперебойников у каждого сервера не бывает, поэтому всё IO идёт без кэша

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

никакой параллельности

всмысле многопоточности если про ядра зашла речь? Зачем тебе 64 ядра для дисковой корзины? Тебе больше оперативка нужна скорее.

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

я так понимаю, что там скорость важна была раз стрипы из nvme. Если сверхзвуковая скорость нужна - то зфс не лучший вариант, соглашусь. Но я всё равно не понимаю, при 14 nvme у вас явно должно было больше 100гб оперативы быть, а при высоких хитах arc должен летать(если только с оперативкой траблов не было) , и откуда проц дохлый такой при таком количестве nvme, как он их на своих линиях вообще тянул интересно.

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

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

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

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

Не обратил внимание что в облаке. Там еще куча абстракций до того как ты что то запишешь в файл, начиная с аппаратного рейда скорее всего. Ну аппаратный рейд + рейд зфс = это явно чтение доков по диагонали.

Кто ж аппаратный рейд ставит в облаке? Ноду в облаке собирают на самом дешёвом железе, из гомна и палок. А если жир нарос, то и вообще своё железо проектируют.

Кеш на чтение не нуждается в сохранности.

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

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

Это да: та же EXT4 потеет, покрывается зелёной сыпью, сыпет в dmesg ошибки, потом непереваренное в lost+found кладёт и дальше бежит. Даже если что-то недочинилось, то всё ещё есть возможность вытащить данные, хотя бы и в оффлайне. А ZFS просто встаёт в ступор, и нифига не даёт сделать. Я, мол, в эту кучу потыкала, но ничего делать не буду. Поэтому сбой в EXT4 обычно - data unavailable на пару часов, а в ZFS - data lost. Пару часов клиенты потерпеть желают, потерять диск полностью - нет.

Не работает в ZFS хвалёный COW.

всмысле многопоточности если про ядра зашла речь? Зачем тебе 64 ядра для дисковой корзины?

Затем, что у NVMe по паре submission/completion очередей на ядро. У каждого из 10-14 штук. У сетевухи штук 128 очередей на виртуальные интерфейсы. У двух сетевух. Современные суперупакованные АМД идут уже с 256 логическими ядрами. Если какая-то часть системы офигеет, что к одному ресурсу лезут с полсотни ядер, то система будет колом стоять, прожигая процессорное время на спинлоках, чем ZFS ваша и занимается.

Тебе больше оперативка нужна скорее.

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

ZFS - плохая, устаревшая система в 2020 году.

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

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

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

да ты нищеброд, оказывается) я еще в 13 году 32 оперативки поставил и че-т не тормозит:)

Я не знаю куда свои 16 деть – 6-10 гектар как правило просто простаивает. Куда можно деть 32 Гб на десктопе? У Вас что там, Android Studio в фоне постоянно болтается?

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

Не работает в ZFS хвалёный COW

Что куришь? Явно не маны. Ты серьезно хочешь сказать что в zfs нет cow? Что тогда в твоем понятии транзакционная семантика? Еще скажи что у вас пулы были до верху забиты данными и тогда я от души посмеюсь. Кстати, как тогда еще снепшоты делаются мнгновенно, занимают мало пространства и мнгновенно откат исполняют в зфс если там нет cow?

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

виртуалка с виндовозом 10(не бейте, по работе нужна), докер с кучей проектов где билдится\тестится\логируется. + я любитель кучи вкладок в браузере, а веб разрабам нынче пофиг на память юзеров. Еще не дай бог открою какое нибудь поделие от джетбрейнс(ну нравится мне там дебажить, удобно) и всё, ява отжирает. 20гб как в трубу. Комп вырубается только когда электричество пропадает больше чем на 15 минут

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

Что куришь? Явно не маны. Ты серьезно хочешь сказать что в zfs нет cow? Что тогда в твоем понятии транзакционная семантика? Еще скажи что у вас пулы были до верху забиты данными и тогда я от души посмеюсь. Кстати, как тогда еще снепшоты делаются мнгновенно, занимают мало пространства и мнгновенно откат исполняют в зфс если там нет cow?

COW, как краеугольный камень надёжности ZFS, с автомагическим откатом на предыдущую операцию при возникновении каких-то проблем на диске, давно не работает, т.к. NAND-флеш - это не намагниченные цилиндры.

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

так, ты походу не понимаешь явно как работает cow. https://docs.oracle.com/cd/E19253-01/820-0836/gaypi/index.html

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

Краеугольный камень надежности - контрольные суммы. Вот тебе пример : возьми md из двух sdb sdc, запиши файл с нулями, сделай чек суммы, потом dd urandom на sdb и снова чекни контольную сумму - мд скажет все за.бись, фзс же из мирора даже не чихнет. Потому что следит чексумами по всему дереву и не даст записать поверх данных существующих данных.

А ты так и не ответил про мгновенные снепшоты, если зфс не ков

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

бэкап каждые десять минут* тут поставлю любое время, каждые 3 секунды, например? Это время зависит от объема данных, IOPS, скорости передачи данных, форматы даты и тд и тп. Так или иначе, для фоточек с телефона «бэкап каждые десять минут» реален. отележивание фоточек всякими штуками типа inotify тоже реально. Но все это до какого-то предела. Но в ZFS ты не тратишь времени и ресурсов вообще. Мнгновеннно.

Как это вообще может работать? Снапшоты каждые N секунд замораживают место для версии, при интенсивной записи место сжирается моментально и старые снапшоты так же резко раз в N секунд приходится удалять. Как тут не пропустить время, когда в снапшотах всё еще лежит что-нибудь полезное и выцепить его? У нас эксперименты со снапшотами были очень быстро свёрнуты именно по этой причине. Да и файлы, которые лежат в снапшотах часто бывают в состоянии «наполовину записаны». Я вижу применение снапшотов только в стиле «заморозил систему пока она в r/o, обновил, если что пошло не так, то откатил».

Для дедупликации полно реальных юзкейзов. А вот частые снапшоты системы, на которую прямо сейчас идёт запись - ну для меня выглядит костылями. Бэкапы на то и сделаны отдельно, чтобы файлы бэкапить в предсказуемом состоянии.

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

Я знаю, как работает COW в теорию. И видел, как ZFS это не помогает, чтобы в случае отвалившегося write io при записи метаданных сия ФС падала с паником, и потом не монтировалась. Поэтому:

Не работает в ZFS хвалёный COW

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

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

Судя по тому как ты объясняешь, могу сделать вывод что у вас больше 80% пула занято было и вы фигачили сверху на него, не понимая принципа COW - вот от этого все тормозило и разлеталось.

  • неужели так часто отваливась запись? Сервер в датацентре стоял? Потому что судя по описанию отключений, он был подпитан на одной фазе с чайником в бухгалтерии
sky92
()
Ответ на: комментарий от intelfx

Раз в неделю

Гм… 20998 / 4082 = 5.144

Неделя какаято сокращенная, каждые 5 часов выдергиваешь вилку из розетки, тестируешь btrfs?

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

Судя по тому как ты объясняешь, могу сделать вывод что у вас больше 80% пула занято было и вы фигачили сверху на него, не понимая принципа COW - вот от этого все тормозило и разлеталось.

Да пустое всё было, клиентов это облако накрыть не успело.

неужели так часто отваливась запись? Сервер в датацентре стоял? Потому что судя по описанию отключений, он был подпитан на одной фазе с чайником в бухгалтерии

В облаке любая, самая невероятная фигня случается десятками случаев каждый отчётный период ;)

Ну и это: выживаемость старого привычного md/dm/ext4 сильно выше на практике оказалась. Работала бы так ZFS, а дефолтный опенсорц - глючил и тормозил, пел бы диферамбы ZFS. Мне без разницы.

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

ufs - окаменевшее говно мамонта, которое используют на своих локалхостах только бздуны-нищеброды потому, что не могут себе позволить zfs, а ext4 - современная передовая повсеместно используемая в продакшен фс.

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

Пример «OS/2 vs Windows 95» очень нагляден.

Извините но этот пример маленько некорректен.Полуось еще обслуживается, Ибм продала контракт на обслуживание нескольким компаниям,из последних новостей
что я читал вышло новое ядро с поддержкой современного железа,к сожалению совместимость с драйверами сломана.Обслуживание дорого, полгода 140$ ........

maximnik0 ★★
()

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

«Зелён виноград»

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

Но Apple реально не нужен. Макбук это просто машина для разработки под iOS и не более того.

GalleryPoster
()

Предлагаю накласть на мнение этого деятеля

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

Поэтому сбой в EXT4 обычно - data unavailable на пару часов, а в ZFS - data lost.

А импортировать пул со всякими опциями форсирования отката последних транзакций? ext4 может потерять файлы даже без внезапной перезагрузки и уж тем более на дешманском железе.

Достаточно осуществить EMI атаку на SATA канал и ext4 даже не заметит как файлы начнут забиваться мусором, в то время как ZFS это заметит и очень вероятно исправит при наличии дублирования.

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

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

А только чего стоит ежедневная репликация, когда в случае тотального факапа устройства, например, в случае EMI атаки на USB-SATA->SSD, когда на незадублированный SSD внезапно попадает тотальная хрень, есть возможность легко и непренужденно восстановиться со вчерашнего вечернего бэкапа, на создание которого ушло всего несколько минут за счет копирования только дельты реплики.

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

ZFS - чудесная штука, только не включайте дебубликацию

Дебубликация ZFS божественна при архивировании бэкапов IBM DB2, созданных с опцией dedup, в остальных случаях - она полная кака.

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

Так вот связка ZFS dedup + DB2 backup dedup позволяла тратить на каждый следующий полный бэкап всего дополнительных 2-5% от общего объема достаточно крупной базы данных, в то время как инкрементальный бэкап DB2 без dedup за аналогичный период времени отъедал 70-90% от полного, т.е. экономия места на диске от dedup достигала десятков раз по сравнению с инкрементальным.

Когда каждый online ночной бэкап логически отжирает около терабайта - вот и считайте, неделя бэкапо без dedup - 5-7 терабайт, неделя или даже месяц бэкапов с dedup - почти равна размеру базы данных, т.е. всего 1TB с небольшим.

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

Достаточно осуществить EMI атаку на SATA канал и ext4 даже не заметит как файлы начнут забиваться мусором,

Сэр , ext4 с 14 года есть контрольные суммы.А установщик в дистрибутиве не телепат и у него отсутствует ИИ чтобы включить эту опцию в fstab.
Было у меня дело как при копирование диск начал тормозить ,в логах crc error.Ну думаю диску хана,но пощелкивании то нету,решил проверить- все с диском нормально оказалась,в кабеле контакты отклеились :-)

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

Разве в ext4 есть полная проверка чексумм, а не только чексумм журнала? Можно узнать опцию/пруф?

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

ext4 с 14 года есть контрольные суммы

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

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