LINUX.ORG.RU

Релиз ZFSonLinux 0.8.0

 , ,


4

2

Около двух лет и 5 RC-релизов потребовалось разработчикам ZFS on Linux (сокращённо ZoL), чтобы выпустить крайне значимый релиз - ZFS-0.8.0.

Новые возможности:

  • «Нативное» шифрование как для файловых систем, так и для разделов. По умолчанию используется алгоритм aes-256-ccm. Ключи для датасета управляются с помощью команды «zfs load-key» и связанных подкоманд.
  • Шифрование при zfs send/receive. Позволяет хранить бэкапы на недоверенных сервисах без возможности компрометации.
  • Удаление устройства из pool через команду «zpool remove». Все данные копируются в фоновом режиме на оставшиеся устройства верхнего уровня, и ёмкость пула соответственно уменьшается.
  • Подкоманда «zpool checkpoint» позволяет сохранить всё состояние пула и при желании вернуться обратно в это точное состояние. Это можно рассматривать как расширенный snapshot пула. Это полезно при выполнении сложных административных действий, которые в противном случае необратимы (например, включение новой функции, уничтожение набора данных и так далее)
  • TRIM для устройств пула. Позволяет более эффективно использовать твёрдотельные накопители и предотвращать снижение их производительности и/или времени их жизни. Можно производить trim как отдельной командой «zpool trim», так и включить аналог опции discard - новое свойство пула «autotrim»
  • Инициализация пула. Подкоманда «zpool initialize» записывает свой патерн во всё нераспределённое пространство. Это устраняет первое снижение производительности доступа, которое может существовать в некоторых виртуализированных хранилищах (например, VMware VMDK).
  • Поддержка аккаунтинга проектов и квот. Эта функция добавляет учёт использования проекта и квоты к существующим функциям учёта пространства и квот. Квоты проекта добавляют дополнительное измерение к традиционным квотам пользователей/групп. Подкоманды «zfs project» и «zfs projectspace» были добавлены для управления проектами, установки лимитов квот и отчётов об использовании.
  • Программы каналов. Подкоманда «zpool program» позволяет использовать скрипты на LUA для выполнения административных действий. Скрипты запускаются в «песочнице» с лимитами времени и памяти.
  • Pyzfs. Новая python-библиотека для обеспечения стабильного интерфейса для программного администрирования ZFS. Эта обёртка обеспечивает взаимно-однозначное (one-to-one) сопоставление для функций API libzfs_core, но сигнатуры и типы более естественны для Python-диалекта.
  • Совместимость с Python3. Утилиты «arcstat», «arcsummary» и «dbufstat» обновлены для совместимости с Python3
  • Direct IO. Добавлена поддержка использования прямого вывода (O_DIRECT).

Также ускорены подкоманды scrub/resilver/list/get, добавлена возможность вывести метаданные на отдельное устройство (например, высокопроизводительный SSD малого объёма), увеличена производительность ZIL за счёт кэширования и оптимизации, добавлена поддержка аппаратного ускорения SHA256-чексумм и AES-шифрования используя Intel QAT (Quick Assist Technology).

Поддерживаемые ядра Linux: 2.6.32 - 5.1 (на ядрах 5.0 и выше пока не поддерживается SIMD-ускорение)

Полный список изменений

Значения параметров модулей по-умолчанию выбраны, чтобы обеспечить оптимальную нагрузку для большинства рабочих нагрузок и конфигураций. Для полного списка опций - man 5 zfs-module-parameters

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

★★★★★

Проверено: shell-script ()

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

Какой мерзкий ZFS, видит все глюки брэндой непогрешимой железки

постоянно скачиваю данные на носитель и втоматом проверяются контрольные суммы, и о чудо - они совпадают. Ext4 если что.

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

постоянно скачиваю данные на носитель и втоматом проверяются контрольные суммы, и о чудо - они совпадают. Ext4 если что.

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

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

Как мы докатились до такой жизни, дружище?

Так это же в мирных целях, чтобы не было войны.

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

все просто ...

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

Если подключить кривой кабель

подключай прямой

можно наблюдать взрывной рост CRC ошибок в SMART и одновременно несколько новых ошибок в zfs scrub

везёт тебе :)

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

Разработчики ZFS из SUN и подумать не могли, что кто-то будет использовать ее на домашнем компьютере. Поэтому вопрос про ecc даже не возникал.

Думаешь, ZFS менее оптимизирован под отсутствие ECC, чем остальные FS? Или иными словами другие FS более?

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

а как заранее с ZFS ?

Тебе похоже даже доктор уже не поможет, раз ты сам не соображаешь.

Сначала кабель можно проверить с помощью ZFS (это и есть заранее),

а потом уже (это не заранее, а после) использовать его для другой FS, которая сама проверять не умеет.

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

Везде написано, что использование ZFS на системах без ECC запрещено.

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

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

Может ext4 в силу ее примитивности гораздо менее агрессивно использует озу и более устойчива к ошибкам в памяти? Но я читал, что использование zfs без ecc недопустимо.

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

Подтверждаю, что дома на железе без явных отклонений работает прекрасно из без ECC, но это не отменяет преимущества ZFS когда она ловит ошибки даже на глючном диске, подключенном к серверу с ECC. Замена диска решила проблему (не кабель, не контроллер, не ECC). Почему контроллер пропускал эти ECC ошибки?

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

и при этом тормозит адово. Так себе преимущество.

Тут уже троляки похоже собрались из мракетологичского отдела ZOL.

Сами бы рассказали насколько крут с кэшированием ZIL+SLOG на небольших промышленных SSD.

Что даже хранилище с 4 тормозными HDD 7K в течении 5 лет тащил нагрузку, которую предполагалось крутить на хранилище с 20 дисками 15K и железом новее лет на 10 с лишним (разницу в цене сами можете посчитать).

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

«однако в этих ваших инторнетах есть статья с рассчётами, где наглядно показано»

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

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

как и ext4, только ext4 на порядок быстрей.

в утином манямирке разве что. даже миша с похороникса уже разродился тестами, где экст4 сливается в унитаз.

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

opensolaris на ноуте с гигом рамы нормально себя чувствовал

Без иксов? Не верю, у меня сейчас линукс+gnome+java на 4 гигах тормозит просто адски, хотя zfs не использует.

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

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

Так речь же шла о домашних данных. Этим данным так и так пока суждено жить без ECC вне зависимости от FS.

А ZFS приэтом бесплатно добавляет целую охапку парашутов (нарашиваемые зеркала, чек суммы, снэпшоты, репликацию на офлайн копии, сборку пулов на огрызках-зеркалах старых HDD разного размера - разделы под vdev).

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

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

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

Но я читал, что использование zfs без ecc недопустимо.

Nое количество моих домашних пулов смеется над твоим утверждением уже с 2012 года (зоранее начали смеятсья).

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

4 тормозными HDD 7K в течении 5 лет тащил нагрузку

Масштабы просто поражают. Что там была за нагрузка? Школьный сайт с выпускниками за 5 лет?

Знаешь зачем покупают диски на 15к?

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

Масштабы просто поражают. Что там была за нагрузка? Школьный сайт с выпускниками за 5 лет?

DB2 поверх zvol, нагруженная одним из самых тяжелых региональных комплексов.

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

Согласен, твой опыт более релевантен, по сравнению с инженерами из Sun.

Откуда взяться опыту инженеров из Sun использованию ZOL на моем оборудовании? сам подумай

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

как и ext4, только ext4 на порядок быстрей.

Это зависит от способа использования. Если в ZFS добавить SSD кэширование то скорость будет прекрасной.

Единственное, где иногда сливает ZFS - это когда троян (возможно в прошивке соседнего современного диска) портит файлы видеонаблюдения, тогда ZFS начинает глючит.

Перенес файлы на ext4 поверх zvol и все глюки ZFS исчезли, зато файлы ext4 стали по желании кого-то там портиться когда им вздумается абсолютно незаметно. Открываешь JPG, а он и не JPG вовсе, какой то мусор бинарный. Команда file тоже так думает. Странно конечно, ведь по идее zvol чексуммится точно также как и файловый dataset. Может быть у них трояно интерфейсы в дровах снаружи со стороны vfs и ПОКА только для ext?

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

I/O-per-second is determined by the following calculation:

Random I/O = 1000/ (average latency + seek time)

For a 7.2K RPM drive, a seek-time of 8.5ms and latency of 4.16 gives an IOPS number of 78.

For a 15K RPM drive, a seek-time of 2.6ms and latency of 2.0ms gives an IOPS number of 217 .

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

А-ку-еть, я думал ты понял, что я в курсе, что такое IOPS, раз упомянул скорость вращения дисков и их количество.

Теперь сравни эти епсы у Enterprise Intel SSD и 20 дисков 15K.

Когда кэш L2ARC холодный, то да, ты прав, все печально. Когда сервер ZFS сильно ограничен древним железом и объемом оперативки 12GB даже под хранение таблиц L2ARC это тоже нерадостно.

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

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

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

Подразумевается сравнение ZFS с любым ДРУГИМ (не ZFS) хранилищем.

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

20 дисков 15K по любому будут быстрее 4 c 7k. zfs тут не причем.

Ты сговорился, чтоли с мракетологами, чтобы меня подначать для защиты ZFS?

