История изменений

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

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

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

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

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

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

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

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