Сейчас на сайте
Сейчас на сайте 0 пользователей и 0 гостей.

UFS (Unix File System)

Так же, как Unix представляет не одну систему, а ряд совместимых, так же UFS - не одна система, а целый ряд. Информации о поддержке разными Unix'ами чужих UFS у меня пока нет; информацию по поводу поддержки чужих файловых систем для каждого конкретного Unix'а скорее всего можно найти в документации к программе ' mount '.

Основным отличием UFS от других известных мне систем является выделение атрибутов файла в отдельном объекте файловой системе - inode; это позволяет иметь доступ к файлу (к набору данных, хранящихся в файле) более чем по одному имени (так называемый жесткий линк; см.ниже), а заодно повысить эффективность функционирования системы.

Классическая UFS Отводит на файл 16 байт - 14-буквенное имя файла и двухбайтный номер inode; современые UFS позволяют создавать длинные имена (до 255 символов), а имена файлов хранят не подряд, а более разумно - в двоичном дереве или hash-таблице, а номер inode может быть любым - четырехбайтным или восьмибайтным.

Сам блок inode содержит:

  • количество ссылок на файл - каждое имя, ссылающееся на файл, а также открытие файла увеличивают этот счетчик на единицу; файл стирается с высвобождением занятого места как только счетчик становится равным нулю (т.е. можно стереть открытый файл, а реально он сотрется когда его закроют);
  • размер файла;
  • дату и время создания, последнего изменения и последего чтения файла;
  • тип файла - в Unix это бывает:
  • обычный файл;
  • директория;
  • файл блочного устройства;
  • файл символьного (последовательного) устройства;
  • поименованный пайп (название происходит от символа " | ", называемого "pipe" - см.его значение в shell);
  • символьный линк (алиас);
  • обычный файл и директория встречаются во всех файловых системах; файлы устройств являются интерфейсами к драйверам этих устройств;
  • UID (идентификатор хозяина файла) и GID (идентификатор группы);
  • атрибуты доступа:
  • Unix использует атрибуты 'Read', 'Write' и 'eXecute' для хозяина файла (owner), для одногрупника (group) и для остальных (other) - итого 9 бит; для директории эти атрибуты означают соответственно права на чтение списка файлов, на создание/удаление файлов и на обращение к файлам внутри директории;
  • важной особенностью является то, что права доступа для хозяина определяются атрибутами для него, права для одногрупника и остальных для хозяина игнорируются; аналогично для одногркпника не играют никакой роли права для остальных;
  • кроме них есть атрибуты SetUID и SetGID - для запускаемого файла (не интерпретируемого) эти атрибуты определяют запуск процесса под правами не запустившего их пользователя, а хозяина и/или группы файла соотвнтственно;
  • и еще есть один атрибут - для директории он запрещает стирание файлов, не принадлежащих стирающему;
  • •  расширенный ACL (Access Control List, Список Управления Доступом) или ссылку на ACL, если файловая система поддерживает ACL;
  • несколько (в классической UFS - 13) ссылок на кластеры файловой системы (раскладка приведена для классической UFS):
  • первые 10 указывают на первые 10 кластеров файла;
  • 11-й указывает на кластер, содержащий адреса следующих 128-ми кластеров файла (в классической UFS размер кластера - полкилобайта, а адрес кластера - четыре байта);
  • 12-й указывает на кластер, содержащий адреса 128-ми кластеров, в свою очередь содержащих адреса следующих 16`384-рех кластеров файла;
  • последний указывает на кластер, ... вобщем, здесь используется еще на один уровень больше, что позволяет адресовать еще 2`097`152 кластера файла;

итого получается 2`113`674 кластера по полкилобайта - чуть более гигабайта в файловой системе, способной работать с томами до двух терабайт (2 ^32 кластеров по полкилобайта).

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

 

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

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