LINUX.ORG.RU

Релиз ZFSOnLinux 0.6.2

 , , ,


0

2

Состоялся выход очередной версии порта файловой системы ZFS для ядра Linux. В этом выпуске пользователи обнаружат множество исправлений и несколько новых возможностей.

Новшества:

  • поддержка ядер 3.11;
  • скрипт arcstat.py для FreeNAS;
  • с FreeBSD перенесена команда zpool labelclear;
  • с Illumos перенесено сжатие L2ARC посредством алгоритма lz4;
  • оттуда же пересена поддержка нити I/O deadman;
  • SEEK_DATA/SEEK_HOLE для lseek()/llseek();
  • записываемые опции для модулей arc+l2arc;
  • улучшенное опознание дискового формата AF (Advanced Format);
  • повышена скорость чтения на зеркальных массивах;
  • улучшено отображение расширенных атрибутов SA в zdb;
  • поддержка GRSecurity/PaX для ядер 3.8+;
  • поддержка пользовательских неймспейсов для ядер 3.8+.

Исправлено:

  • потеря zvol при импорте;
  • обработка ошибок xattr;
  • переполнение ядерного стека;
  • зацикливание процесса arc_adapt;
  • зацикливание iterate_supers_type() при размонтировании;
  • зависание при размонтировании пулов, доступных только для чтения;
  • мёртвая блокировка txg_quiesce;
  • мёртвые блокировки размонтирования снапшотов .zfs/snapshot;
  • основанные на SA расширенные атрибуты симлинков;
  • потеря ядром флагов монтирования;
  • паники при arc_read() и zfs_sb_teardown()/zfs_resume_fs();
  • освобождение блоков кэширования ARC.

Новая версия уже должна быть доступна в следующих дистрибутивах:

  • Gentoo
  • Funtoo
  • RHEL/CentOS (репозиторий ZFSOnLinux)
  • Fedora (репозиторий ZFSOnLinux)
  • Ubuntu (ZFSOnLinux PPA)

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



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

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

Вот тут один зевает

Я не очень верю, что у него там xfs на софтовом raid5 и zfs raidz1 на таком же количестве накопителей.

Удиви его

Зачем?

Чтобы правильно собрать zfs pool необходимо понимать, что ты хочешь получить помимо сквозного контроля целостности, чем готов жертвовать: объем, процент резервирования, время восстановления, линейная скорость чтения/записи, iops…

Скорость и iops чтения всегда растут с увеличением количества дисков. Скорость записи не растет только в зеркале. Страйп увеличивает iops записи, а зеркало — нет. ZIL и L2ARC на SSD значительно уменьшают latency и увеличивают iops…

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

 Но ты ведь понимаешь, там какие-то доли процента скорее всего.

Понимаю. Но едкая мыслишка всё равно житья не даёт :-)

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

ZIL и L2ARC на SSD значительно уменьшают latency и увеличивают iops…

Если сравнивать пул с ZIL на SLC SSD, например, и пул с отключенным ZIL, то насколько велика разница в быстродействии, как считаешь?

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

Если сравнивать пул с ZIL на SLC SSD, например, и пул с отключенным ZIL, то насколько велика разница

Если сравнивать поездку на спорткаре и бочке с порохом, насколько велика разница в скорости?

В общем случае ZIL на HDD — медленно и печально, там синхронная случайная запись. Но если у тебя большая часть обращений асинхронны, не так страшно.

Надо понимать, что ZIL — это нифига не кэш. ZIL — это лог на случай отказа, и в обычной жизни его только пишут, но никогда не читают. Используется ZIL только при синхронной записи в пул, и сбрасывается каждый раз, когда завершается группа транзакций. Сейчас таймаут транзакций пять секунд, поэтому при максимальной скорости синхронной записи 400MB/s, например, объем ZIL не превысит двух гигабайт.

Фишка в том, что ZFS успешно отрапортует вызвавшему синхронную запись, как только данные окажутся в ZIL, параллельно асинхронно сливая их в основное хранилище. Поэтому задержки и iops синхронной записи будут как у устройства, на котором расположен лог, пока оно не переполнено, а основной пул успевает кушать данные из кэша в ОЗУ более редкими большими порциями.

ZIL может быть не на одном накопителе, а на массиве из нескольких SSD, например. В случае без выделенного места он размазан по всем дискам, поэтому на пуле из SSD нет смысла отделять ZIL.

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

Если сравнивать поездку на спорткаре и бочке с порохом, насколько велика разница в скорости?

Сравнение пула с отключенным ZIL и бочки пороха не корректно. Даже если отключить ZIL, с пулом ничего не будет, на его целостность в случае продажи питания или нештатного перезапуска по любой другой причине это никак не повлияет. Нарушиться может только консистентность данных приложений, которые пишут синхронно, потому как им обещали, что данные сохранены, а на самом деле они были сохранены только в ОЗУ

В общем случае ZIL на HDD — медленно и печально, там синхронная случайная запись.

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

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

им обещали, что данные сохранены, а на самом деле они были сохранены только в ОЗУ

Если это не бочка с порохом, то что тогда? Хуже могут быть только FS, которые теряют уже сохраненные на диск данные. Не буду показывать пальцем.

Что значит случайная?

Random write, да ещё и синхронная. А то, что ZFS оптимизирует любую запись, стараясь не гонять головки — это немного другое.

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