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

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

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

UFS2

Нет журналирования? Данные пропадали.

Зачем?)

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

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

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

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

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

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

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

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

А как патенты Oracle влияют на возможность законного использования ZFS on Linux за пределами США?

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

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

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

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

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

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

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

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

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

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

На всё.

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

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

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

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

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

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

Btrfs лучше?

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

Btrfs лучше?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 году.

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

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

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

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

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

ошибаешься

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

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

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

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

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

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

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

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

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

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

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

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

ну, cow это ж не для надежности

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

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

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

Тем не менее cow более надежен.

Раз в неделю

Гм… 20998 / 4082 = 5.144

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

наполовину записаны

Это как? Снепшот не сделается пока не произойдет sync()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

// Админ локалхоста с многолетней практикой

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

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

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

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

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

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

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

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

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

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

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

В ZFS тоже.