Files-11

Files-11 (также известна как on-disk structure (с англ. — «структура на диске», «дисковая структура») — файловая система, используемая в операционной системе OpenVMS, а также в более простой форме в более старой ОС RSX-11. Это иерархическая файловая система с поддержкой списков контроля доступа, запись-ориентированным вводом-выводом, удалённым сетевым доступом и версиями файлов.

Files-11 похожа на файловые системы, использовавшиеся в более ранних операционных системах от DEC, таких как TOPS-20 и RSTS/E, но значительно более прогрессивна.

Родная файловая система OpenVMS происходит из более старых операционных систем DEC и во многом похожа на них. Главным отличием является расположение каталогов. Эти файловые системы предоставляют некоторую форму рудиментарной неиерархической структуры каталогов, обычно основанную на выделении одного каталога на одну учётную запись пользователя. В RSTS/E каждая учётная запись пользователя была представлена двумя числами, парой [проект.программист], и имела один ассоциированный каталог. Специальные системные файлы, такие как исполняемые файлы программ и сама ОС, хранились в каталоге, зарезервированном для системной учётной записи.

Несмотря на то, что это было применимо на системах PDP-11, обладавших ограниченной ёмкостью постоянного запоминающего устройства, системы VAX с гораздо большими жёсткими дисками требовали более гибкого метода хранения файлов: в частности иерархического расположения каталогов, наиболее заметного усовершенствования в ODS-2.

Files-11 является общим названием для пяти отдельных файловых систем, известных как уровни с 1 по 5 на-дисковой структуры (ODS).

ODS-1 — плоская файловая система, использовавшаяся в ОС RSX-11; поддерживается старыми версиями ОС VMS для совместимости с RSX-11, но никогда не использовалась самой VMS; была почти повсеместно заменена на ODS-2 и ODS-5.

ODS-2 — стандартная файловая система для VMS, до сих пор остаётся наиболее часто используемой файловой системой для системного диска (диск, на который установлена операционная система).

Хотя их редко упоминают по обозначению их уровня ODS, ODS-3 и ODS-4 являются поддержкой Files-11 для файловых систем компакт-дисков ISO 9660 и High Sierra, соответственно.

ODS-5 является расширенной версией ODS-2, доступной для платформ Alpha или Itanium, в которой добавлена поддержка сохраняемого регистра имён файлов с не-ASCII символами и улучшена поддержка иерархических каталогов. Изначально она была предназначена для обслуживания файлов в Microsoft Windows или других отличных от VMS системах, как часть проекта «NT affinity», но также используется на пользовательских дисках и интернет-серверах.

Все файлы и каталоги в файловой системе Files-11 находятся в одном или более родительских каталогах, и в конце концов в корневом каталоге — основном файловом каталоге (master file directory, MFD). Следовательно файловая система организована в древовидную структуру.

В примере справа File 2 имеет запись в каталогах Dir 2 и Dir 3; он находится в обоих каталогах одновременно. Даже если его удалить из одного каталога, то он всё еще будет существовать в другом, пока его не удалят и оттуда. Это очень похоже на концепцию жёстких ссылок в UNIX, хотя здесь необходимо следить за тем, чтобы действительно не удалить файл на дисках, которые не поддерживают жёсткие ссылки. Жёсткие ссылки доступны только на дисках с ODS-5, и только если они разрешены на этих дисках.

Функционирующая система VMS имеет доступ к одному или нескольким постоянно подключенным дискам, каждый из которых содержит полноценную независимую файловую систему. Они являются либо локальным хранилищем, либо, в случае кластера, хранилищем, используемым совместно с удалёнными системами.

В кластерной конфигурации OpenVMS, не-приватные диски совместно используются всеми узлами кластера (см. рисунок 1). В такой конфигурации два системных диска доступны для обоих узлов кластера, но приватный диск не находится в совместном использовании: он подключен только для использования отдельным пользователем или процессом на первой машине. Доступ к файлам в кластере управляется OpenVMS Distributed Lock Manager, неотъемлемой частью файловой системы.

Множество дисков может быть скомбинировано в один больший логический диск или объединенный том (volume set). Диски могут также автоматически копироваться в теневые наборы для защиты данных или более высокой производительности при чтении.

Диск обозначается или его физическим именем или (более часто) логическим именем, определённым пользователем. Например, загрузочное устройство (системный диск) может иметь физическое имя $3$DKA100, но на него обычно будет ссылаться логическое имя SYS$SYSDEVICE.

Файловая система на каждом диске (за исключением ODS-1) является иерархической. Полная спецификация файла состоит из имени узла, имени учётной записи пользователя и его пароля, имени устройства, каталога, имени файла, типа файла и версии файла, и имеет следующий формат:

NODE"accountname password"::device:[directory.subdirectory]filename.type;version

узел"пользователь пароль"::устройство:[каталог]имя_файла.тип_файла;версия

Например, [DIR1.DIR2.DIR3]FILE.EXT будет ссылаться на последнюю версию файла FILE.EXT, на диске, установленном по умолчанию, в каталоге [DIR1.DIR2.DIR3].

DIR1 является подкаталогом основного файлового каталога (MFD) или корневого каталога, а DIR2 — подкаталогом DIR1. Основной файловый каталог определён как [000000].

Многие части спецификации файла могут быть опущены, тогда они берутся из текущей спецификации файла по умолчанию. Спецификация файла по умолчанию заменяет концепцию «текущего каталога» в других операционных системах предоставлением набора установок по умолчанию для узла, имени устройства и каталога. Все процессы имеют спецификацию файла по умолчанию, которая содержит имя диска и каталог, и большинство подпрограмм файловой системы VMS принимает спецификацию файла по умолчанию, которая также может содержать тип файла; команда TYPE, например, по умолчанию ожидает «.LIS» в качестве типа файла, поэтому, если команде TYPE указать имя файла F без расширения, то она попытается открыть файл F.LIS.

Каждый файл имеет номер версии, который по умолчанию равен 1, если нет других версий этого файла (в противном случае больше на единицу, чем наивысшая версия). Каждый раз при сохранении или перезаписи существующей версии будет создан новый файл с тем же именем, но увеличенным на 1 номером версии. Старые версии могут быть удалены явно командами DELETE или PURGE, или, опционально, более старые версии файла могут быть удалены автоматически при достижении предела количества версий файла (устанавливается командой SET FILE/VERSION_LIMIT). Старые версии в этом случае не перезаписываются, а хранятся на диске и могут быть восстановлены в любое время. Заложенный предел номера версии — 32767. Режим работы механизма присваивания версий может быть легко отключён, если в нём нет необходимости. В частности, файлы, которые обновляются напрямую, такие как базы данных, не создают новых версий, если только это не запрограммировано специально.

ODS-2 ограничена 8 уровнями вложенности каталогов, и именами файлов только в верхнем регистре, длина буквенно-цифровых имён (плюс символ подчёркивания, тире и знак доллара) - до 39.39 символов (39 для имени файла и еще 39 для расширения). В ODS-5 расширен набор символов до символов в нижнем регистре и большинства других символов ASCII, а также символов ISO Latin-1 и Unicode, увеличена максимальная длина имени файла и не ограничено количество уровней вложенности каталогов. При конструировании полного имени файла для файла ODS-5, который использует символы, неразрешённые в ODS-2, используется специальный синтаксис «^» для сохранения обратной совместимости; файл «file.tar.gz;1» на диске с ODS-5, например, будет называться «file^.tar.gz» — имя файла будет «file.tar», а расширение - «.gz».

Защита файлов в VMS определяется двумя механизмами: управлением доступом на основе кода идентификации пользователя (UIC) и управлением доступом на основе списков контроля доступа. Управление доступом на основе кода идентификации пользователя базируется на владельце файла и его коде идентификации, или коде идентификации пользователя, желающего получить доступ к файлу. Доступ определяется четырьмя группами разрешений:

• Системные разрешения (System)
• Разрешения владельца (Owner)
• Групповые разрешения (Group)
• Разрешения мира (World)

И четырьмя битами разрешений:

• Чтение (Read)
• Запись (Write)
• Исполнение (Execute)
• Удаление (Delete)

Системный доступ применяется к любому пользователю, код идентификации которого меньше или равен параметру SYSGEN MAXSYSGROUP (обычно 8 или 10 восьмеричных) (например пользователь SYSTEM); доступ владельца и группы применяются ко владельцу файла и его группе, к которой он принадлежит, а доступ мира применяется к любому другому пользователю. Также есть пятый бит разрешений — Управление (Control), который используется для определения доступа к изменению метаданных файла таких как защита. Эта группа не может быть задана явно; она всегда задана для Системы и Владельца, и никогда не задана для Группы или Мира.

Управление доступом на основе кода идентификации также находится под влиянием от четырёх системных привилегий, которые позволяют удерживать их для предотвращения перехвата управления доступом:

• BYPASS: пользователь неявно имеет доступ на RWED ко всем файлам, независимо от защиты файла;
• READALL: пользователь неявно имеет доступ на R ко всем файлам;
• SYSPRV: пользователь может иметь доступ к файлам на основе защиты System;
• GRPPRV: пользователь может иметь доступ к файлам на основе защиты System, если группа их UIC достигает группы файла.

ACL позволяет назначать дополнительные привилегии пользователю или группе; например, коду идентификации пользователя веб-сервера может быть дано право читать все файлы в отдельном каталоге. ACL могут быть помечены как наследуемые, где ACL файлов для каталога применяются ко всем файлам в нём. Изменения в списки контроля доступа вносятся командой EDIT/ACL и имеют форму пары идентификатор/права_доступа. Например, запись в ACL команды

(IDENTIFIER=HTTP$SERVER,ACCESS=READ+EXECUTE)

позволит пользователю HTTP$SERVER читать и исполнять файлы.

Логическое имя является системной переменной, которая может ссылаться на диск, каталог или файл, или содержать другую программную информацию. Например, логическое имя SYS$SYSDEVICE содержит системное загрузочное устройство. Логические имена обычно ссылаются на один каталог или диск, например, SYS$LOGIN, которое является домашним каталогом (каталогами) учётной записи пользователя; эти логические имена не могут использоваться в качестве настоящих имён дисков — SYS$LOGIN:[DIR]FILE не является правильной спецификацией файла. Тем не менее, скрытые логические имена, определённые командой DEFINE/TRANSLATION=CONCEALED, могут использоваться для этого; эти корневые каталоги заканчиваются символом точки («.») в спецификации каталога, поэтому команда

$ DEFINE/TRANS=CONCEAL HOME DISK$USERS:[username.]

позволит использовать HOME:[DIR]FILE. Более распространены простые логические имена, которые указывают на определённые каталоги, связанные с какими-нибудь прикладным ПО, которое может располагаться на любом диске или в любом каталоге. Поэтому логическое имя ABC_EXE может указывать на каталог исполнимых программ приложения ABC, а ABC_TEMP может указывать на каталог временных файлов для того же самого приложения и этот каталог может быть на том же диске и в том же каталоге, что и ABC_EXE, или может быть где угодно на другом диске (и в другом дереве каталогов).

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

Ближайшей, не родственной VMS, операционной системой, поддерживающей концепцию логических имён, является AmigaOS, посредством команды ASSIGN. Входящая в AmigaOS дисковая операционная система AmigaDOS, похоже, многое взяла из VMS, учитывая, что TRIPOS (портом которой является AmigaDOS) была создана под сильным влиянием VMS. Например, имена физических устройств следуют шаблону типа DF0: для первого флоппи-дисковода, CDROM2: для третьего дисковода CD-ROM, и т. д. Тем не менее, с тех пор как система может загружаться с любого подключённого дисковода, операционная система создаёт логическое имя SYS:, назначенное автоматически ссылающимся на используемое загрузочное устройство. Другие назначения, LIBS:, PREFS:, C:, S: и прочие также создаются, сами не ссылающиеся на SYS:. Пользователям, конечно же, тоже разрешается создавать и удалять их собственные назначения.

Логические имена могут ссылаться на другие логические имена (до предопределённого предела вложенности, равного 10) и могут содержать списки имён для поиска существующих имён файлов. Некоторыми часто ссылающимися логическими именами являются:

Логическое имя	Значение
SYS$INPUT	равнозначно стандартному вводу, источник данных для программ
SYS$OUTPUT	равнозначно стандартному выводу, получатель данных от программ
SYS$ERROR	равнозначно стандартному журналу ошибок, получатель сообщений об ошибках от программ
SYS$COMMAND	источник командных файлов (то есть командных файлов с расширением .COM)
TT	терминал, связанный с процессом
SYS$PRINT	принтер или очередь печати по умолчанию
SYS$LOGIN	домашний каталог для каждого пользователя
SYS$SCRATCH	временная папка, каталог для временных файлов
SYS$SYSTEM	каталог, содержащий большинство системных программ и несколько жизненно важных файлов данных, таких как системный файл авторизации (учётные записи и пароли)
SYS$SHARE	совместно используемые библиотеки времени исполнения, исполнимые файлы и т. д.
SYS$LIBRARY	системные и дополнительные библиотеки

Record Management Services (сокр. RMS, рус. Службы управления записью) является структурным уровнем ввода-вывода операционной системы VMS. RMS предоставляет всеобъемлющую программную поддержку для управления структурированными файлами, такими как состоящие из записей и индексированные файлы баз данных. Файловая система VMS может быть представлена как база данных, содержащая серии записей, каждая из которых имеет одно из многих индивидуальных полей. Текстовый файл, например, является списком записей (строк) разделённых символом новой строки. RMS является примером реализации запись-ориентированной файловой системы.

Есть 4 формата записей определяемых RMS:

• Фиксированной длины — все записи в файле имеют одинаковую длину.
• Переменной длины — записи различаются по длине, и каждая запись предваряется счётчиком байт, дающим её длину.
• Запись переменной длины с фиксированным контрольным блоком — записи различаются по длине, но предваряются контрольным блоком фиксированной длины.
• Поток — записи различаются по длине, и каждая запись отделена от следующей завершающим символом. Текстовый файл является примером файла потокового формата, использующего символы конца строки или перевода каретки для разделения записей.

Есть 4 метода доступа к записям, или метода нахождения существующих записей из файлов:

• Последовательный доступ — изначально с отдельными записями, последующие записи находятся по порядку до конца файла.
• Относительный доступ по номеру записи — записи находится по её номеру относительно начала файла.
• Доступ по адресу записи файла — записи находятся прямо по их расположению в файле (RFA — Record File Address, рус. Адрес записи файла).
• Индексный доступ — записи находятся по ключу, в форме соответствия ключ-значение (ассоциативный массив).

На уровне диска ODS представляет файловую систему как массив блоков, блок состоит из 512 расположенных рядом байт на одном физическом диске (томе). Дисковые блоки назначены в кластеры (изначально 3 непрерывно расположенных блока, но позже увеличено для больших размеров дисков). В идеале, файл на диске должен быть полностью непрерывным, то есть блоки, содержащие файл, должны быть расположены последовательно, но фрагментация диска будет иногда требовать размещать файл в непоследовательных кластерах, в случае чего фрагменты будут называться «экстентами». Диски могут комбинироваться с другими дисками, образуя объединённый том, а файлы храниться где угодно на всем наборе дисков, но большие размеры дисков уменьшают использование объединенных томов, потому что управление единичными дисками проще.

Каждый файл на диске (или объединённом томе) с файловой системой Files-11 имеет уникальный файловый идентификатор (FID), состоящий из 3 чисел: номер файла (NUM), номер файловой последовательности (SEQ) и относительный номер тома (RVN). NUM показывает где расположен файл INDEXF.SYS, содержащий метаданные файлов; SEQ — номер поколения который увеличивается когда файл удаляется и создается другой файл повторно используя ту же запись в INDEXF.SYS (поэтому любые оборванные ссылки на старый файл не будут случайно указывать на новый); RVN показывает номер тома на котором хранится файл, когда используется объединённый том.

Структурная поддержка тома ODS предусмотрена посредством файла каталога — специального файла, содержащего список имён файлов, версий файлов и связанных с ними файловыми идентификаторами (FID). Корнем структуры каталогов является основной файловый каталог (MFD), корневой каталог, который содержит (напрямую или косвенно) каждый файл тома.

(картинка)

Эта диаграмма показывает пример каталога, содержащего 3 файла, и то, как каждое имя файла отображено в записи в INDEXF.SYS (каждая запись INDEXF содержит больше информации, здесь показаны только несколько первых пунктов).

На верхнем уровне файловой системы ODS находится основной файловый каталог (MFD), содержащий все файлы каталогов (directory files) высшего уровня (включая себя) и несколько системных файлов, используемых для хранения информации файловой системы. На томах с ODS-1 используется двухуровневая структура каталогов: каждый код идентификации пользователя (UIC) связан с каталогом пользовательских файлов (UFD) в виде [GROUP.USER] ([ГРУППА.ПОЛЬЗОВАТЕЛЬ]). На ODS-2 и более поздних томах расположение каталогов в основном файловом каталоге имеет произвольную форму, будучи ограничено пределом вложенности каталогов (8 уровней в ODS-2 и неограниченно в ODS-5). На объединённых томах основной файловый каталог обычно хранится на первом томе и содержит подкаталоги всех томов.

Следующие системные файлы представлены в основном файловом каталоге ODS:

• INDEXF.SYS;1 — индексный файл
• BITMAP.SYS;1 — файл битовой карты хранилища данных
• BADBLK.SYS;1 — файл плохих блоков
• 000000.DIR;1 — файл каталога самого основного файлового каталога
• CORIMG.SYS;1 — файл образа ядра
• VOLSET.SYS;1 — файл списка томов объединённого тома (только в ODS-2/5)
• CONTIN.SYS;1 — файл продолжения (только ODS-2/5)
• BACKUP.SYS;1 — файл журнала резервного копирования (только в ODS-2/5)
• BADLOG.SYS;1 — ожидающие рассмотрения плохие блоки (только в ODS-2/5)
• SECURITY.SYS;1 — профиль безопасности тома (только в ODS-2/5)
• QUOTA.SYS;1 — файл квоты (опциональный и доступный только в ODS-2/5)
• GPT.SYS;1 — таблица разделов GUID (GPT) (загрузочные структуры EFI для OpenVMS I64, опционально для OpenVMS Alpha)

Помните, что реализация файловой системы сама по себе ссылается на эти файлы не по именам, а по их файловым идентификаторам, которые всегда имеют одно и то же значение. Так, например, INDEXF.SYS это всегда файл с NUM = 1 и SEQ = 1.

Индексный файл содержит самую основную информацию об объединённом томе Files-11.

Есть два способа организации INDEXF.SYS, традиционная организация и организация, используемая на дисках с GPT.SYS со структурами таблицы разделов GUID (GPT).

При традиционной организации, блок 1 является загрузочным блоком, который содержит местоположение первичного загрузочного образа, используемого для загрузки операционной системы VMS. Он всегда расположен на диске в логическом блоке 0, поэтому микропрограмма аппаратного обеспечения может прочитать его. Этот блок есть всегда, даже на несистемных (не загрузочных) томах.

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

На дисках, где есть GPT.SYS, в нём содержится эквивалент загрузочного блока (известный как главная загрузочная запись (Master Boot Record (MBR)) и на них нет первичного домашнего блока. Все домашние блоки представленные на диске с GPT являются альтернативными домашними блоками. Эти структуры не включаются в INDEXF.SYS и блоки из файла INDEXF.SYS не используются.

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

• Секция header содержит NUM и SEQ, информацию о защите (безопасности) и расположение оставшейся части заголовка файла.
• Секция ident содержит метаданные учётных записей: имя файла, времена создания и изменения и время последнего резервного копирования.
• Секция map описывает какой блоки (экстент) физического диска отображается на каждый виртуальный блок файла.
• Секция access control list содержит информацию списков контроля доступа о файле.
• Секция reserved area — это место в конце заголовка файла, которое не используется операционной системой. Может использоваться для информации поставщика или потребителя.
• Последние 2 байта заголовка файла являются контрольной суммой предыдущих 255 слов, для проверки правильности заголовка.

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

(картинка) Структура заголовка файла INDEXF.SYS

Заголовок файла начинается с 4 смещений (IDOFFSET, MPOFFSET, ACOFFSET и ROFFSET). Так как размер областей после заголовков фиксированной длины может варьироваться (такие области как map и ACL), смещения требуются для определения местоположения этих дополнительных областей. Каждое смещение равно числу 16-битных слов от начала заголовка файла до начала области, для которой вычислено смещение.

Если файл требует множества заголовков, то добавочный номер сегмента (SEGNUM) содержит в себе порядковый номер этого заголовка, начиная с 0 в первой записи в INDEXF.SYS.

STRUCLEV содержит текущий уровень структуры (в старшем байте) и версию (в младшем байте) файловой системы; ODS-2 имеет уровень структуры 2. Увеличение номера версии свидетельствует об обратно совместимом изменении, что может игнорироваться старым программным обеспечением; изменения в самом уровне структуры являются несовместимыми.

W_FID (содержит 3 значения: FID_NUM, FID_SEQ и FID_RVN, соответственно файл, последовательность и относительный номер тома) содержит идентификатор этого файла; EXT_FID (также состоит из 3 значений) держит расположение следующего расширенного заголовка, если он есть. В обоих этих значениях, RVN определён как 0 для представления «текущего» тома (0 нормально не является допустимым RVN).

FILECHAR содержит несколько флагов, которые предписывают, как файлу обрабатываться или организовываться:

• NOBACKUP устанавливает, что файл будет проигнорирован при выполнении резервного копирования.
• WRITEBACK разрешает кешируемую (отложенную) запись в файл.
• READCHECK устанавливает, что все чтения файла производятся дважды и сравниваются для обеспечения целостности данных.
• WRITCHECK — все записи будут проверены последующим чтением и сравнением.
• CONTIGB — операционная система попытается разместить файл в хранилище настолько последовательно, насколько это возможно.
• LOCKED — установлен, если файл заблокирован при завершении доступа. Если установлен, это свидетельствует, что файл не был должным образом закрыт после его последнего использования, и содержимое может быть несогласованным.
• CONTIG указывает, что файл хранится на диске последовательно; то есть каждый виртуальный блок i отображён на логический (физический) блок i + k, где k — константа
• BADACL — установлен, если файл имеет неправильный список контроля доступа.
• SPOOL — установлен, если файл является буферным, как промежуточный файл используемый в процессе печати.
• DIRECTORY — установлен, если файл является каталогом.
• BADBLOCK — установлен, если файл содержит плохие блоки.
• MARKDEL — установлен, если файл был помечен для удаления, но всё еще используется; он будет удалён сразу после закрытия последним пользователем.
• NOCHARGE, если установлен, то указывает, чтобы место используемое файлом не бралось из квоты владельца хранилища.
• ERASE — указывает чтобы содержимое файла было затёрто при его удалении.

Флаг ACCMODE описывает уровень привилегии, с которым процесс может выполняться в порядке доступа к файлу. VMS определяет 4 уровня привилегий: user, supervisor, exec и kernel. Каждый тип доступа — чтение, запись, выполнение и удаление — кодируется 2-битным целочисленным значением.

Флаг FILEPROT содержит информацию дискреционного контроля доступа применимую к файлу. Он разделён на 4 группы по 4 бита каждая: система, владелец, группа и мир. Бит 0 соответствует доступу на чтение, бит 1 — на запись, бит 2 — на выполнение и бит 3 — на удаление. Установка бита запрещает частичный доступ группе; снятие бита — разрешает.

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

• Файл битовой карты хранилища: BITMAP.SYS

Файл битовой карты отвечает за хранение информации об использованном и доступном месте в томе. Он содержит блок контроля хранения (storage control block, SCB), который включает суммарную информацию и битовую карту — массив битов, показывающих свободен или распределён кластер блоков на диске. В ранних версиях VMS кластер состоял из 3 блоков, но так как размеры дисков увеличились, то и размер кластера тоже.

• Файл плохих блоков: BADBLK.SYS

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

• Файл списка томов объединённого тома: VOLSET.SYS

Список томов объединённого тома расположен на первом томе объединённого тома и содержит список метки всех томов в наборе и имя набора томов.

• Файл продолжения: CONTIN.SYS

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

• Файл квоты: QUOTA.SYS

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

• Профиль безопасности тома: SECURITY.SYS

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

• Таблица разделов GUID: GPT.SYS

Этот файл перекрывает и защищает MBR (Master Boot Record, главная загрузочная запись) и GPT (GUID Partitioning Table) дисковые структуры, используемые для EFI-совместимых микропрограмм. Этот файл создаётся по умолчанию в ходе инициализации диска в OpenVMS I64, и создаётся опционально (командой INITIALIZE/GPT) в OpenVMS Alpha.

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

1. Andrew C. Goldstein, VAX/VMS Software Development (1985-01-11). Files-11 On-Disk Structure Specification.
2. Hewlett-Packard Development Company, L.P. (September 2003). «Appendix A: Files-11 Disk Structure». OpenVMS System Manager’s Manual, Volume 2: Tuning, Monitoring, and Complex Systems.
3. Kirby McCoy (1990). VMS File System Internals. Digital Press. ISBN 1-55558-056-4.

• Документация OpenVMS: Руководство по работе с файлами в OpenVMS
• http://www.vms2linux.de  (англ.)