The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз OpenZFS 2.0, реализации ZFS для Linux и FreeBSD

01.12.2020 09:36

После полутора лет разработки состоялся релиз проекта OpenZFS 2.0, развивающего реализацию файловой системы ZFS для Linux и FreeBSD. Проект получил известность как "ZFS on Linux" и ранее ограничивался разработкой модуля для ядра Linux, но после переноса поддержки FreeBSD был признан основной реализацией OpenZFS и был избавлен от упоминания Linux в названии. Вся активность по разработке ZFS для Linux и BSD-систем теперь сосредоточена в одном проекте и развивается в общем репозитории.

OpenZFS уже используется в основной ветке FreeBSD (HEAD) и входит в состав дистрибутивов Debian, Ubuntu, Gentoo, Sabayon Linux и ALT Linux. Пакеты с новой версией в ближайшее время будут подготовлены для основных дистрибутивов Linux, включая Debian, Ubuntu, Fedora, RHEL/CentOS. Во FreeBSD код синхронизирован с актуальной кодовой базой OpenZFS. Работа OpenZFS проверена с ядрами Linux c 3.10 по 5.9 (в прошлом выпуске поддерживались ядра, начиная с 2.6.32) и ветками FreeBSD 12.2, stable/12 и 13.0 (HEAD).

OpenZFS предоставляет реализацию компонентов ZFS, связанных как с работой файловой системы, так и с функционированием менеджера томов. В частности, реализованы компоненты: SPA (Storage Pool Allocator), DMU (Data Management Unit), ZVOL (ZFS Emulated Volume) и ZPL (ZFS POSIX Layer). Дополнительно проектом обеспечена возможность использования ZFS в качестве бэкенда для кластерной файловой системы Lustre. Наработки проекта основаны на оригинальном коде ZFS, импортированном из проекта OpenSolaris и расширенном улучшениями и исправлениями от сообщества Illumos. Проект развивается при участии сотрудников Ливерморской национальной лаборатории по контракту с Министерством энергетики США.

Код распространяется под свободной лицензией CDDL, которая несовместима с GPLv2, что не позволяет добиться интеграции OpenZFS в состав основной ветки ядра Linux, так как смешивание кода под лицензиями GPLv2 и CDDL недопустимо. Для обхода данной лицензионной несовместимости было решено распространять продукт целиком под лицензией CDDL в виде отдельно загружаемого модуля, который поставляется отдельно от ядра. Стабильность кодовой базы OpenZFS оценивается как сопоставимая с другими ФС для Linux.