ZFS пишет всегда последовательно в рамках текущей фрагментации даже для случайной записи. Попробуй обгони хотя бы один диск даже и всего лишь 7K на чисто последовательной записи, где он дает скорость порядка 150мбайт в секунду, а файловая система (не ZFS) не умеет делать последовательную запись для случайно разбросанных данных.

ZFS пишет мелкую случайную синхронную долбежку (sync из СУБД) сначала в SLOG на Ent. SSD последовательно и потом выгружает на диски тоже последовательно по мере возможности. Попробуй обгони Intel Enterprise SSD на мелких последовательных записях.

ZFS читает случайные данные из L2ARC на Ent. SSD быстрее, чем чем 20 дисков с елозящими головами. Но ведь и в других хранилищах тоже есть кэширование.

Добавь сюда то, что мой опыт был на тормозной версии 0.65x на ужасно тормозном по современным меркам оборудовании. И да мое ZFS хранилище временами захлебывалось, например, во время бэкапов и во время загрузки больших файлов в приложении, во время запросов к данным, которые давно не использовали, т.е. когда IOPS HDD дисков начинало имет значение при случайном вычитывании данных четырьмя тормознутыми дисками 7K на древнем контроллере. Там каждая Intel Enterprise PCI SSD, наверно, стоила дороже, чем вся эта остальная рухлядь вместе взятая (древний сервер с 4 дисками). Учитывай скорость его шин по сравнению с современными.

Добавь и то, что у меня не было отдельных SSD под SLOG и под L2ARC. Одна и та же пара SSD (разделы) использовалась одновременно под: 1) Зеркало SLOG 2) 2 кэша L2ARC 3) Каталог для активных логов DB2 по NFS - отдельным пулом чисто на разделе SSD (что очень сильно ускорило всю систему в целом)

В современном ZOL ZFS есть возможность размещения даже всех метаданных на отдельном SSD.

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

Вообще не понимаю, как можно произведение искусства типа ZFS (которое больше походит на СУБД и какую-то инопланетную технологию) сравнивать с лаптями из прошлого века типа ext, FS и т.п.

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

ZFS читает случайные данные из L2ARC на Ent. SSD быстрее, чем чем 20 дисков с елозящими головами

20 дисков читают параллельно, скорость равна 20*скорость одного.

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

Контроллер умеет, у него кеш данных.

Умеет что? Как акробат в цирке (образно) в момент пролета головки над одним цирковым номером одновременно побыстрому выполнить и остальные накопившиеся трюки, если им повезет оказаться рядом? а если не повезет?

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

А ZFS почти последовательно с поправкой на метаданные и вынужденную текущую фрагментацию свободного места. Но ведь метаданные теперь можно перекинуть на отдельный носитель с основного.

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

Вообщем вангую в будущем на серверах уход остальных файловых систем на свалку истории.

OpenBSD и телепхоны конечно имеют право, но не сервера. Хотя.. в загрузочных разделах под ядро и initrd разрешаю :)

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

Так, вопрос на миллион, а чем это отличается от BPR?

Видимо тем, что не работает, если есть снимки. А без снимков dirty-on-read сделать труда не составляет.

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

Практически все. Там кеш гигабайты и свой процессор.

Это тоже по своему прекрасно, если взглянуть на количество уже пофиксенных за все время багов в ZOL ZFS за счет популярности и потом прикинуть количество ЕЩЕ не пофиксенных в проприетарных хранилищах.

Да и кстати сравни два варианты развития событий и выбери, какой тебе больше нравится:

1) Ты платишь десятки $K и получаешь черный ящик, который тебе удалось выбрать из скудного locked in листа савместимости. Который когда фатально сглюкнет ты напишешь в поддержку и тебе там сообщат, что извини дружок, но ты забыл поставить патч N1313 (который накакивается только поверх серии дястков патчей N666 и поэтому мы не виноваты. Но ваш вапрос ОООочень вааажен для нас, ны мы соизволим попросить инженеров учесть в будущем ваш хуюкз кейс.

2) Ты берешь лучшую и самую надежную железяку, которая понятия не имеет о файловых системах. ЕЕ инженеры были сосредоточены на решении узкоспециализированной задачи надежной работы железяки и за счет большого тиража она стоит сущие копейки при фантастической надежности. Потом ты разворачиваешь на ней ZFS который оттачивают уже без малого 18 лет и с огромным паблик листом поддержки, онлайн чатами с сотнями человек в т.ч. разработчиков и все это бесплатно. Ах забыл сказать, что если ты ошибся с выбором матплаты или контроллера или они просто тупо сгорели, то может переткнуть их в другие встречные варианты и ZOL заработает на них как ни в чем не бывало. И на сэкономленные средства ты можешь запастить десятками дублей железок, а не ждать 3 дня супер экспресс доставкой.

anonymous ()