Логическая организация файла

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

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

 

Модель файла, в соответствии с которой содержимое файла представляется неструктурированной последовательностью байт, стала популярной вместе с ОС UNIX, и теперь широко используется в современных ОС. Неструктурированная модель файла позволяет легко организовать разделение файла между несколькими приложениями, поскольку разные приложения могут по-своему структурировать и интерпретировать данные, содержащиеся в файле.

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

Известно два фундаментальных способа организации файлов:

последовательный файл,

файл прямого доступа.

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

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

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

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

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

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

 

 

Лекция 11. Тема: Связи

Современные файловые системы имеют структуру дерева или графа каталогов. Подходы к организации структуры каталогов разные для разных ОС: некоторые системы реализуют единое дерево каталогов или граф каталогов, куда могут подключаться (монтироваться) отдельные файловые системы, размещенные на разных дисках; другие системы обозначают отдельные разделы диска буквами алфавита и работают с соответствующими файловыми системами отдельно. Дерево каталогов становится графом при наличии связей. Многие файловые системы дают возможность задавать несколько имен для одного файла. Такие имена называются связями (links). Связи могут быть жесткими (альтернативное имя для файла) и символьными (файл, который содержит ссылки на другой файл или каталог).

Пользователи операционных систем Microsoft Windows знакомы с таким понятием, как ярлыки. Однако, в файловой системе NTFS есть нечто большее - жесткие ссылки (Hard Links). Если в случае с простыми ярлыками указатель на файл есть только один (в одном каталоге), а по разным директориям могут быть разбросаны ссылки на него (ярлыки), то в случае с Hard Link на файл делаются абсолютно равноправные указатели в разных каталогах, указывающие на один и тот же объект.

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

При работе с жесткими ссылками следует знать, что:

1. жесткие связи могут быть только на NTFS-разделе, и связаны могут быть только файлы, находящиеся на одном разделе;

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

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

4. внешне (в отличие от простых ярлыков) нет никаких признаков того, что файл имеет жесткую связь;

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

1. все связанные файлы абсолютно равноправны;

7. при удалении связанных файлов удален будет только конкретный выбранный файл, а остальные останутся (их тоже по отдельности можно удалить);

8. Hard Link делается для файлов, для директорий существует другое средство - Junction Points.

Для создания жестких связей в POSIX используется системный вызов link(). Для Windows – это функция CreateHardLink().

Несмотря на то, что жесткие связи существуют уже почти десять лет, программ для работы с ними немного: Hard Link Magic, Xplorer², PropertyEditor, Xln: File System Link creation utility - утилита Windows, позволяющая из командной строки создать жесткую ссылку или обыкновенный ярлык.

Символьная связь (Symbolic link) работает наподобие ярлыка, однако располагается непосредственно в файловой системе и указывает на конкретный объект. В отличие от файлов LNK с символьными ссылками без проблем работают все программы.Символическая связь — специальный файл в файловой системе, для которого не формируются никакие данные, кроме одной текстовой строки с указателем. Эта строка трактуется как путь к файлу, который должен быть открыт при попытке обратиться к данной ссылке (файлу). Символьная ссылка занимает ровно столько места в файловой системе, сколько требуется для записи её содержимого (нормальный файл занимает как минимум один блок раздела).

Целью ссылки может быть любой объект – например, другая ссылка, файл, папка.

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

При работе с символьными связями следует знать, что:

- символьные связи могут быть только на NTFS-разделах, начиная с ОС Windows 2000;

- связаны могут быть директории, находящиеся на разных логических и физических дисках;

- "привязанный" каталог можно перемещать в любое место на NTFS;

- cвязанные символьной связью директории равноправны по использованию, но не равноправны по переименованию и удалению (вы не можете удалить или переименовать первый каталог, пока существуют созданные на него каталоги-ссылки);

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

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

- внешне (в отличии от простых ярлыков) нет никаких признаков, что каталог имеет символьную связь;

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

Для создания символьных связей в POSIX используется системный вызов symlink().Символическая связь (symbolic links) — доступна с Windows Vista. Может указывать и на файлы, и на директории. Для Windows 7– это команда mklink.

Создание символической ссылки.

MKLINK [[/D] | [/H] | [/J]] Ссылка Назначение

/D Создание символической ссылки на каталог.

По умолчанию создается символическая ссылка на файл.

/H Создание жесткой связи вместо символической ссылки.

/J Создание соединения для каталога.

Ссылка Имя новой символической ссылки.

 

Операции над файлами и каталогами

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

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

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

Файловые операции.

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

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

3. Создание файла. Эта операция создает на диске новый файл нулевой длины. После создания файл автоматически открывается.

4. Удаление файла. С помощью этой операции файл удаляется и освобождается занятое им дисковое пространство. Эта операция недопустима для открытых файлов.

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

6. Запись в файл. Осуществляется с текущей позиции, данные записываются в файл из заранее выделенного буфера. Если на этой позиции уже есть данные, они будут перезаписаны. Эта операция может изменить размер файла.

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

8. Получение и задание атрибутов файла. Эти операции дают возможность считывать текущие значения всех или некоторых атрибутов файла или задавать для них новые значения.

9. Поиск. Данный системный вызов устанавливает файловый указатель в определенную позицию.

10. Переименование. Этот системный вызов позволяет изменить имя файла. Такое действие можно выполнить копированием файла.

11. Копирование файла.

12. Выполнить. Используя этот системный вызов, файл можно запустить на выполнение.

 

 

Основные функции Win 32 API для файлового ввода-вывода и соответствующие системные вызовы POSIX приведены ниже.

Функция Win 32 API	Системные вызовы UNIX	Описание
CreateFile	open	Создать или открыть файл; вернуть дескриптор файла
DeleteFile	unlink	Удалить существующий файл
CloseHandle	close	Закрыть файл
ReadFile	read	Прочитать данные из файла
WriteFile	write	Записать данные в файл
SetFilePointer	lseek	Установить указатель в файле в определенную позицию
GetFileAttributes	stat	Вернуть атрибуты файла
LockFile	fcntl	Заблокировать область файла для обеспечения взаимного исключения
UnlockFile	fcntl	Отменить блокировку области файла

 

 

Лекция 12. Тема: Файлы, отображаемые в память

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

Файлы, отображаемые в память (memory-mapped files, далее — MMF),
их использование может дать существенный прирост производительности по сравнению с обычной буферизированной работой с файлами.

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

Что это даёт? Допустим, перед нами стоит задача обработки большого файла (несколько десятков или даже сотен мегабайт). Казалось бы, задача тривиальна — открываем файл, поблочно копируем из него в память, обрабатываем. При этом каждый блок копируется во временный кэш, затем из него в нашу память. И так с каждым блоком. Налицо неоптимальное расходование памяти под кэш + куча операций копирования. Что же делать? Тут-то нам на помощь и приходит механизм MMF. Когда мы обращаемся к памяти, в которую отображен файл, данные загружаются с диска в кэш, затем делается отображение кэша в адресное пространство нашей программы. Если эти данные удаляются — отображение отменяется. Таким образом, мы избавляемся от операции копирования из кэша в буфер. Кроме того, не нужно заботится по поводу оптимизации работы с диском — всю работу берёт на себя ядро ОС. Чтобы воспользоваться этой возможностью, мы должны сообщить ядру о нашем желании отобразить файл в память. Делается это с помощью функции mmap().

По сравнению с доступом к памяти, традиционный доступ к файлам выглядит запутанным и неудобным. По этой причине некоторые ОС, начиная с MULTICS, обеспечивают отображение файлов в адресное пространство выполняемого процесса. Это выражается в появлении двух новых системных вызовов: MAP (отобразить) и UNMAP (отменить отображение). Первый вызов передает операционной системе в качестве параметров имя файла и виртуальный адрес, и операционная система отображает указанный файл в виртуальное адресное пространство по указанному адресу.

Предположим, например, что файл f имеет длину 64 К и отображается на область виртуального адресного пространства с начальным адресом 512 К. После этого любая машинная команда, которая читает содержимое байта по адресу 512 К, получает 0-ой байт этого файла и т.д. Очевидно, что запись по адресу 512 К + 1100 изменяет 1100 байт файла. При завершении процесса на диске остается модифицированная версия файла, как если бы он был изменен комбинацией вызовов SEEK и WRITE.

В действительности при отображении файла внутренние системные таблицы изменяются так, чтобы данный файл служил хранилищем страниц виртуальной памяти на диске. Таким образом, чтение по адресу 512 К вызывает страничный отказ, в результате чего страница 0 переносится в физическую память. Аналогично, запись по адресу 512 К + 1100 вызывает страничный отказ, в результате которого страница, содержащая этот адрес, перемещается в память, после чего осуществляется запись в память по требуемому адресу. Если эта страница вытесняется из памяти алгоритмом замены страниц, то она записывается обратно в файл в соответствующее его место. При завершении процесса все отображенные и модифицированные страницы переписываются из памяти в файл.

Отображение файлов лучше всего работает в системе, которая поддерживает сегментацию. В такой системе каждый файл может быть отображен в свой собственный сегмент, так что k-ый байт в файле является k-ым байтом сегмента. На рисунке 2.38,а изображен процесс, который имеет два сегмента-кода и данных. Предположим, что этот процесс копирует файлы. Для этого он сначала отображает файл-источник, например, abc. Затем он создает пустой сегмент и отображает на него файл назначения, например, файл ddd.

С этого момента процесс может копировать сегмент-источник в сегмент-приемник с помощью обычного программного цикла, использующего команды пересылки в памяти типа mov. Никакие вызовы READ или WRITE не нужны. После выполнения копирования процесс может выполнить вызов UNMAP для удаления файла из адресного пространства, а затем завершиться. Выходной файл ddd будет существовать на диске, как если бы он был создан обычным способом.

Хотя отображение файлов исключает потребность в выполнении ввода-вывода и тем самым облегчает программирование, этот способ порождает и некоторые новые проблемы. Во-первых, для системы сложно узнать точную длину выходного файла, в данном примере ddd. Проще указать наибольший номер записанной страницы, но нет способа узнать, сколько байт в этой странице было записано. Предположим, что программа использует только страницу номер 0, и после выполнения все байты все еще установлены в значение 0 (их начальное значение). Быть может, файл состоит из 10 нулей. А может быть, он состоит из 100 нулей. Как это определить? Операционная система не может это сообщить. Все, что она может сделать, так это создать файл, длина которого равна размеру страницы.

Рис. 2.38. (а) Сегменты процесса перед отображением файлов в адресное пространство; (б) Процесс после отображения существующего файла abc в один сегмент и создания нового сегмента для файла ddd

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

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

 

 

Лекция 13. Тема: Физическая организация файловых систем