KnigaRead.com/
KnigaRead.com » Компьютеры и Интернет » Прочая околокомпьтерная литература » Алексей Федорчук - Linux и все, все, все... Статьи и колонки в LinuxFormat, 2006-2013

Алексей Федорчук - Linux и все, все, все... Статьи и колонки в LinuxFormat, 2006-2013

На нашем сайте KnigaRead.com Вы можете абсолютно бесплатно читать книгу онлайн "Алексей Федорчук - Linux и все, все, все... Статьи и колонки в LinuxFormat, 2006-2013". Жанр: Прочая околокомпьтерная литература издательство неизвестно, год неизвестен.
Перейти на страницу:

Обзор возможностей

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

Для начала – немного цифр. В отличие от всех предшествовавших файловых систем и систем размещения данных, ZFS является 128-битной. То есть теоретическое ограничение на её объём и объёмы её составляющих превышают не только реальные, но и воображаемые потребности любого пользователя. По выражению создателя ZFS, Джеффа Бонвика [Jeff Bonwick], для её заполнения данными и их хранения потребовалось бы вскипятить океан. Так, объём пула хранения данных (zpool – максимальная единица в системе ZFS) может достигать величины 3×1023 петабайт (а один петабайт, напомню, это 1015 или 250 байт, в зависимости от системы измерения). Каждый пул может включать в себя до 264 устройств (например, дисков), а всего пулов в одной системе может быть тоже не больше 264.

Пул может быть разделён на 264 наборов данных (dataset – в этом качестве выступают, например, отдельные файловые системы), по 264 каждая. Правда, ни одна из таких файловых систем не может содержать больше 248 файлов. Зато размер любого файла ограничивается опять же значением в 264 байт. Количество таких ограничений можно умножить. Как уже было сказано, они лежат вне пределов человеческого воображения и возможностей. И привожу я их только для того, чтобы вселить в пользователя уверенность: ни он сам, ни его внуки и правнуки в реальности не столкнутся c ограничениями на размер файловой системы или отдельного файла, как это бывало при использовании FAT или ext2fs.

Так что перейду к особенностям ZFS, наиболее интересным, по моему мнению, десктопному пользователю. Здесь в первую очередь надо отметить гибкое управление устройствами. В пул хранения данных можно объединить произвольное (в обозначенных выше пределах) число дисков и их разделов. Устройства внутри пула могут работать в режиме расщепления данных, зеркалирования или избыточности с подсчётом контрольных сумм, подобно RAID’ам уровней 0, 1 и 5, соответственно. В пул можно включать накопители, специально предназначенные для кэширования дисковых операций, что актуально при совместном использовании SSD и традиционных винчестеров.

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

Пул хранения может быть разделён на произвольное количество иерархически организованных файловых систем. По умолчанию размер их не определяется, и растёт по мере заполнения данными. Это избавляет пользователя от необходимости расчёта места, потребного под системные журналы, домашние каталоги пользователей и другие трудно прогнозируемые вещи. С другой стороны, не запрещено при необходимости и квотирование объёма отдельных файловых систем – например, домашних каталогов отдельных излишне жадных пользователей.

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

Среди других возможностей ZFS, интересных настольному пользователю, можно упомянуть:

   • создание снапшотов файловой системы, позволяющих восстановить её состояние в случае ошибки;

   • клонирование файловых систем;

   • компрессия данных файловой системы и дедупликация (замена повторяющихся данных ссылками на «первоисточник»);

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

В общем, даже если не говорить об быстродействии ZFS (а оно весьма высоко, особенно в многодисковых конфигурациях), перечислять её достоинства можно очень долго. Так долго, что поневоле успеваешь задаться вопросом: а есть ли у неё недостатки?

Разумеется, есть. Хотя большая их часть – скорее особенности: например, ограничения при добавлении или удалении накопителей в пуле, или отсутствие поддежки TRIM.

По большому счёту для пользователя Linux’а у ZFS обнаруживается два кардинальных недостатка: некоторая усложнённость её использования, обусловленная юридическими факторами, и высокие требования к аппаратуре.

Первый недостаток если не ликвидирован, то сглажен трудами Брайана Белендорфа [Brian Behlendorf] со товарищи и майнтайнерами прогрессивных дистрибутивов вкупе с примкнувшими к ним независимыми разработчиками. Аппаратные же претензии ZFS мы сейчас и рассмотрим.

Аппаратные потребности

Итак, ZFS предоставляет пользователю весьма много возможностей. И потому вправе предъявлять немало претензий к аппаратной части – процессору (изобилие возможностей ZFS создает на него достаточную нагрузку), оперативной памяти и дисковой подсистеме.

Впрочем, претензии эти отнюдь не сверхъестественные. Так, процессор подойдёт любой из относительно современных, начиная, скажем, с Core 2 Duo. Минимальный объём памяти определяется в 2 ГБ, с оговоркой, что применение компрессии и дедупликации требуют 8 ГБ и более.

Сама по себе ZFS прекрасно функционирует и на одиночном диске. Однако в полном блеске показывает себя при двух и более накопителях. В многодисковых конфигурациях рекомендуется разнесение накопителей на разные контроллеры: современные SSD способны полностью загрузить все каналы SATA-III, и равномерное распределение нагрузки на пару контроллеров может увеличить быстродействие.

К «железным» претензиям добавляются и притязания программные. В первую очередь, ZFS on Linux требует 64-битной сборки этой ОС, поскольку в 32-разрядных системах действует ограничение на адресное пространство физической памяти. Кроме того, в конфигурации ядра должнв быть отключена опция CONFIG_PREEMPT. Поэтому, например, в openSUSE ZFS может использоваться с ядром kernel-default, но не kernel-desktop, каковое, вопреки названию, устанавливается по умолчанию при стандартной настольной инсталляции.

Если вас привлекли достоинства ZFS и не устрашили её «железные» аппетиты, самое время опробовать её в деле. Что потребует знакомства с некоторыми специфическими понятиями.

Терминология

Центральным понятием ZFS является пул хранения данных [zpool]. В него может объединяться несколько физических устройств хранения – дисков или дисковых разделов, причём первый вариант рекомендуется. Но не запрещено и создание пула из одного диска или его раздела.

Каждый пул состоит из одного или нескольких виртуальных устройств [vdev]. В качестве таковых могут выступать устройства без избыточности (то есть всё те же диски и/или их разделы), или устройства с избыточностью – зеркала и массивы типа RAID-Z.

Зеркальное устройство [mirror] – виртуальное устройство, хранящее на двух или более физических устройствах, но при чётном их количестве, идентичные копии данных на случай отказа диска,

RAID-Z – виртуальное устройство на нескольких устройств физических, предназначенное для хранения данных и их контрольных сумм с однократным или двойным контролем чётности. В первом случае теоретически требуется не менее двух, во втором – не менее трёх физических устройств.

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

Пулы, образованные виртуальными устройствами, служат вместилищем для наборов данных [dataset]. Они бывают следующих видов:

   • файловая система [filesystem] – набор данных, смонтированный в определённой точке и ведущий себя подобно любой другой файловой системе;

   • снапшот [snalishot] – моментальный снимок текущего состояния файловой системы, доступный только для чтения;

   • клон [clone] – точная копия файловой системы в момент его создания; создаётся на основе снимка, но, в отличие от него, доступен для записи;

   • том [volume] – набор данных, эмулирующий физическое устройство, например, раздел подкачки.

Наборы данных пула должны носить уникальные имена такого вида:

pool_name/path/[dataset_name][@snapshot_name]

Пулы и наборы данных в именуются по правилам пространства имён ZFS, впрочем, довольно простым. Запрещёнными символами для всех являются символы подчёркивания, дефиса, двоеточия, точки и процента. Имя пула при этом обязательно должно начинаться с алфавитного символа и не совпадать с одним из зарезервированных имён – log, mirror, raidz или spare (последнее обозначает имя устройства «горячего» резерва). Все остальные имена, в соответствие с демократическими традициями пространства имён ZFS, разрешены.

Перейти на страницу:
Прокомментировать
Подтвердите что вы не робот:*