Основные изменения:

  • Добавлена поддержка платформы FreeBSD, а кодовая база унифицирована для поддержки разных операционных систем. Разработка всех связанных с FreeBSD изменений теперь ведётся в основном репозитории OpenZFS и данный проект рассматривается как основная реализация ZFS для будущих выпусков FreeBSD. Переход FreeBSD на OpenZFS позволил устранить многие проблемы, связанные с состоянием гонки и блокировками, а также перенести во FreeBSD новые возможности, такие как расширенная система квот, шифрование наборов данных, раздельный выбор классов распределения блоков (allocation classes), использование векторных процессорных инструкций для ускорения реализация RAIDZ и вычисления контрольных сумм, поддержка алгоритма сжатия ZSTD, режим multihost (MMP, Multi Modifier Protection) и улучшенный инструментарий командной строки.
  • Реализован режим последовательного выполнения команды "resilver" (sequential resilver), осуществляющей перестроение распределения данных с учётом изменения конфигурации накопителей. Новый режим позволяет перестроить отказавшее зеркало vdev значительно быстрее, чем традиционный resilver - вначале как можно быстрее восстанавливается потерянная избыточность в массиве, и лишь после этого автоматически запускается операция "scrub" для проверки всех контрольных сумм данных. Новый режим запускается при добавлении или замене накопителя командами "zpool replace|attach" при указании опции "-s".
  • Реализован постоянный кэш второго уровня (L2ARC), в котором данные на подключённом для кэширования устройстве сохраняются между перезагрузками системы, т.е. кэш после запуска остаётся "тёплым" и производительность сразу выходит на номинальные показатели, минуя фазу начального заполнения кэша.
  • Добавлена поддержка алгоритма сжатия zstd (Zstandard), который демонстрирует в 3-5 раз более высокую скорость сжатия по сравнению с zlib/Deflate и в два раза более быструю распаковку, при улучшении уровня сжатия на 10-15%. Предоставлено несколько уровней сжатия, предлагающих разный баланс между эффективностью сжатия и производительностью.
  • Добавлен выборочный режим работы команд zfs send/receive, применяемых для переноса данных из одного пула в другой. Предложенный режим позволяет настроить отправку на другую систему лишь подмножества данных, отбросив для экономии дискового пространства неважную информацию, такую как логи, или исключив конфиденциальные данные, такие как ключи доступа. Режим включается при помощи команд "zfs redact" или "zfs send --redact".
  • Добавлена поддержка системного вызова fallocate для упреждающего резервирования места.
  • На платформе Linux по умолчанию включён сервис systemd zfs-mount-generator.
  • Добавлен PAM-модуль для автоматической загрузки ключей шифрования для домашних каталогов.
  • Улучшена поддержка загрузчиков.
  • Добавлена подсветка вывода команды "zpool status".
  • Реализованы новые команды и опции:
    • "zfs wait", "zpool wait" - ожидает завершения фоновых работ (resilver, scrub, trim и т.п.).
    • "zfs send --saved" - позволяет сохранить не полностью полученный набор данных.
    • "zfs jail", "zfs unjail" - прикрепляет и открепляет ZFS из jail-окружений FreeBSD.
    • "zfs rename -u" - переименовывает ФС без перемонтирования.
    • "zfs umount -u" - выгружает ключи шифрования в момент размонтирования ФС.
    • "zfs bookmark fs#target fs#newbookmark" - создаёт копию закладки с новым именем.
  • Представлены оптимизации производительности:
    • Ускорен процесс удаления клонов и фоновой очистки при выполнении команды "zfs destroy".
    • Повышена производительность команд zfs send / zfs receive при обработке записей небольшого размера.
    • Повышена масштабируемость команды "zfs share".
    • Повышена эффективность кэша адаптивной замены ARC и управления памятью.
    • Повышена скорость записи в сильно фрагментированных пулах.
    • Оптимизирован режим шифрования AES-GCM.
    • Добавлены оптимизации с использование векторных процессорных инструкций SIMD.
  • Объявлена устаревшей поддержка дедупликации данных при отправке потоков командой "zfs send -D". Также объявлен устаревшим параметр пула dedupditto и прекращена запись новых блоков dedupditto (механизм создания избыточности, при котором создаются дополнительные копии дедуплицированных данных, повторяющихся более 100 раз).


  1. Главная ссылка к новости (https://github.com/openzfs/zfs...)
  2. OpenNews: Выпуск ZFS on Linux 0.8.0, реализации ZFS для ядра Linux
  3. OpenNews: Кодовая база FreeBSD переведена на использование OpenZFS (ZFS on Linux)
  4. OpenNews: Линус Торвальдс пояснил, в чём проблемы реализации ZFS для ядра Linux
  5. OpenNews: Выявлена несовместимость SMR-дисков WD с ZFS, которая может привести к потере данных
  6. OpenNews: Уязвимость в OpenZFS, нарушающая обработку прав доступа во FreeBSD
Лицензия: CC-BY
Тип: Интересно
Короткая ссылка: https://opennet.ru/54172-openzfs
Ключевые слова: openzfs, zfs, zfsonlinux
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (210) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, leibniz (ok), 10:14, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Проект развивается при участии сотрудников Ливерморской национальной лаборатории по контракту с Министерством энергетики США.

    И это под открытой лицензией — красота же! Фактический показатель важности открытого ПО в современном мире.

     
     
  • 2.8, Аноним (8), 10:48, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну так открытый сфот используют вы науке, как и открытое железо, в космос пускают.
     
  • 2.20, Dzen Python (ok), 11:47, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +8 +/
    В нынешних условиях это единственно возможная модель эволюции методологии программирования.
    Или вскрой исходники, или умри, в судах и корчах полицейской системыю
     
  • 2.21, Аноним (21), 11:49, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –16 +/
    >под свободной лицензией CDDL

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

     
     
  • 3.67, Аноним (-), 15:25, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Под правильной и истинно свободной, заметьте, в отличие от вредного и ведущего опенсорс к забвению GPL.

    Минус тебе толстый тролль. Великий Столлман подарил нам истинную Свободу в виде копилефта!

     
     
  • 4.103, Аноним (103), 21:47, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Великий Столлман подарил нам истинную Свободу в виде копилефта!

    Ну так CDDL тоже копилефт. Просто один копилефт с другим не совместим ;)

     
     
  • 5.189, Аноним (-), 11:19, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так сан хотел солярис проталкивать в пику линуксу. Но получилось иначе.
     
  • 4.117, Аноним (117), 02:24, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И в чём он троллит? GPL - рак, дающий метастазы в другие проекты. GPL запрещает использование других, свободных лицензий. И речь не про CDDL даже, а про абсолютно любую лицензию. Пишешь наработки в проекте с GPL и обязан лицензировать в GPL.
     
     
  • 5.137, Alexander Belov (?), 08:57, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    все верно, жпл или смерть
     
  • 5.207, Брат Анон (ok), 09:56, 07/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    GPL -- неудобная лицензия. Она вмешивается в другие лицензии. И тут надо понимать -- в условиях капитализма -- GPL раковая опухоль. В условиях общества совместного справедливого потребления -- GPL является антибиотиком.
     

  • 1.2, Аноним (2), 10:15, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > После полутора лет разработки состоялся релиз проекта OpenZFS 2.0

    не понял с какого момента считать =)

    https://en.wikipedia.org/wiki/OpenZFS -- 2013 / 7 лет

    0.7.13 -- 4 марта 2019 / 21 месяц
    0.8.5  -- 5 октября 2020 / 2 месяца

     
     
  • 2.5, Аноним (5), 10:42, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    С 0.8.0.
     

  • 1.3, iCat (ok), 10:17, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Яджва года ждал!!!
    Ура.
    А, если кроме шуток, то я очень рад тому, что ZFS продолжает развиваться, и не томится в экосистеме Oracle.
    Ещё бы перелицензировать её так, чтобы можно было в ядро поместить...
    И не надо фантазировать на тему "единственной файловой системы для всего"! Для разных задач - разные инструменты.
     
     
  • 2.4, MasterSlave (?), 10:19, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > И не надо фантазировать на тему "единственной файловой системы для всего"

    А кто фантазирует-то?) Разве что какие-нибудь романтики-утописты.

     
     
  • 3.24, Аноним (24), 11:54, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Почему? Скажу как фанат ext4 - "единственной файловой системы для всего".
    В прошлом году очень много было исправлений read-range-locks для ZFS. Теперь на ней можно вращать даже базы данных, для чего она ранее не была предназначена. Так что ZFS с недавнего времени тоже может быть "единственной файловой системы для всего", если ты захочешь так сделать.
    То есть уже ZFS - это ФС общего назначения.
     
  • 2.6, Аноним (6), 10:45, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    С подобной гибкостью по ее конфигурированию - какие уж тут фантазии? Если среди файловых систем и существует "серебряная пуля", то это она самая и есть.
     
     
  • 3.18, Dzen Python (ok), 11:43, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Ну сконфигурируй её под вчерашний dwarFS.
    Сможешь - возьму к себе на работу за меметичные 300к/наносекунду.
    "Дай человеку молоток и он везде начнет видеть гвозди"
     
     
  • 4.60, Аноним (60), 14:58, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    я смогу, но я уже получаю 300к/наносекунду и к тебе на работу врядли пойду, ЛОЛ!
     
     
  • 5.122, Аноньимъ (ok), 05:03, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Теперь поцелуйтесь.
     
  • 5.165, microsoft (?), 20:18, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пруфов конечно не будет
     
  • 4.136, a (??), 07:32, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    питон только и может что лог с такой скоростью срать
     
  • 4.198, Аноньимъ (ok), 15:49, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, а что там конфигурировать? Отключить дублирующие фичи и размер блока подобрать.

    ZFS кстати основные фичи двара сама имеет. Двар наверное оптимизирован на меньший жор ОЗУ, но нужно смотреть.

    А какого рода работу вы можете предложить? И в каком виде вам конфигурацию ZFS прислать?

     
  • 2.23, Аноним (21), 11:50, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –8 +/
    >Ещё бы перелицензировать её

    Сами кушайте свой GPL, да не обляпайтесь. А адекватные разработчики систем и компании держатся от GPL-кода на социальной дистанции.

     
     
  • 3.102, Chromium (ok), 21:39, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Адекватные разработчики берут прежде всего наиболее функциональный и рабочий код. А лицензия - дело второстепенное. Сколько вклада в Linux вносят крупные компании типа Google и Microsoft?
     
     
  • 4.118, Аноним (117), 02:27, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    То-то все крупные проекты, не затрагивающие напрямую GPL код используют Apache и BSD. Что мешало, к примеру, Clang под GPL выпустить или Golang, Rust и прочее, что написали крупные компании не так давно?
     
     
  • 5.208, Брат Анон (ok), 09:59, 07/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > То-то все крупные проекты, не затрагивающие напрямую GPL код используют Apache и
    > BSD. Что мешало, к примеру, Clang под GPL выпустить или Golang,
    > Rust и прочее, что написали крупные компании не так давно?

    Компиляторы и языки программирования -- это отдельная песня. А что касается GPL -- никто не заставляет отказываться от динамической линковки (и понимается (для справочки) динамическая линковка весьма по разному).

     
  • 4.138, Аноним (138), 08:58, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    *вредоносного вклада
     
  • 4.172, Аноним (172), 23:06, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сколько вклада в Linux вносят крупные компании типа Google и Microsoft?

    Присоединяюсь к вопросу. Сколько?

    > А лицензия - дело второстепенное.

    К сожалению нет.
    Лицензия часто определяет будет жить проект или нет.

     
     
  • 5.201, Chromium (ok), 22:35, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Сколько вклада в Linux вносят крупные компании типа Google и Microsoft?
    > Присоединяюсь к вопросу. Сколько?

    https://www.linuxfoundation.org/membership/members/

    >> А лицензия - дело второстепенное.
    > К сожалению нет.
    > Лицензия часто определяет будет жить проект или нет.

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

     
  • 4.190, Аноним (-), 11:21, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сколько вклада в Linux вносят крупные компании типа Google и Microsoft?

    На удивление, довольно много. Загрепай по гиту, умник. Майкрософт один раз вообще в топ вошел. С поддержкой своего гиперви в линуксе, разумеется. В *бсд они врядли с этим пойдут - на линуксе 2/3 их azure видите ли, а на bsd у них какой % кастомеров?

     
     
  • 5.197, анонн (ok), 13:59, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ох уж эти сказочники https www opennet ru opennews art shtml num 44570 htt... большой текст свёрнут, показать
     

  • 1.7, Аноним (7), 10:45, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –12 +/
    ну и зачем сие надо?
     
     
  • 2.83, Аноним3000 (?), 16:32, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    чтобы хранить порнуху более эффективно!
     
  • 2.143, Аноним (143), 10:53, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Дядь, это единственная рабочая COW FS с кучей функционала и которой не страшно доверить свои данные на всей планете (не считая APFS, которая закрыта).
     
     
  • 3.191, Аноним (-), 11:22, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Btrfs хранит данные миллиардов хомячков фэйсбука, вроде живые.
     
     
  • 4.195, имя (ok), 12:19, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Btrfs хранит данные миллиардов хомячков фэйсбука, вроде живые.

    …потому что могут нанять себе автора btrfs, а ленты далеко всё равно никто не листает.

     
  • 3.209, Брат Анон (ok), 10:02, 07/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Дядь, это единственная рабочая COW FS с кучей функционала и которой не
    > страшно доверить свои данные на всей планете (не считая APFS, которая
    > закрыта).

    Чо? Т.е. я правильно понимаю, что RAID, софт-зеркалирование -- не надо, а NTFS допускает потери данных каждый день на предприятиях?))

     

  • 1.9, timur.davletshin (ok), 11:02, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ну и ладненько. Пока на моей фре это не прилетело ещё.
     
     
  • 2.11, leibniz (ok), 11:08, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    держите в курсе ;)
     

  • 1.10, Аноним (10), 11:04, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Как форснуть дедупликацию на уже наполненном сторадже? И можно ли при этом сохранить избыточность (например есть 10 одинаковых файлов, нужно оставить не более двух копий)
     
     
  • 2.12, анонимоузе (?), 11:09, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так если надо не более двух копий, делай zfs pool типа зеркало, вот и будет две копии всего. Или надо чего-то по одному, чего два? Тогда можно сделать зеркало на части диска и монтировать отдельно.
     
     
  • 3.16, Аноним (10), 11:41, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дисочко уже нарезано, поэтому вариант "монтировать отдельно" не вариант, нужно чуть уменьшить занимаемое место на давно существующей хранилке, но при этом прихранить некоторую избыточность
     
     
  • 4.29, Амоним (?), 12:19, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Форсить только вручную. Сначала включить требуемые опции - дедупликацию/сжатие. Но это действует только на вновь записанные данные. Затем тупо гонять данные с места на место. Скопировал файло из одной директории в другую, переименовал директория обратно и вуаля - данные сжаты и в хеш дедупликации попали. Повторять порциями пока все файло не будет скопировано хотя бы один раз.
     
     
  • 5.52, Аноним (10), 14:20, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Но это действует только на вновь записанные данные

    Вот это как раз вгоянет в печаль на более-менее значимых объёмах

     
     
  • 6.146, Аноним (146), 12:42, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Теоретически, можно написать скрипт, который перемещает файлы в /tmp (например) и обратно в zfs...
     
     
  • 7.210, Брат Анон (ok), 10:04, 07/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Теоретически, можно написать скрипт, который перемещает файлы в /tmp (например) и обратно
    > в zfs...

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

     
  • 2.25, Амоним (?), 11:54, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Дедупликация на то и дедупликация что хранится одна копия, которая защищена избыточностью пула (raidzX) или копиями (zfs set copies=2).
     
     
  • 3.53, Аноним (10), 14:21, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> хранится одна копия

    немного не сходится с
    >> или копиями (zfs set copies=2)

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

     
     
  • 4.111, Аноним (111), 23:05, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    сходится. У тебя первоначальных копий могло быть 10. Всё это, условно, "сворачивается" в один экземпляр, который потом другими компонентами ФС дублируется уже для сохранности. Условно: было 10 - стало 2.
     
  • 3.128, ZFS (?), 06:17, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так не или, а И.

    Физическая избыточность задается на уровне пула zpool количеством доп. устройств zmirror или raidz

    А copies - это логическая избыточность на уровне dataset, задается командой ZFS (, а не zpool).


    Т.е. ничто не мешает одновременно иметь например физически три зеркала zmirror на уровне zpool и поверх них две логических копии на уровне zfs copies=2 pool/dataset.

    И будет вам количество копий 3*2=6 ! Причем одновременно с дедупликацией хоть сотен бэкапов, например DB2 dedup.

     
  • 3.213, Vanych (?), 17:58, 12/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Кроме "дедубликации" в ZFS есть еще и "дублирование"
     
  • 2.162, Кир (?), 19:47, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    для двух копий видимо делай 2 снапшота, с нужной тебе частотой
     

  • 1.13, Dionysius (?), 11:14, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Эта штука имеет смысл для домашнего десктопа? Например, повысить производительность HDD и/или увеличить время работы ноутбука от батареи?
     
     
  • 2.19, Аноним (6), 11:44, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да.
     
     
  • 3.22, Dzen Python (ok), 11:50, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Что "Да"?
    Какой выигрыш она даст на стандартном десктопном сценарии на WDC WD1003FBYX-01Y7B1?
     
     
  • 4.62, Аноним (60), 14:59, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    значительный
     
     
  • 5.73, Аноним (73), 15:41, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Раз в 10 медленнее чем ext4 https://www.phoronix.com/scan.php?page=article&item=ubuntu1910-ext4-zfs&num=2
     
  • 4.112, lleeree_ (ok), 23:08, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    1. Компрессия на исходниках
    2. Дедупликация если вы маньяк
    3. Можете увеличить пространство за счет любого подключенного диска.
    4. Если не додумались до бэкапа, то потеряете все данные по взмаху палочкой феи (из электросетей).
     
  • 4.123, Аноньимъ (ok), 05:06, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, самое главное её сво
     
  • 4.124, Аноньимъ (ok), 05:11, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну, самое главное её свойство это защита от тихой порчи данных.
    А побочное - очень годный софтварный рейд.
    Так что можете например зеркало сделать, или RAID-Z
    А если избыточность не интересна то сможет точно обнаружить повреждение данных и сказать какие именно данные повреждены.

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

    Третья удобная вещь - сжатие на лету. Для уже сжатых файлов и прочего видео штрафа почти нет. Зато разнообразные сорцы и прочее сжимает очень круто попутно сильно ускоряя чтение и запись.

     
  • 3.131, Аноним (131), 06:52, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нет.
     
  • 2.26, Аноним (24), 11:59, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Скорее наоборот. Я бы для домашнего пользователя ext4 посоветовал. Но если хочется ZFS - то конечно можно. Будет не на много медленнее, но уйдёт много ОЗУ на ARC. А ещё - бойтесь ООМ-ов в юзерспейсе, сюрпризы приносящих. Нам обещали эту проблему обойти в этом-следующем году, хоть это и не критично.
     
     
  • 3.125, Аноньимъ (ok), 05:12, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ЗФС можно оттюнить на низкое потребление.
    По крайней мере раньше можно было.
     
  • 3.139, Alexander Belov (?), 09:57, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    обойти это очень просто, проставить параметры размера арка в конфиге
     
  • 2.30, Аноним (30), 12:30, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Да, добавляет емкость батареи +7000мАч, увеличивает скорость вращения шпинделя в ХДД на 43%
     
  • 2.31, 1 (??), 12:32, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    если только у вас в десктопе дисков больше 3х и + место в M2 для ARC
     
  • 2.33, xm (ok), 12:36, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да. Она повысит надёжность хранения данных и даст возможность восстановления в случае неудачных действий пользователя, например, при обновлениях.
     
     
  • 3.43, Alatar (??), 13:43, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Да. Она [...] даст возможность восстановления в случае неудачных действий пользователя, например, при обновлениях.

    Ну, нет, если Вы про снапшоты, то это лишь ещё один удобный способ делать бекапы. Ручные. Если пользователь их не делает, снапшоты ему ничем не помогут. А если делает, то возможность восстановления у него уже есть.

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

     
     
  • 4.45, имя (ok), 13:53, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну, нет, если Вы про снапшоты, то это лишь ещё один удобный
    > способ делать бекапы.

    Ну какие же это бекапы, если они не спасают ни от кражи, ни от пожара, ни от пользователя, который решает покупать ST3000DM001-ы пачками в один RAID из соображений мифической производительности? А в остальном, конечно, инструмент удобный.

     
     
  • 5.54, xm (ok), 14:22, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ну, нет, если Вы про снапшоты, то это лишь ещё один удобный
    >> способ делать бекапы.
    > Ну какие же это бекапы, если они не спасают ни от кражи,

    Да, довольно странно считать snapshot исключительно аналогом бэкапа.

     
     
  • 6.147, Аноним (146), 12:44, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Бэкапы (снимки) можно инкрементально по сети пересылать в другой zfs
     
     
  • 7.187, Аноним (187), 08:04, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Бэкапы (снимки) можно инкрементально по сети пересылать в другой zfs

    Вот тот другой zfs и будет бэкапом. А снимки на основной системе так и останутся просто снимками.

     
  • 5.55, Аноним (10), 14:24, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В первую очередь на случай если юзверь самостоятельно что-то запорет и надо оперативно вернуться.
    А что, вас часто грабят и поджигают?
     
     
  • 6.114, имя (ok), 01:10, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А что, вас часто грабят и поджигают?

    «Если у вас паранойя, это ещё не значит, что за вами не следят.»


     
  • 5.141, Alatar (??), 10:38, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да нормальные это бекапы. Если пользователь считает достаточным бекапить свои важные данные в отдельную папочку на том же диске, это его решение и снапшоты ZFS будут ничем не хуже, скажем, рсинка. Если же не считает, то кто ему мешает хранить снапшоты на удалённой машине?
     
  • 4.50, xm (ok), 14:17, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Одним из способов применения снапшотов являются boot environments. Впрочем, я не уверен, что последние доступны в Linux. А есть ещё checkpoints.
     
  • 2.79, псевдонимус (?), 15:58, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Эта штука имеет смысл для домашнего десктопа? Например, повысить производительность HDD
    > и/или увеличить время работы ноутбука от батареи?

    Защититься от злого шифровальщика.

     
  • 2.80, Амоним (?), 16:00, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Почему-то забывают упомянуть про прозрачное криптование.
    Спокойней на душе в случае, например, кражи. Если есть конечно бэкап, который по всем правилам должен быть физически где-то в другом/других местах, и по той же причине тоже криптованным.
     
     
  • 3.132, ZFS (?), 06:58, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ZFS прекрасно работает поверх люксованных дисков, родное шифрование ZFS вроде бы не шифрует даже метаданные, оно надо такое?
     
  • 2.156, t (??), 15:25, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    а чего для домашнего применения не использовать btrfs ?
     
     
  • 3.192, Аноним (-), 11:23, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, кэп, это уже даже до федоры дошло.
     

  • 1.14, Аноним (14), 11:14, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Теоретики лицензий, раскажите, что мешает им выпустить своё поделие под GPL?
     
     
  • 2.15, Аноним (5), 11:22, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Теоретики лицензий, раскажите, что мешает им выпустить своё поделие под GPL?

    Мешает упёртость Oracle, который не спешит перелицензировать свой код ZFS, на котором основан OpenZFS. Без изменения лицензии на код Oracle, разработчики OpenZFS могут изменить лицензию лишь на свои изменения, что никуда не денет проблему с поставкой основного кода под CDDL.

     
  • 2.38, Аноним (-), 12:56, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Мешают те же причины, по которым и в ядре все гплизируется
     
     
  • 3.68, Аноним (-), 15:28, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    GPL -это Свобода. А ты враг Свободы!
     
  • 2.100, Annoynymous (ok), 20:27, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Идея состояла в том, чтобы на волне успеха Linux попытаться попробовать выпустит... большой текст свёрнут, показать
     
     
  • 3.119, Аноним (117), 02:30, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >ведь обе лицензии требуют, чтобы производный код сохранял лицензию

    CDDL позволяет использовать другие лицензии в составе проекта и даже распространять проект CDDL под другой лицензией. Так что, упёртый тут только GPL.

     
     
  • 4.171, Annoynymous (ok), 22:56, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > CDDL позволяет использовать другие лицензии в составе проекта и даже распространять проект
    > CDDL под другой лицензией. Так что, упёртый тут только GPL.

    Нет. CDDL — это аналог LGPL, он позволяет распространять код в составе другого проекта, но не позволяет проект под CDDL под другой лицензией. Иначе он был бы совместим с GPL.

     
     
  • 5.173, Аноним (117), 00:05, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >CDDL — это аналог LGPL

    LGPL совместим с GPL. Если бы CDDL был бы аналогом, была бы совместимость тоже.

     
     
  • 6.188, Annoynymous (ok), 11:08, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >>CDDL — это аналог LGPL
    > LGPL совместим с GPL. Если бы CDDL был бы аналогом, была бы
    > совместимость тоже.

    Именно. Его намеренно сделали несовместимым.

     

  • 1.17, Аноним (10), 11:41, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Интересно, когда с ним выйдет какой-нибудь армбиан свежий, со следующим LTS-ядром, чтобы на 4-ую малинку вкорячить и получить наконец-то нормальный NAS
     
     
  • 2.39, псевдонимус (?), 12:58, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нормальный нас на малинке это что-то новенькое.
     
     
  • 3.51, Аноним (10), 14:19, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Просто коробки за дофига денег, которые не умеют ничего интереснее, чем ext4 в зеркало - это тоже нифига не нормальные насы. А тут хоть какой-то шанс.
    FreeNAS/pfSense/OpenMediaVault/OpenWRT/CryptoNAS накатить и при условии что сеть норм, проц норм, ОЗУ хватает - почему бы и не быть ему нормальным
     
     
  • 4.64, OpenEcho (?), 15:08, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    +XigmaNAS
     
  • 4.71, псевдонимус (?), 15:36, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Просто коробки за дофига денег, которые не умеют ничего интереснее, чем ext4
    > в зеркало - это тоже нифига не нормальные насы. А тут
    > хоть какой-то шанс.
    > FreeNAS/pfSense/OpenMediaVault/OpenWRT/CryptoNAS накатить и при условии что сеть норм,
    > проц норм, ОЗУ хватает - почему бы и не быть ему
    > нормальным

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

    Пвсеннс фаервол.

     
  • 4.74, псевдонимус (?), 15:41, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Просто коробки за дофига денег, которые не умеют ничего интереснее, чем ext4
    > в зеркало - это тоже нифига не нормальные насы. А тут
    > хоть какой-то шанс.
    > FreeNAS/pfSense/OpenMediaVault/OpenWRT/CryptoNAS накатить и при условии что сеть норм,
    > проц норм, ОЗУ хватает - почему бы и не быть ему
    > нормальным

    Коробки лучше отбросить. Собери сам, будет гибче и дешевле. Для дома уж точно.

    Нормальный - от 12-16 гигабайт оперативки и проц уж не ниже фенона.

     
  • 4.75, псевдонимус (?), 15:49, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Просто коробки за дофига денег, которые не умеют ничего интереснее, чем ext4
    > в зеркало - это тоже нифига не нормальные насы. А тут
    > хоть какой-то шанс.
    > FreeNAS/pfSense/OpenMediaVault/OpenWRT/CryptoNAS накатить и при условии что сеть норм,
    > проц норм, ОЗУ хватает - почему бы и не быть ему
    > нормальным

    Фринас интерпрайзное и полуинтерпрайзое решения. Рекомендуемые требования - от 16 гигабайт рамы. Естественно, он будет работать на гораздо более слабых конфигурациях, но "перформанс", да и просто комфортную работу с ним не получишь.

    Насфофри попробуй. Или опенмедиавульту.

     

  • 1.28, Анонимус999 (?), 12:03, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А можно как-то настроить ZFS для старого компа с ОЗУ 2-4ГБ? Отключить тяжелые фичи (типа дедупликации), оставив сжатие...
     
     
  • 2.34, xm (ok), 12:37, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В общем случае специальная настройка (на FreeBSD) не требуется.
     
     
  • 3.58, Аноним (-), 14:43, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    как показала практика, для общих случаев, где не требуется спец. настроек и специальных фич - нужность zfs стремится к нулю и можно обойтись обычной юфс.
     
     
  • 4.90, zzz (??), 18:24, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    У UFS нельзя одновременно задействовать снапшоты и Soft Updates, а это частенько бывает нужно.
     
  • 2.37, Аноним (30), 12:46, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дедупликация по умолчанию отключена, для самого ARC рекомендуется выделять объём 1 Гб и выше. Если нет постоянных или больших потоков данных, используется типа а-ля десктоп, то скорее всего и со ~200Мб под ARC будет работать так же.
     
     
  • 3.56, n00by (ok), 14:25, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Дедупликация по умолчанию отключена, для самого ARC рекомендуется выделять объём 1 Гб
    > и выше.

    1 Гб на каждый 1 ТБ хранилища, насколько помню. Искать ссылку лень, кому важно, тот сам эти цифры знает.

     
     
  • 4.66, OpenEcho (?), 15:24, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пожалуйста, не говорите ерунды, если не в теме.

    1Гб достаточно если без дедупликации даже на exabyte хранилище.

    Почитайте не "ХауТо" блоги, а ответы на эту тему реальных разработчиков ZFS:

    https://www.reddit.com/r/DataHoarder/comments/5u3385/linus_tech_tips_unboxes_1

    https://www.reddit.com/r/DataHoarder/comments/5u3385/linus_tech_tips_unboxes_1

     
     
  • 5.98, Аноним (98), 19:54, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Если без давайте без если и без. Т.е. По факту ей надо полтерабайта памяти и больше на типичное использование а ля подкроватный сервер. Как с этим у btrfs сейчас?
     
     
  • 6.104, OpenEcho (?), 22:00, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Если без давайте без если и без.

    В ZFS по умолчанию выключена дедуплекация, о каких "без" не "без" разговор?

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

    С английским проблема посмотреть ссылки приведеные выше?
    1Гб памяти достаточно для любого обьема

    > Как с этим у btrfs сейчас?

    FYI: Поддержка btrfs была остановлена одним из главных спонсоров линукса - т.е. красношляпой

     
     
  • 7.113, Аноним (98), 23:12, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >по умолчанию выключена

    Какой смысл использовать дефолт?

    >1Гб памяти достаточно для любого обьема

    Зачем же такая очевидная ложь? Не любого, далеко не всегда эффективно, и без дедупликации естественно.

    >FYI: Поддержка btrfs была остановлена одним из главных спонсоров линукса - т.е. красношляпой

    https://www.phoronix.com/scan.php?page=news_item&px=Fedora-33-Released

     
     
  • 8.149, OpenEcho (?), 13:40, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А кто говорил про эффективность Естественно, чем больше памяти, тем лучше, но е... текст свёрнут, показать
     
  • 7.163, Кир (?), 20:12, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Наиболее заметные улучшения в Fedora 33:

        Все варианты дистрибутива для рабочего стола (Fedora Workstation, Fedora KDE и т.п.) переведены на использование по умолчанию файловой системы Btrf

     
  • 6.133, ZFS (?), 07:04, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    6TB пулы работают просто прекрасно на Core2Duo всего с двумия гигами рамы под Devuan.
    Добавление SSD кэширования еще более улучшает все это.
     
  • 6.193, Аноним (-), 11:24, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Как с этим у btrfs сейчас?

    Живет на роутере с 64 мегами. Нормально?

     
  • 5.144, n00by (ok), 11:04, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Пожалуйста, не говорите ерунды, если не в теме.
    > 1Гб достаточно если без дедупликации даже на exabyte хранилище.

    Дословно "не должно быть массы проблем" ("would not have much trouble"). В общем, нет противоречий со средней температурой по больнице.

    > Почитайте не "ХауТо" блоги, а ответы на эту тему реальных разработчиков ZFS:

    Я не читал блоги до Вашей ссылки на reddit, только issues zfsonlinux.

     
  • 4.96, Аноним (96), 19:39, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > 1 Гб на каждый 1 ТБ хранилища, насколько помню

    А вы не помните, вы головой подумайте. Есть горячие данные, есть холодные. Для горячих нужен ARC, а сколько холодных, а тем более места в хранилище, ему глубочайше насрaть.

    Если хранилище используется как лента, ARC вообще не нужен. Если на хранилище идёт значительная нагрузка в виде равномерно наспределённого случайного доступа, ARC имеет смысл делать либо размером в хранилище, либо вообще не делать потому что он иначе никак не поможет. Если доступ распределён неравномерно, то оптимальный размер arc может лежать где угодно в диапазоне от 0 до размера хранилища и зависит от множества факторов.

    Сделай одолжение, найди свою ссылку, узнай её автора и напиши ему что он некомпетентный графоман-вредитель.

     
     
  • 5.99, Аноним (98), 19:55, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А как он дедуплицировать будет?
     
     
  • 6.105, OpenEcho (?), 22:04, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А как он дедуплицировать будет?

    А зачем ??? У вас правда столько много одинаковых котиков раскиданных по всему диску чтоб экономить через дедупликацию?

     
     
  • 7.110, Аноним (98), 23:04, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ты не поверишь сколько одинаковых котиков. Я прошёлся hardlink и освободил примерно так треть пространства, но метаданные и атрибуты были утеряны конечно и в идеале этого стоит избежать. И это ведь только абсолютно идентичные данные, а сколько их частично совпадающих? Да 2/3 оставшегося наверно.
     
  • 7.134, ZFS (?), 07:08, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Дедупликация бэкапов DB2 с опцией DB2 dedup позволяет добиться снижения занимаего физического пространства в количество раз, равное примерно количеству бэкапов.

    Например, если у вас 1000 бэкапов, то они займут примерно в 1000 раз меньше места, ну может в 300-500 раз с поправкой на дельты и т.п.

     
     
  • 8.135, ZFS (?), 07:12, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Только потом для операций на удаление, например, снэпшотом даже при количестве р... текст свёрнут, показать
     
  • 8.150, OpenEcho (?), 13:50, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я не спорю, что задачи разные бывают, но вы прочитайте пожалуйста оригинальный в... текст свёрнут, показать
     
  • 8.176, Аноньимъ (ok), 00:41, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ZFS поддерживает инкрементальные бекапы снапшотов ... текст свёрнут, показать
     
  • 8.194, Аноним (-), 11:26, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    но когда сыпанется под общим для них всех набором блоков, мы скажем во бл ... текст свёрнут, показать
     
     
  • 9.196, Аноним (98), 13:04, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Неправильно ты бэкапы делаешь, дядя 1000 кратная избыточность на одном массиве ... текст свёрнут, показать
     
  • 5.145, n00by (ok), 11:05, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Над чем Есть вопрос пользователя Похоже, его запугало мнение экспертов, что ZF... большой текст свёрнут, показать
     
  • 2.76, Амоним (?), 15:53, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нормально работает, на 4гб как минимум. Размер ARC настраивается через modprobe, вот образец на 512 мб мин, 2 гб макс. Кэш он и есть кэш. Много памяти надо для дедупликации только.

    options zfs zfs_arc_min=536870912
    options zfs zfs_arc_max=2147483648

    Осталось понять что именно от зфс вам хочется и почему, ибо она в целом медленней (но вполне терпимо).

     
  • 2.77, псевдонимус (?), 15:55, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А можно как-то настроить ZFS для старого компа с ОЗУ 2-4ГБ? Отключить
    > тяжелые фичи (типа дедупликации), оставив сжатие...

    На четырех он и без настроек нормально работал на ноуте. Правда там фрибсд была, как в Линукс не знаю.

     
  • 2.97, Аноним (96), 19:53, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Там ничего не нужно настраивать Дедупликация по умолчанию выклчючена, ARC при m... большой текст свёрнут, показать
     
  • 2.126, Аноньимъ (ok), 05:17, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А можно как-то настроить ZFS для старого компа с ОЗУ 2-4ГБ? Отключить
    > тяжелые фичи (типа дедупликации), оставив сжатие...

    Можно.
    ZFS тюнется на малые объемы ОЗУ очень неплохо.

    >типа дедупликации

    Она никогда не должна быть включена ни где. И не включена.
    Включать если у вас есть много героина и молоток.

     
     
  • 3.130, nymous (?), 06:38, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > ZFS тюнется на малые объемы ОЗУ очень неплохо

    Как именно тюнется?

     
     
  • 4.152, Аноньимъ (ok), 13:55, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> ZFS тюнется на малые объемы ОЗУ очень неплохо
    > Как именно тюнется?

    http://letmegooglethat.com/?q=zfs+tuning+guide

     
  • 3.140, edo (ok), 10:07, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Она никогда не должна быть включена ни где. И не включена.

    Слишком смелое утверждение.

    У меня дедуплицикация фс, занимающей 6Тб на диске, потребляет меньше 4 гигабайт памяти:
    dedup: DDT entries 22107989, size 511B on disk, 165B in core
    Коэффициент дедупликации 4:1.

     
     
  • 4.151, Аноньимъ (ok), 13:51, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Каков юзкейс, что храните, каковы нагрузки?
    Единственный известный мне случай оправданной детупликации это куча виндовз виртуалок.
     
     
  • 5.154, edo (ok), 14:29, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Бэкапы виртуалок вмвари, хранятся 10 последних дней
     
     
  • 6.166, Аноньимъ (ok), 20:42, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Бэкапы виртуалок вмвари, хранятся 10 последних дней

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

    Кстати, с сжатием просто сравнивали?

     

     ....большая нить свёрнута, показать (35)

  • 1.32, Vlad Violentiy (?), 12:34, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чем оно лучше btrfs?
     
     
  • 2.35, xm (ok), 12:37, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +9 +/
    В общем-то, всем.
     
     
  • 3.36, Catwoolfii (ok), 12:44, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну кроме снапшотов.
     
     
  • 4.40, Аноним (-), 13:06, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А что не так со снэпшотами в ZFS? Работают же.
     
     
  • 5.44, Catwoolfii (ok), 13:44, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Снапшоты в btrfs удобнее (линейная по времени цепочка неизменяемых снапшотов в zfs и дерево в btrfs)
     
  • 3.46, An0n (?), 13:57, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Особенно 128-битностью
    Единственный минус - отсутствие любого подобия shrinking (by design?)
     
     
  • 4.59, Аноним (59), 14:51, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и что тебе даёт 128-битность? +100500 к чсв?
     
  • 4.69, OpenEcho (?), 15:33, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ZFS(big) -> backup -> ZFS(small)
     

  • 1.41, Аноним (41), 13:09, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Глючная штука на которую не действуют конфиги а выдаваемые ошибки не имеют обьяснений.
     
  • 1.42, Аноним (42), 13:18, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А есть информация, как произойдет переезд с текущей реализации ZFS во Freebsd 11/12 на OpenZFS в будущих релизах при обновлении рабочей системы?

    Что бэкапы наше все - это понятно и тривиально...

     
     
  • 2.47, Catwoolfii (ok), 13:59, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я использую в 12.2, функционал и опции перенесены частично. Смотрел в 13-м - там уже все на месте, как на линуксе. Права всё те же ACL NFS4
     
  • 2.57, xm (ok), 14:39, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Официальный переезд запланирован на 13.0-RELEASE. Сейчас же её можно поставить из портов, включая модуль ядра.
     
     
  • 3.61, Аноним (42), 14:59, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это я знаю...
    Я имел в виду - в ходе freebsd-update -r 13.0-RELEASE upgrade существующие zfs-пулы/ФС/данные не накроются медным тазом?
     
     
  • 4.82, xm (ok), 16:13, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да ну с чего бы?
    Там опасения, скорее связаны с тем, что во FreeBSD приедут (прежние?) проблемы ZFS на Linux.
     

  • 1.48, user90 (?), 14:03, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А где про тестирование, про надежность ФС??
     
     
  • 2.49, Аноним (49), 14:15, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > "Стабильность кодовой базы OpenZFS оценивается как сопоставимая с другими ФС для Linux."
     

  • 1.63, Аноним (59), 15:01, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Почему у них своего гита нет?
     
     
  • 2.65, dom (??), 15:19, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://github.com/openzfs/zfs
     
     
  • 3.84, Аноним (59), 17:00, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это гит мелкомягких.
     

  • 1.72, Аноним (72), 15:37, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    buzzword :)
     
  • 1.78, Аноним (146), 15:58, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Ждём в Proxmox 6.4!
     
  • 1.81, NotaBug (ok), 16:03, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Поставлю любую ФС если она не будет дёргать диск и моргать этой долбаной лампочкой. Хотя насколько я понял, все ядра, начиная с 4-й версии имеют диск вдоль и поперёк, даже ext2, но ведь удавалось же обеспечить нулевое обращение к диску при простое например на том же Debian 8 с ядром 3.16 и ниже, вот прям ноль, хоть десять лет работает. Линус, ты делаешь что-то не то.
     
     
  • 2.85, псевдонимус (?), 17:22, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Та как бы диск не файловая система дёргает.
     
  • 2.86, nobody (??), 17:30, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Дело не в ядре. Специально проверял, собирал одно и то же ядро в Fedora 25 и 26. В 26 и выше лампочка HDD вспыхивает каждые 2 сек. В 25 тишина, пока что-нибудь не запишешь. Судя по всему это какой-то сервис, не удивлюсь, если из комплекта systemd.
     
     
  • 3.89, NotaBug (ok), 18:19, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Судя по всему это какой-то сервис, не удивлюсь, если из комплекта systemd.

    Скорее всего так и есть, если например logrotate и подобное легко выпиливалось, то journald намертво вшито.

     
  • 2.101, Аноним (98), 21:30, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если бы это было так, диски бы не парковались каждые 5 минут.
     
     
  • 3.107, NotaBug (ok), 22:33, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Если бы это было так, диски бы не парковались каждые 5 минут.

    Вот причём здесь парковка? Тем более её легко отключить
    в
    /etc/hdparm.conf
    смените
    #apm_battery = 127
    на
    apm_battery = 255

    По крайней мере раньше было так.

     
     
  • 4.109, Аноним (98), 23:01, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нуу это сильно раньше, на современных дисках парковка не отключается. Вроде даже как совсем. Если бы ядро дёргало диски, они бы не парковались, но они паркуются и не просыпаются пока не понадобятся какие-нибудь файлы. Можно в iotop -oa наверно посмотреть кто дёргает, но если это какой-нибудь крон, то не отобразится.
     
     
  • 5.115, NotaBug (ok), 01:29, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Что это за современные диски такие, вроде ж техпроцесс на HDD не меняется десятилетиями, тут надо копать в daemon/service и с корнем такое выпиливать.
     
     
  • 6.116, Аноним (98), 01:49, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще-то каждые пару лет всё меняется очень значительно. Не выпилишь ты парковку, она в прошивке зашита. Они видимо решили что достаточно обкатали на прошлых поколениях и теперь можно принудительно парковать. В принципе это не сотни тысяч парковок в месяц, но штук 10 за день легко набирается и доступ к паркованным дискам чересчур уж медленный. Если хочешь убить диск более эффективно включи остановку шпинделя.
     
     
  • 7.148, NotaBug (ok), 13:02, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Вообще-то каждые пару лет всё меняется очень значительно. Не выпилишь ты парковку,
    > она в прошивке зашита. Они видимо решили что достаточно обкатали на
    > прошлых поколениях и теперь можно принудительно парковать. В принципе это не
    > сотни тысяч парковок в месяц, но штук 10 за день легко
    > набирается и доступ к паркованным дискам чересчур уж медленный. Если хочешь
    > убить диск более эффективно включи остановку шпинделя.

    А всё таки это из-за ядра, так как я ставил и Devuan, и MXLinux/Antix, там нет systemd, а диск дёргало будь здоров, скорее всего какая-то подсистема для ускорения доступа до ФС.

     
  • 5.127, Аноньимъ (ok), 05:20, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Современные диски очень разные.
    И на большинстве парковкой можно управлять из вне.
     
  • 2.158, t (??), 15:35, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    на ext4 ставил commit=900, и годами жил на корне который на флешке.
     
     
  • 3.186, NotaBug (ok), 02:32, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > на ext4 ставил commit=900, и годами жил на корне который на флешке.

    Спасибо, добавил к noatime,nodiratime,nobarrier, а вот lazytime под вопросом.

     

  • 1.87, nobody (??), 17:37, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А кто-нибудь знает где можно проверить ключ, которым подписан .tar.gz ? Новых бинарных сборок 2.0.0 под дистрибутивы пока нет, а старые сборки подписаны gpg ключами ментейнеров, которые тоже не понятно где проверять...
     
  • 1.88, Аноним (88), 18:11, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    ZFS это хорошо
     
  • 1.93, Аноним (93), 18:41, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Впилили бы zstd компрессию в ext4, и не надо больше ничего
     
     
  • 2.95, Аноним (30), 19:27, 01/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше webp.
     
  • 2.120, Синьоры смотрители борделей (?), 02:52, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Она есть, называется VDO Layer
     
     
  • 3.121, fske (?), 03:06, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мало, очень мало прлслоек. Нужно больше!
     
  • 2.129, nymous (?), 06:37, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Мысль вслух - а может попробовать компрессию на F2FS...
     

  • 1.108, Аноним (59), 22:45, 01/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Оно уже научилось дефрагментации?
     
     
  • 2.153, Аноньимъ (ok), 13:58, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Оно уже научилось дефрагментации?

    Каков ваш юзкейс вызывающий повышенную фрагментацию ZFS?
    Как быстро перфоманс деградирует?

     
     
  • 3.155, Аноним (98), 15:11, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Любой юзкейс где файлы не аллоцируются сразу а дописываются в процессе вызывает сильную фрагментацию. Например, типично самое фрагментированное, это профили браузера (для линукса).
     
     
  • 4.157, Аноньимъ (ok), 15:35, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Профиль браузера у вас вызывает фрагментацию ZFS?
    Или вы не знаете, а только предполагаете?
    ИМХО, нужно проверять.

    ZFS кстати COW система, на всякий случай отмечу.

     
     
  • 5.159, Аноним (98), 15:44, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ext4 он определённо точно фрагментирует очень сильно, а ведь ext4 как известно тоже "не фрагментируется", только даже e4defrag плачет кровавыми слезами от кэшей браузера. Однако, свободное пространство адово фрагментирует, но у неё хотя бы какой-то онлайн дефрагментатор есть.
     
     
  • 6.168, Аноньимъ (ok), 20:53, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Ext4 он определённо точно фрагментирует очень сильно, а ведь ext4 как известно
    > тоже "не фрагментируется", только даже e4defrag плачет кровавыми слезами от кэшей
    > браузера. Однако, свободное пространство адово фрагментирует, но у неё хотя бы
    > какой-то онлайн дефрагментатор есть.

    Надо тестировать. ZFS - совсем другая система. Я слышал о проблеме фрагментации на ней, но точно не на профилях браузера.
    И обычно рекомендуют оставлять больше свободного места или добавить дисков в пул для повышения IO.

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

     
     
  • 7.169, Аноним (98), 21:35, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не только профили браузера, это просто пример постоянно пишущихся файлов. Ещё жесть была на cow образах виртуалок. И раньше ещё сталкивался с фрагментацией на торрентах, когда программа не аллоцировала сразу весь файл целиком. Дефрагментатора на линуксах очень не хватает, файлы читающиеся подряд чаще всего будут разнесены по всем блинам ровным слоем даже если они не фрагментированы, это тоже значительно снижает производительность (поэтому доступ к куче мелких файлов такой медленный). Ну и консолидировать свободное пространство наверное хотелось бы. Не подходит линукс для высокопроизводительных рабочих станций, ничего не поделать.
     
     
  • 8.175, Аноньимъ (ok), 00:34, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нужно аллоцировать, иначе торренты жесткий диск вешают Высокопроизводительные р... текст свёрнут, показать
     
     
  • 9.177, Аноним (98), 00:53, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ССД не напасёшся, они конечно идут под кэши, но это всё довольно ограничено в ит... большой текст свёрнут, показать
     
     
  • 10.178, Аноним (98), 00:58, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Особенно весело становится когда случайный доступ в несколько потоков, а файлы р... текст свёрнут, показать
     
     
  • 11.180, Аноньимъ (ok), 01:18, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Никакая дефрагментация тут не поможет Это ограничения жестких дисков как технол... текст свёрнут, показать
     
     
  • 12.181, Аноним (98), 01:29, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Диски читают в свой кэш относительно большими блоками даже очень большими , а е... текст свёрнут, показать
     
     
  • 13.182, Аноньимъ (ok), 01:38, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И как это поможет когда у вас ... текст свёрнут, показать
     
     
  • 14.183, Аноним (98), 01:50, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    На позиционирование понадобится много меньше времени, если файлы сразу попадают ... текст свёрнут, показать
     
     
  • 15.184, Аноньимъ (ok), 02:01, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Доступ же случайный, откуда файлам в кеш попадать, и какая разница как близко он... текст свёрнут, показать
     
     
  • 16.185, Аноним (98), 02:10, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Наверное всё же не совсем случайный Тут вычитал тысячу файлов за один заход, та... текст свёрнут, показать
     
     
  • 17.199, Аноньимъ (ok), 19:02, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, диски не обладают подобным интеллектом ... текст свёрнут, показать
     
     
  • 18.200, Аноним (98), 21:25, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Или обладают, они определённо умнее среднего пользователя Сегодняшние нжмд искл... текст свёрнут, показать
     
     
  • 19.202, Аноньимъ (ok), 22:36, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вот и не додумывайте тогда за ШДД и файловые системы, им виднее ... текст свёрнут, показать
     
     
  • 20.203, Аноним (98), 23:00, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну это уже откровенное хамство, да Будем считать за слив и отсутствие адекватны... текст свёрнут, показать
     
  • 21.204, Аноньимъ (ok), 23:06, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вам заняться нечем, кроме как меня троллить Вы единственный кто здесь хамит Вс... текст свёрнут, показать
     
  • 22.205, Аноним (98), 23:13, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну это стадия отрицания, не иначе Пример низкой квалификации, да Поскольку люб... текст свёрнут, показать
     
  • 23.206, Аноним (98), 23:21, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пс я, конечно, могу совершенно добросовестно заблуждаться, но я хотя бы проводи... текст свёрнут, показать
     
  • 22.214, Admin LinuxDB2 (?), 04:48, 16/12/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Подтверждаю, ZFS жутко фрагментируется и тормозит от профиля Chrome, уже 4 раза ... текст свёрнут, показать
     
  • 23.216, Аноньимъ (ok), 06:38, 16/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сами-то свои ссылки читали И куда вас понесло, что там за промышленные хранилищ... текст свёрнут, показать
     
  • 10.179, Аноньимъ (ok), 01:17, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    На кеш браузера и логи ZFS очень хорошо это оптимизирует Попробуйте тестовый с... текст свёрнут, показать
     
  • 3.161, Аноним (161), 18:40, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я сумку на плече ношу либо рюкзак, кейсами не пользуюсь. И про Перфоманса не знаю, среди знакомых людей с такой фамилией нет.
     
  • 2.167, xm (ok), 20:49, 02/12/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А почему вас это беспокоит? Я вот не вижу проблем с производительностью на ZFS c 73% фрагментацией. Кстати, вы точно правильно понимаете что этот показатель означает в ZFS?
     

     ....большая нить свёрнута, показать (27)

  • 1.142, JBOND (?), 10:45, 02/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    DRAID еще не допилили.
     
  • 1.160, Вопль_в_пустыне (?), 18:14, 02/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нормальная фс для больших объемов самое то.
     
  • 1.170, Аноним (172), 22:55, 02/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > OpenZFS уже используется в основной ветке FreeBSD (HEAD)

    HEAD это не ветка!
    Насколько я выяснил (на openzfs.org/wiki/Main_Page) OpenZFS использует git в качестве системы контроля версий.

    В git, HEAD - это указатель на текущую ветку.
    Поэтому фраза имеет (точнее _фраза_не_имеет_смысла) следующий смысл -
    "OpenZFS уже используется в основной ветке FreeBSD (любой ветке в которую сделан git checkout или git switch)"

     
     
  • 2.174, Аноним84701 (ok), 00:21, 03/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    FreeBSD вообще-то старше git и HEAD может использоваться как устоявшееся обозначение
    https://www.freebsd.org/cgi/man.cgi?cvs
    >  HEAD refers to the most recent version available in the repository

    еще со времен живых мамонтов и компьютеров из натурального кремНЯ

    т.е. фраза означает, что оно вот тут https://svnweb.freebsd.org/base/head/

     

  • 1.211, Брат Анон (ok), 10:16, 07/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Добавлена поддержка алгоритма сжатия zstd (Zstandard), который демонстрирует в 3-5 раз более
    > высокую скорость сжатия по сравнению с zlib/Deflate

    Прям в 3-5 раз более высокую скорость сжатия?... Т.е. эти ребята возможно:
    1) научились читать данные с диска в 3..5 раз быстрее
    2) открыли какой-то волшебный алгоритм?))


     
  • 1.215, Admin LinuxDB2 (?), 04:49, 16/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Подтверждаю, ZFS жутко фрагментируется и тормозит от профиля Chrome, уже 4 раза приходилось делать send | receive для дефрагментации, после чего браузер перестает подолгу тормозить.

    И это в режиме sync=disabled, когда по сути все пишется первые несколько минут только в оперативку.
    Т.е. получается, затраты по IOPs только на чтение.

    И дальше берем базу СУБД на zvol, через несколько лет она становится жутко фрагментированной, но это еще полбеды, потому что часть ее можно загнать в L2ARC на SSD.

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

    Ну ни нада звиздеть про ненужность дефрагметации, это же дичайшая дичь тупая, почейтайте лучше, что пишут умные люди:

    https://serverfault.com/questions/957317/zfs-heavy-write-amplification-due-to-

    https://github.com/openzfs/zfs/issues/4785

    Ну если вы просто троль производителей СХД, то я вас еще могу понять, потому что после появления в ZFS онлайн дефрагментации вас ждет финансовый кирдык, что я приветствую как пострадавший (к счастью только потерей своего времени) от хоронилищ IBM в составе Blade Center S.

    Во всех уважающих себя промышленных хранилищах есть online дефрагментация, и я больше скажу, когда такая дефрагментация появится в ZFS, а она однозначно появится, когда подсуетятся промышленные пользователи, так вот тогда, все эти дорогие промышленные хранилища начального и среднего уровня пойдут по писе, ну может останутся девяточные с дублированием матплат и т.п. и то с учетом существования кластерных FS типа CEPH это еще большой вапроз.

     
     
  • 2.217, Историк (?), 10:43, 21/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Для уменьшения фрагментации можно подтюнить recordsize https://jrs-s.net/2019/04/03/on-zfs-recordsize/
     
     
  • 3.218, Chromium1234 (?), 09:22, 27/12/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно, какой нужен volblocksize для профиля Chromium в ext4 поверх zvol блока?

    Наверно, нужно сначала выбрать оптимальный размер блока для ext4 и потом такой же для zvol?

    А как выбрать оптимальный?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру