Незамаскированная Zfs

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

Проблемы начинаются, когда вы начинаете делиться данными.

Все, что меньше байта, не является проблемой (если только вы не используете VAX), но большие тома требуют использования четко определенного порядка байтов.

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

Нотация с прямым порядком байтов располагает байты в порядке 1234, тогда как компьютеры с прямым порядком байтов хранят их в порядке 4321. Некоторые компьютеры используют что-то вроде 1324, но в целом люди стараются этого избегать.

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

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

HFS+ от Apple — хороший пример такой практики.

Поскольку HFS+ возникла на PowerPC, структуры данных в файловой системе хранятся в формате с прямым порядком байтов.

На Mac с процессором Intel вам необходимо менять порядок байтов каждый раз, когда вы загружаете или записываете данные на диск.

Инструкция BSWAP на чипах x86 обеспечивает быстрое переключение, но в любом случае она не очень хороша для производительности.

Sun оказалась в интересном положении, когда дело дошло до порядка байтов, когда она начала продавать и поддерживать Solaris на архитектурах SPARC64 и x86-64. SPARC64 – обратный порядок байтов и x86-64 – прямой порядок байтов; Какое бы решение Sun ни выбрала, одна из ее файловых систем будет работать медленнее, чем другая архитектура, поддерживаемая Sun. Решение Сан? Не выбирайте.

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

Раздел ZFS на Opteron будет иметь прямой порядок байтов, а контролируемый UltraSPARC — обратный порядок байтов.

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

Это не совсем точно, ZFS — это не файловая система в традиционном понимании UNIX, а скорее набор определенных слоев, который обеспечивает расширение обычной файловой системы.

В этот момент любой администратор VMS в аудитории может почувствовать самодовольство и пробормотать про себя: «Наконец-то в UNIX появилась настоящая файловая система.

Возможно, он наконец готов к промышленному использованию».

Три уровня ZFS называются уровнем интерфейса, уровнем транзакционных объектов и уровнем интегрированного хранилища.

Спускаясь вниз по стеку, эти уровни преобразуют запросы файловой системы в объектные транзакции, транзакции в операции виртуальных блочных устройств и, наконец, виртуальные операции в реальные.

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

Этот уровень играет роль, аналогичную менеджеру разделов в существующей системе.

Каждое виртуальное устройство (vdev) создается путем объединения устройств с использованием одного из вариантов — зеркалирования или RAID-Z. Создав виртуальные устройства, вы объединяете их в пул носителей.

Такой подход обеспечивает некоторую гибкость.

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

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

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

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

В отличие от других менеджеров разделов, ZFS определяет планирование ввода-вывода.

Каждая транзакция имеет определенный приоритет и временные рамки, которые планировщик обрабатывает на уровне vdev системы.

Основой этого уровня является блок управления данными (DMU), и на многих блок-схемах ZFS DMU — это все, что вы видите на этом уровне.

DMU предоставляет объекты для верхнего уровня и позволяет осуществлять атомарные операции.

Если у вас когда-либо случался сбой питания во время записи файла, возможно, вы запускали fsck, scandisk или что-то подобное.

В конце концов, у вас, вероятно, останутся поврежденные файлы.

Если бы это были текстовые файлы, возможно, вам повезло; повреждение можно легко устранить.

В противном случае, если файлы имели смешанную структуру, вы могли потерять весь файл.

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

Потом в журнал пишут «Я сделал это».

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

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

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

К сожалению, эта целостность не распространяется на файлы.

Если вы выполняете две записи из пользовательского приложения, возможно, что одна завершится, а другая — нет. Эта модель вызывает некоторые проблемы.

ZFS использует транзакционную модель.

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

Это возможно, поскольку ZFS использует механизм копирования при записи.

Каждый раз, когда ZFS записывает какие-либо данные, она записывает эти данные, чтобы освободить место на диске.

Затем он обновляет метаданные, говоря: «Это новая версия».

Если процесс записи не доходит до стадии обновления метаданных, ни один из старых данных не будет перезаписан.

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

Некоторые файловые системы, такие как UFS2 во FreeBSD и XFS в IRIX, уже поддерживают снимки, поэтому это не новая концепция.

Стандартная технология — создание раздела моментальных снимков.

После создания моментального снимка каждая операция записи заменяется последовательностью, которая копирует оригинал в раздел моментального снимка, а затем выполняет запись.

Излишне напоминать, что этот подход очень дорогостоящий.

В ZFS все, что вам нужно сделать для создания моментального снимка, — это увеличить количество ссылок на разделы.

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

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

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

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

Помимо ZPL, ZFS имеет еще один модуль на уровне интерфейса, известный как ZVOL. Этот слой выполняет более простое преобразование; Вместо того, чтобы выглядеть как файловая система, совместимая с POSIX, она выглядит как необработанное блочное устройство, что полезно для реализации существующих файловых систем, использующих пулы хранения данных ZFS. Порт FreeBSD изначально использует существующую файловую систему UFS2 поверх устройства ZVOL. Мне кажется, что порт Apple будет использовать HFS+ поверх ZVOL, чтобы позволить Apple поддерживать метаданные HFS+.

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

Поскольку ZFS уже поддерживает транзакции, возможно, на этом уровне можно использовать SQL или аналогичный интерфейс.

Благодаря низкой стоимости создания файловых систем каждый пользователь может создавать базы данных «на лету» и получать гораздо более гибкий интерфейс, чем тот, который предоставляет уровень POSIX. Проблема Microsoft WinFS — слишком сложно заставить всех поддержать подход, не основанный на файлах, — не применима, поскольку этот инструмент скорее дополнит, чем заменит текущую файловую систему.

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

К счастью, эта проблема решена, и ZFS может использовать тот же механизм, что и для сжатия.

Четко определенные квоты также не поддерживаются.

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

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

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

Если вы используете Windows, возможно, нет. С Linux ситуация несколько сложнее.

Реализация OpenSolaris выпускается под лицензией CDDL, которая не совместима с GPL. Есть два варианта поддержки этой файловой системы в Linux. Первый — сделать полностью кастомную реализацию, что потребует огромных усилий и поэтому вряд ли произойдет в ближайшем будущем.

Другой вариант — портировать ZFS на FUSE и запустить ее как пользовательский процесс.

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

Пользователи Ubuntu, которым нужна поддержка ZFS, могут переключиться на Nexenta, которая использует ядро OpenSolaris и среду рабочего стола GNU. Поскольку CDDL является пофайловой лицензией, она не влияет на общую лицензию проекта, позволяя использовать ее в большом количестве любых проектов, не имеющих лицензии, в которой указано, что «все компоненты этого проекта должны быть охвачены».

по лицензии, соответствующей этим условиям».