Как называется граф с помощью которого можно изобразить файловую систему семейства unix
Обновлено: 06.07.2024
Файловой системы Unix ( UFS ) является файловая система поддерживается многими Unix и Unix-подобных операционных систем. Это дальний потомок исходной файловой системы, используемой версией 7 Unix .
Позже в Unix- системах использовалась быстрая файловая система Беркли ( BSD Fast File System , FFS ), которая отличается от UFS. [2]
СОДЕРЖАНИЕ
Том UFS состоит из следующих частей:
- Несколько блоков в начале раздела зарезервированы для загрузочных блоков (которые должны быть инициализированы отдельно от файловой системы)
- Суперблок, содержащий магическое число, идентифицирующее это как файловую систему UFS, и некоторые другие важные числа, описывающие геометрию и статистику этой файловой системы, а также параметры настройки поведения.
- Набор групп цилиндров. Каждая группа цилиндров состоит из следующих компонентов:
- Резервная копия суперблока
- Заголовок группы цилиндров со статистикой, списками свободных номеров и т. Д., Относящимися к этой группе цилиндров, как и в суперблоке
- Количество индексных дескрипторов , каждый из которых содержит атрибуты файла.
- Ряд блоков данных
Inode нумеруются последовательно, начиная с 0. Inode 0 зарезервирован для нераспределенных записей каталога, inode 1 был inode файла плохого блока в исторических версиях UNIX, за ним идёт inode для корневого каталога , который всегда inode 2 и inode. для каталога lost + found, который является индексом 3.
Файлы каталога содержат только список имен файлов в каталоге и индексный дескриптор, связанный с каждым файлом. Все метаданные файла хранятся в индексном дескрипторе.
Ранние версии файловых систем Unix назывались просто FS . FS включала только загрузочный блок, суперблок, группу индексных дескрипторов и блоки данных. Это хорошо работало для небольших дисков, для которых были разработаны ранние Unix, но по мере развития технологий и увеличения размеров дисков перемещение головки вперед и назад между скоплением inodes и блоками данных, на которые они ссылались, вызывало перегрузку . Маршалл Кирк МакКусик , в то время аспирант в Беркли , оптимизировал FFS (Fast File System) BSD 4.2 , придумав группы цилиндров, которые разбивают диск на более мелкие части, причем каждая группа имеет свои собственные индексы и блоки данных.
Цель BSD FFS - попытаться локализовать связанные блоки данных и метаданные в одной группе цилиндров и, в идеале, все содержимое каталога (как данные, так и метаданные для всех файлов) в той же или соседней группе цилиндров, таким образом уменьшение фрагментации, вызванной разбросом содержимого каталога по всему диску.
Некоторые параметры производительности в суперблоке включали количество дорожек и секторов, скорость вращения диска, скорость головки и выравнивание секторов между дорожками. В полностью оптимизированной системе головку можно было перемещать между близкими дорожками, чтобы читать разбросанные сектора из чередующихся дорожек, ожидая вращения диска.
По мере того, как диски становились все больше и больше, оптимизация на уровне секторов стала устаревшей (особенно с дисками, которые использовали линейную нумерацию секторов и переменные сектора на дорожку). С большими дисками и большими файлами фрагментированное чтение стало большей проблемой. Чтобы бороться с этим, BSD первоначально увеличила размер блока файловой системы с одного сектора до 1 КБ в 4.0 BSD; а в FFS увеличил размер блока файловой системы с 1 КБ до 8 К. Это имеет несколько эффектов. Вероятность того, что секторы файла будут смежными, намного выше. Объем служебных данных для перечисления блоков файла уменьшается, в то время как количество байтов, представляемых любым заданным числом блоков, увеличивается.
Также возможны диски большего размера, поскольку максимальное количество блоков ограничено фиксированным числом блоков разрядности. Однако при больших размерах блоков диски с большим количеством небольших файлов будут тратить впустую пространство, поскольку каждый файл должен занимать хотя бы один блок. Из-за этого в BSD добавлена фрагментация на уровне блоков , также называемая перераспределением блоков, объединением хвостов или упаковкой хвостов , когда последний частичный блок данных из нескольких файлов может храниться в одном блоке «фрагмента» вместо нескольких, по большей части, пустых блоков ( Аллен 2005 ).
Поставщики некоторых проприетарных систем Unix, таких как SunOS / Solaris , System V Release 4 , HP-UX и Tru64 UNIX , а также открытых систем, производных от Unix, таких как illumos , приняли UFS. Большинство из них адаптировали UFS для собственных нужд, добавив проприетарные расширения, которые могут не распознаваться версиями Unix других производителей. Многие [ какие? ] продолжали использовать исходный размер блока и ширину полей данных в качестве исходной UFS, поэтому некоторая степень совместимости чтения сохраняется на разных платформах. [ какой? ] [ необходима цитата ] [ согласно кому? ] Совместимость между реализациями в целом в лучшем случае неоднородна. [ согласно кому? ]
Начиная с Solaris 7 , Sun Microsystems включила функцию UFS Logging, которая принесла журналирование файловой системы в UFS, которая по-прежнему доступна в текущих версиях Solaris и illumos. [3] Solaris UFS также имеет расширения для больших файлов и больших дисков и другие функции.
В системах Unix 4.4BSD и BSD, производных от него, таких как FreeBSD , NetBSD , OpenBSD и DragonFlyBSD , реализация UFS1 и UFS2 разделена на два уровня: верхний уровень, который обеспечивает структуру каталогов и поддерживает метаданные (разрешения, владение, и т. д.) в структуре индексных дескрипторов и нижние уровни, которые предоставляют контейнеры данных, реализованные как дескрипторы. Это было сделано для поддержки как традиционных FFS, так и LFS.файловая система с лог-структурой и общим кодом для общих функций. Верхний уровень называется «UFS», а нижние уровни - «FFS» и «LFS». В некоторых из этих систем термин «FFS» используется для комбинации нижнего уровня FFS и верхнего уровня UFS, а термин «LFS» используется для комбинации нижнего уровня LFS и верхнего уровня UFS.
Кирк МакКусик реализовал перераспределение блоков, метод, который переупорядочивает блоки в файловой системе непосредственно перед выполнением записи, чтобы уменьшить фрагментацию и контролировать старение файловой системы. Он также реализовал мягкие обновления , механизм, который поддерживает согласованность файловой системы без ограничения производительности, как это делал традиционный режим синхронизации. Это имеет побочный эффект, заключающийся в снижении требований к проверке файловой системы после сбоя или сбоя питания. Чтобы решить оставшиеся проблемы после сбоя, была введена фоновая утилита fsck.
В UFS2 Кирк МакКусик и Пол-Хеннинг Камп расширили уровни FreeBSD FFS и UFS, добавив 64-битные указатели блоков (позволяющие увеличивать объемы до 8 зебибайт ), блоки переменного размера (аналогичные экстентам ), расширенные поля флагов, дополнительные Штампы «время рождения», поддержка расширенных атрибутов и ACL POSIX1.e. UFS2 стала версией UFS по умолчанию, начиная с FreeBSD 5.0. FreeBSD также представила программные обновления и возможность делать снимки файловой системы как для UFS1, так и для UFS2. С тех пор они были перенесены в NetBSD, но в конечном итоге мягкие обновления (называемые мягкими зависимостями в NetBSD) были удалены из NetBSD 6.0 в пользу менее сложного механизма журналирования файловой системы под названием WAPBL.(также называется журналированием), который был добавлен в FFS в NetBSD 5.0. OpenBSD поддерживает программные обновления с версии 2.9 [4] и поддерживает UFS2 (FFS2) (без ACL) с версии 4.2. [5] OpenBSD теперь сделал UFS2 версией UFS по умолчанию и будет включен в выпуск 6.7. [6] Начиная с FreeBSD 7.0, UFS также поддерживает ведение журнала файловой системы с помощью поставщика gjournal GEOM . FreeBSD 9.0 добавляет поддержку облегченного журналирования поверх мягких обновлений (SU + J), что значительно снижает потребность в фоновых fsck и списках ACL NFSv4.
FreeBSD, NetBSD, OpenBSD и DragonFly BSD также включают систему Dirhash , разработанную Яном Доузом. Эта система поддерживает хеш-таблицу в памяти для ускорения поиска в каталогах. Dirhash устраняет ряд проблем с производительностью, связанных с большими каталогами в UFS.
Linux включает реализацию UFS для двоичной совместимости на уровне чтения с другими Unix, но поскольку нет стандартной реализации для расширений поставщика для UFS, Linux не имеет полной поддержки записи в UFS. Собственная файловая система Linux ext2 была вдохновлена UFS1, но не поддерживает фрагменты, и нет планов по внедрению мягких обновлений. [ необходима цитата ] (В некоторых системах, основанных на 4.4BSD, уровень UFS может использовать слой ext2 в качестве уровня контейнера, так же как он может использовать FFS и LFS.)
NeXTStep , созданный на основе BSD, также использовал версию UFS. В компании Apple «s Mac OS X , она была доступна в качестве альтернативы HFS + , их собственной файловой системы. Однако, начиная с Mac OS X Leopard , больше нельзя было установить Mac OS X на том, отформатированный в UFS. Кроме того, нельзя обновить старые версии Mac OS X, установленные на томах в формате UFS, до Leopard; обновление требует переформатирования загрузочного тома. [7] Для дисков, отформатированных как UFS в Mac OS X, было ограничение в 4 ГБ. В Mac OS X Lion поддержка UFS была полностью прекращена. [8]
Хотя это старая файловая система основные элементы используются и современных UNIX системах.
Имена файлов ограничены 14 символами ASCII, кроме косой черты "/" и NUL - отсутствие символа. (в последующих версиях расширены до 255)
Контроль доступа к файлам и каталогам.
Имена чувствительны к регистру, my.txt и MY.TXT это разные файлы.
Используется схема i-узлов.
Не делается различий между разными файлами (текстовыми, двоичными и д.р.).
Поддерживаются символьные специальные файлы (для символьных устройств ввода-вывода).
- Если открыть файл /dev/lp и записать в него данные, то данные будут распечатаны на принтере.
- Если открыть файл /dev/tty и прочитать из него данные, то получим данные, введенные с клавиатуры.Поддерживаются блочные специальные файлы (для блочных устройств ввода-вывода, например /dev/hd1).
Позволяет монтировать разделы в любое место дерева системы.
Расположение файловой системы UNIX
Количество дисковых блоков
Начало списка свободных блоков диска
При уничтожении суперблока, файловая система становится не читаемой.
Каждый i-узел имеет 64 байта в длину и описывает один файл (в том числе каталог).
Каталог содержит по одной записи для каждого файла.
Каталоговая запись UNIX V7 в 16 байт
Первые 10 дисковых блоков файла хранятся в самом i-узле, при блоке в 1Кбайт, файл может быть 10Кбайт.
Дополнительные блоки для i-узла, в случае больших файлов:
Одинарный косвенный блок - дополнительный блок с адресами блоков файла, если файл не сильно большой, то один из адресов в i-узле указывает на дополнительный блок с адресами. Файл может быть 266Кбайт=10Кбайт+256Кбайт (256Кбайт <= 256 (2^8)-адресов блоков = 1Кбайт-размер блока / 4байта-размер адреса)
Двойной косвенный блок - дополнительный блок с адресами одинарных косвенных блоков, если одного дополнительного блока не хватает. Файл может быть 65Мбайт=10Кбайт+2^8Кбайт+2^16Кбайт.
Тройной косвенный блок - дополнительный блок с адресами двойных косвенных блоков, если одного одинарного косвенного блока не хватает. Файл может быть 16Гбайт=10Кбайт+2^8Кбайт+2^16Кбайт+2^24Кбайт.
3.1.1 Поиск файла
Этапы поиска файла по абсолютному пути /usr/sbin/mc
При использовании относительного пути, например sbin/mc, поиск начинается с рабочего каталога /usr.
3.1.2 Блокировка данных файла
Блокирование осуществляется по блочно.
Стандартом POSIX два типа блокировки:
Блокировка с монополизацией - больше ни один процесс эти блоки заблокировать не может.
Блокировка без монополизации - могут блокировать и другие процессы.
Блокировки данных файла без монополизации
Если процесс К попытается блокировать блок 6 с монополизацией, то сам процесс будет заблокирован до разблокирования блока 6 всеми процессами.
3.1.3 Создание и работа с файлом
fd=creat("abc", mode) - Пример создания файла abc с режимом защиты, указанном в переменной mode (какие пользователи имеют доступ). Используется системный вызов creat.
Успешный вызов возвращает целое число fd - дескриптор файла.
Который хранится в таблице дескрипторов файла, открывшего процесса.
После этого можно работать с файлом, используя системные вызовы write и read.
n=read(fd, buffer, nbytes)
n=write(fd, buffer, nbytes)
У обоих вызовов всего по три параметра:
fd - дескриптор файла, указывающий на открытый файл
buffer - адрес буфера, куда писать или откуда читать данные
nbytes - счетчик байтов, сколько прочитать или записать байт
Теперь нужно по дескриптору получить указатель на i-узел и указатель на позицию в файле для записи или чтения.
Таблица открытых файлов - создана для хранения указателей на i-узел и на позицию в файле. И позволяет родительскому и дочернему процессам совместно использовать один указатель в файле, но для посторонних процессов выделять отдельные указатели.
Связь между таблицей дескрипторов файлов, таблицей открытых файлов и таблицей i-узлов.
3.2 Файловая система BSD
Основу составляет классическая файловая система UNIX.
Особенности (отличие от предыдущей системы):
Увеличена длина имени файла до 255 символов
Было добавлено кэширование имен файлов, для увеличения производительности.
Применено разбиение диска на группы цилиндров, чтобы i-узлы и блоки данных были поближе друг к другу, для каждой группы были свои:
- суперблок
- i-узлы
- блоки данных.
Это сделано для уменьшения перемещений галовок.Используются блоки двух размеров, для больших файлов использовались большие блоки, для маленьких маленькие.
Каталоговые записи ни как не отсортированы и следуют друг за другом.
Каталог BSD с тремя каталоговыми записями для трех файлов и тот же каталог после удаления файла zip, увеличивается длина первой записи.
3.3 Файловые системы LINUX
Изначально использовалась файловая система MINIX с ограничениями: 14 символов для имени файла и размер файла 64 Мбайта.
После была создана файловая система EXT с расширением: 255 символов для имени файла и размер файла 2Гбайта.
Система была достаточно медленной.
3.3.1 Файловая система EXT2
Эта файловая система стала основой для LINUX, она очень похожа BSD систему.
Вместо групп цилиндров используются группы блоков.
Размещение файловой системы EXT2 на диске
Размер блока 1 Кбайт
Размер каждого i-узла 128 байт.
i-узел содержит 12 прямых и 3 косвенных адресов, длина адреса в i-узле стала 4 байта, что обеспечивает поддержку размера файла чуть более 16Гбайт.
Особенности работы файловой системы:
Создание новых каталогов распределяется равномерно по группам блоков, чтобы в каждой группе было одинаковое количество каталогов.
Новые файлы старается создавать в группе, где и находится каталог.
При увеличении файла система старается новые блоки записывать ближе к старым.
Благодаря этому файловую систему не нужно дефрагментировать, она не способствует фрагментации файлов (в отличии от NTFS), что проверено многолетним использованием.
3.3.2 Файловая система EXT3
В отличие от EXT2, EXT3 является журналируемой файловой системой, т.е. не попадет в противоречивое состояние после сбоев. Но она полностью совместима с EXT2.
Разработанная в Red Hat
В данный момент является основной для LINUX.
Драйвер Ext3 хранит полные точные копии модифицируемых блоков (1КБ, 2КБ или 4КБ) в памяти до завершения операции. Это может показаться расточительным. Полные блоки содержат не только изменившиеся данные, но и не модифицированные.
Такой подход называется "физическим журналированием", что отражает использование "физических блоков" как основную единицу ведения журнала. Подход, когда хранятся только изменяемые байты, а не целые блоки, называется "логическим журналированием" (используется XFS). Поскольку ext3 использует "физическое журналирование", журнал в ext3 имеет размер больший, чем в XFS. За счет использования в ext3 полных блоков, как драйвером, так и подсистемой журналирования нет сложностей, которые возникают при "логическом журналировании".
Типы журналирования поддерживаемые Ext3, которые могут быть активированы из файла /etc/fstab:
data=journal (full data journaling mode) - все новые данные сначала пишутся в журнал и только после этого переносятся на свое постоянное место. В случае аварийного отказа журнал можно повторно перечитать, приведя данные и метаданные в непротиворечивое состояние.
Самый медленный, но самый надежный.data=ordered - записываются изменения только мета-данных файловой системы, но логически metadata и data блоки группируются в единый модуль, называемый transaction. Перед записью новых метаданных на диск, связанные data блоки записываются первыми. Этот режим журналирования ext3 установлен по умолчанию.
При добавлении данных в конец файла режим data=ordered гарантированно обеспечивает целостность (как при full data journaling mode). Однако если данные в файл пишутся поверх существующих, то есть вероятность перемешивания "оригинальных" блоков с модифицированными. Это результат того, что data=ordered не отслеживает записи, при которых новый блок ложится поверх существующего и не вызывает модификации метаданных.data=writeback (metadata only) - записываются только изменения мета-данных файловой системы. Самый быстрый метод журналирования. С подобным видом журналирования вы имеете дело в файловых системах XFS, JFS и ReiserFS.
3.3.3 Файловая система XFS
XFS - журналируемая файловая система разработанная Silicon Graphics, но сейчас выпущенная открытым кодом (open source).
XFS была создана в начале 90ых (1992-1993) фирмой Silicon Grapgics (сейчас SGI) для мультимедийных компьютеров с ОС Irix. Файловая система была ориентирована на очень большие файлы и файловые системы. Особенностью этой файловой системы является устройство журнала - в журнал пишется часть метаданных самой файловой системы таким образом, что весь процесс восстановления сводится к копированию этих данных из журнала в файловую систему. Размер журнала задается при создании системы, он должен быть не меньше 32 мегабайт; а больше и не надо - такое количество незакрытых транзакций тяжело получить.
Более эффективно работает с большими файлами.
Имеет возможность выноса журнала на другой диск, для повышения производительности.
Сохраняет данные кэша только при переполнении памяти, а не периодически как остальные.
В журнал записываются только мета-данные.
Используются B+ trees.
Используется логическое журналирование
3.3.4 Файловая система RFS
RFS (RaiserFS) - журналируемая файловая система разработанная Namesys.
Официальная информация на RaiserFS
Более эффективно работает с большим количеством мелких файлов, в плане производительности и эффективности использования дискового пространства.
Использует специально оптимизированные b* balanced tree (усовершенствованная версия B+ дерева)
Динамически ассигнует i-узлы вместо их статического набора, образующегося при создании "традиционной" файловой системы.
Динамические размеры блоков.
3.3.4 Файловая система JFS
JFS (Journaled File System) - журналируемая файловая система разработанная IBM для ОС AIX, но сейчас выпущенная как открытый код.
Журналы JFS соответствуют классической модели транзакций, принятой в базах данных
В журнал записываются только мета-данные
Размер журнала не больше 32 мегабайт.
Асинхронный режим записи в журнал - производится в моменты уменьшения трафика ввода/вывода
![]()
Файловая система Unix - это метод, в котором организация и хранение больших объемов данных хранятся и ими легче управлять. Файл представляет собой набор связанных данных, которые логически рассматриваются как поток байтов. У этого есть атрибуты, у которых есть информация, связанная с этим файлом. Атрибуты файла могут относиться к типу файла, имени файла, физическому размеру файла, владельцу файла, защите файла, метке времени файла и т. Д. Этот атрибут дает подробную информацию об используемом файле. Когда файлы используются, они будут манипулировать и, следовательно, потребуются инструменты. Следовательно, эта файловая система в основном состоит из некоторых файлов и каталогов. В файловой системе Unix используется иерархия. Каталоги можно сказать как специальные файлы, которые, в свою очередь, могут содержать больше файлов. Каталог высшего уровня, присутствующий в этой структуре, будет корневым каталогом, который обозначается как «/». В этом каталоге может быть много подкаталогов.
Файловая система Unix обычно имеет следующие каталоги, присутствующие в файловой системе.
- bin: это краткая форма для двоичных файлов. В этом каталоге хранятся часто используемые исполняемые команды.
- mnt: содержит информацию о подключенных устройствах.
- root: это домашний каталог пользователя root.
- TMP: это хранилище для временных файлов. Поскольку они являются временными, они периодически удаляются из файловой системы.
- usr: содержит набор исполняемых команд
- home: у него есть коллекция каталогов и файлов.
- proc: содержит файлы, связанные с системными процессами.
Что такое Unix?
Unix - это операционная система, которая применяется к семейству многозадачных многопользовательских компьютерных операционных систем. Он был основан на операционной системе AT & T UNIX и был разработан в 1970-х годах в исследовательском центре Bell Labs. Сначала он был запрограммирован на ассемблере и снова перепрограммирован на C. Он стабилен и также предоставляет графический интерфейс пользователя, который помогает в создании удобной среды. Unix предоставляет пользователям различные инструменты разработки программ, средства электронной связи, а также множество инструментов разработки. С их помощью он также предоставляет несколько оболочек UNIX, где один интерпретирует ваши команды, а те передаются операционной системе. У этого также есть ядро, которое действует как посредник между оболочкой и оборудованием. Ядра относительно небольшие и эффективные. Unix также предоставляет отдельную файловую систему, в которой можно выполнять множество функций. Давайте посмотрим на файловую систему.
Типы файловой системы Unix
Файловая система Unix состоит из файлов разных типов. Давайте посмотрим на это.
1. Обычные файлы
Эти файлы используются для хранения информации пользователей. Это может быть какой-то текст или любое изображение, которое сохраняется. Обычно он находится в каталоге и не содержит никаких других файлов.
2. Справочники
Каталоги помогают в организации файлов, которые присутствуют. Каталоги могут содержать обычные файлы, специальные файлы или даже другие каталоги. Все эти каталоги являются потомками корневого каталога.
3. Специальные файлы
Специальные файлы используются для представления физических устройств, таких как принтер, драйвер ленты или терминал. Unix считает любое устройство файлом. Даже терминал считается файлом. Он считается стандартным входным файлом, из которого читается ввод. Этот терминал также является стандартным выходным файлом, который является выходом команды.
4. Трубы
Для связывания команд Unix предусмотрены каналы. Труба - это временный файл. Это также содержит данные одной команды, которые сохраняются до тех пор, пока они не будут прочитаны другой командой. Вывод одной команды передается следующей команде в качестве ввода.
Файловый дескриптор и индекс
Существует четкое разделение между содержимым файла и информацией, которая присутствует в файле. Все файлы состоят из последовательности символов, за исключением устройства и специальных файлов. Информация, которая необходима файловой системе для обработки файлов, включена в структуру данных, которая называется inode. Индод используется для идентификации файла. Для обработки функций ядра и файловой системы необходимо предоставить несколько атрибутов. Чтобы назвать несколько атрибутов, это тип файла, идентификатор устройства, идентификатор пользователя владельца файла, права доступа и режим файла и т. Д.
Дополнительные атрибуты файла в файловой системе Unix
Файл может иметь некоторые дополнительные атрибуты, как показано ниже.
- Режимы разрешений: он сообщает разрешения, которые назначены для файла для владельца.
- Владелец: это владелец файла.
- Группа: указывает группы, связанные с этим файлом.
- Имя файла : это имя, связанное с файлом.
- Дата изменения: это была дата последнего изменения файла.
- Размер : указывается размер файла в байтах.
- Количество ссылок: файлы, которые относятся к конкретному файлу.
Команды файлов и каталогов в файловой системе Unix
UNIX предоставляет множество команд, помогающих работать с файлами. Некоторые из этих команд перечислены ниже.
1. ls: в нем перечислены все файлы в определенном каталоге.
У этого есть несколько изменений ниже.
- ls dir: показывает содержимое, присутствующее в каталоге.
- ls a: показывает все файлы, включая скрытые.
- ls -al: выдает подробный список всего содержимого файла.
2. Меньше: отображает меньшее количество строк, чем весь файл.
3. Заголовок: отображает первые несколько строк или n строк файла.
4. Хвост: отображает последние несколько строк или n строк файла.
5. Cat: отображает содержимое всего файла без нумерации страниц.
6. cp: копирует содержимое одного файла в другой. Он перезаписывает содержимое файла, если не указано иное.
7. mv: перемещает указанные файлы в указанное место назначения.
8. rm: удаляет или удаляет указанные файлы.
Вывод
Unix - это операционная система, которая обрабатывает файлы организованно. Со всеми командами и функциями управлять файлами очень легко. Он также имеет разрешения, ограничивающие доступ к файлам. Только авторизованные люди могут получить доступ к файлам и выполнять различные операции. Он также имеет различные виды отдельных файлов, что облегчает его использование. Следовательно, файловая система Unix считается одной из самых удобных для пользователя файловых систем.
Рекомендуемая статья
Это было руководство по файловой системе Unix. Здесь мы обсуждаем его атрибуты файла, а также дескриптор файла и Inode. Вы также можете просмотреть наши другие предлагаемые статьи, чтобы узнать больше -
В материалах нескольких предыдущих семинаров (семинары 1–2, семинар 5) уже затрагивались вопросы работы с файлами в UNIX . Но только теперь, пояснив в лекции понятие файловой системы, мы можем рассмотреть файловую систему UNIX в целом. Наш обзор, правда, ограничится общими вопросами, связанными с организацией файловой системы, и системными вызовами, которые с наибольшей вероятностью могут пригодиться в дальнейшем. Это связано как с ограниченностью времени, которое отводится на работу с файловыми системами в нашем курсе, так и с преимущественно практическим направлением наших занятий.
Разделы носителя информации (partitions) в UNIX
Физические носители информации – магнитные или оптические диски, ленты и т.д., использующиеся как физическая основа для хранения файлов, в операционных системах принято логически делить на разделы (partitions) или логические диски . Причем слово "делить" не следует понимать буквально, в некоторых системах несколько физических дисков могут быть объединены в один раздел . Об этом подробнее рассказывается в лекции 12 в разделе "Общая структура файловой системы".
В операционной системе UNIX физический носитель информации обычно представляет собой один или несколько разделов . В большинстве случаев разбиение на разделы производится линейно, хотя некоторые варианты UNIX могут допускать некое подобие древовидного разбиения (Solaris). Количество разделов и их размеры определяются при форматировании диска. Поскольку форматирование диска относится к области администрирования операционных систем, оно в нашем курсе рассматриваться не будет.
Наличие нескольких разделов на диске может определяться требованиями операционной системы или пожеланиями пользователя. Допустим, пользователь хочет разместить на одном жестком диске несколько операционных систем с возможностью попеременной работы в них, тогда он размещает каждую операционную систему в своем разделе . Или другая ситуация: необходимость работы с несколькими видами файловых систем. Под каждый тип файловой системы выделяется отдельный логический диск . Третий вариант – это разбиение диска на разделы для размещения в разных разделах различных категорий файлов. Скажем, в одном разделе помещаются все системные файлы, а в другом разделе – все пользовательские файлы. Примером операционной системы, внутренние требования которой приводят к появлению нескольких разделов на диске, могут служить ранние версии MS-DOS , для которых максимальный размер логического диска не превышал 32 Мбайт.
Для простоты далее в этих семинарах будем полагать, что у нас имеется только один раздел и, следовательно, одна файловая система . Вопросы взаимного сосуществования нескольких файловых систем в рамках одной операционной системы мы затронем в семинарах 13–14 перед обсуждением реализации подсистемы ввода-вывода.
Логическая структура файловой системы и типы файлов в UNIX
Мы не будем давать здесь определение файла, полагая, что интуитивное представление о файлах у вас имеется, а в лекции 11 (раздел "Введение") было введено понятие о файлах, как об именованных абстрактных объектах, обладающих определенными свойствами. При этом в пространстве имен файлов одному файлу могут соответствовать несколько имен.
В материалах семинаров 1-2 упрощенно говорилось о том, что файлы могут объединяться в директории , и что файлы и директории организованы в древовидную структуру. На нынешнем уровне знаний мы можем сформулировать это более аккуратно. В операционной системе UNIX существуют файлы нескольких типов, а именно:
- обычные или регулярные файлы ;
- директории или каталоги;
- файлы типа FIFO или именованные pip 'ы;
- специальные файлы устройств ;
- сокеты (sockets);
- специальные файлы связи (link).
Что такое регулярные файлы и директории , вам должно быть хорошо известно из личного опыта и из лекций (лекция 11). О способах их отображения в дисковое пространство речь пойдет чуть позже. Файлы типа FIFO были представлены в семинаре 5, когда рассматривалась работа с именованными pip 'ами (раздел "Понятие FIFO . Использование системного вызова mknod() для создания FIFO . Функция mkfifo ()"). Файлы типа "связь" мы представим в этом семинаре, когда будем обсуждать операции над файлами (раздел " Операции над файлами и директориями ") и соответствующие им системные вызовы (раздел "Системные вызовы и команды для выполнения операций над файлами и директориями "). О специальных файлах устройств будет рассказано в материалах семинаров 13–14, посвященных реализации в UNIX подсистемы ввода-вывода и передаче информации с помощью сигналов. Файлы типа "сокет" будут введены в семинарах 15–16, когда мы будем рассматривать вопросы сетевого программирования в UNIX .
Файлы всех перечисленных типов логически объединены в ациклический граф с однонаправленными ребрами, получающийся из дерева в результате сращивания нескольких терминальных узлов дерева или нескольких его нетерминальных узлов таким образом, чтобы полученный граф не содержал циклов. В нетерминальных узлах такого ациклического графа (т.е. в узлах, из которых выходят ребра) могут располагаться только файлы типов " директория " и "связь" . Причем из узла, в котором располагается файл типа "связь" , может выходить только ровно одно ребро . В терминальных узлах этого ациклического графа (т.е. в узлах, из которых не выходит ребер) могут располагаться файлы любых типов (см. рис. 11–12.1), хотя присутствие в терминальном узле файла типа "связь" обычно говорит о некотором нарушении целостности файловой системы.
В отличие от древовидной структуры набора файлов, где имена файлов связывались с узлами дерева, в таком ациклическом графе имя файла связывается не с узлом, соответствующим файлу, а с входящим в него ребром. Ребра, выходящие из узлов, соответствующих файлам типа "связь" , являются неименованными. Надо отметить, что практически во всех существующих реализациях UNIX -подобных систем в узел графа , соответствующий файлу типа " директория ", не может входить более одного именованного ребра, хотя стандарт на операционную систему UNIX и не запрещает этого. Правила построения имен ребер (файлов) рассматривались в семинарах 1-2. В качестве полного имени файла может использоваться любое имя, получающееся при прохождении по ребрам от корневого узла графа (т.е. узла, в который не входит ни одно ребро ) до узла, соответствующего этому файлу, по любому пути с помощью следующего алгоритма:
- Если интересующему нас файлу соответствует корневой узел, то файл имеет имя " / ".
- Берем первое именованное ребро в пути и записываем его имя, которому предваряем символ " / ".
- Для каждого очередного именованного ребра в пути приписываем к уже получившейся строке справа символ " / " и имя соответствующего ребра.
Полное имя является уникальным для всей файловой системы и однозначно определяет соответствующий ему файл .
Читайте также:
