Служба рассылок Subscribe.Ru проекта Citycat.Ru
-*--------------------------------------------------------------------------
                    Здравствуйте, уважаемые подписчики. 
 
----------------------------------------------------------------------------


                   Выпуск No8
                                    
   В этом выпуске мы с вами поговорим про файловые системы.
   Файловая система - это немаловажный момент в операционной системе,
   они бывают разные, различаются по производительности, надежности,
   по-разному экономно используют пространство.
   
   Есть много файловых систем, которые нам, в принципе, подойдут
   (EXT2FS, FFS, NTFS, RaiserFS и много других), есть так же файловые
   системы, которые нам вообще не подойдут (FAT). В процессе развития
   нашей операционной системы мы создадим поддержку и для них, но для
   начала надо остановиться на чем-то одном. Этой одной файловой
   системой будет EXT2FS.
   
   В этом выпуске я достаточно подробно рассмотрю файловые системы
   FAT, и более подробно файловую систему Linux (ext2). Поскольку
   наша операционная система будет юниксоподобная, то файловые
   системы FAT нам никак не подходят, поскольку они не обеспечивают
   мер ограничения доступа, и по сути своей не являются
   многопользовательскими. Про остальные файловые системы я
   ограничусь лишь основными моментами.
   
   Так же я не стану затрагивать тему разделов диска. Обсудим это в
   другой раз.
   
  Основные принципы файловых систем.
  
   Все устройства блочного доступа (к которым относятся жесткие или
   гибкие диски, компакт диски) при чтении/записи информации
   оперируют секторами. Для жестких или гибких дисков размер сектора
   равен 512 байт, в компакт-дисках размер сектора равен 2048 байт.
   Сектора являются физической единицей информации для носителя.
   
   Для файловых систем такое распределение часто бывает не очень
   удобно, и в них вводится понятие кластера. Кластеры часто бывают
   больше по размеру, чем сектора носителя. Кластеры являются
   логической единицей файловых систем. Правда, не всегда они
   называются кластерами. В ext2 кластеры называются просто блоками,
   но это не столь важно. Для организации кластеров файловые системы
   хранят таблицы кластеров. Таблицы кластеров, естественно,
   расходуют дисковое пространство. Помимо этого, дополнительное
   дисковое пространство расходуется под каталоги файлов. Эти
   неизбежные расходы в разных файловых системах имеют разную
   величину. Но об этом мы поговорим ниже.
   
  Файловые системы на базе FAT (File Allocation Table).
  
   Этот тип файловых систем разработала фирма Microsoft достаточно
   давно. Вместе с первыми DOS... С тех пор неоднократно натыкались
   на различные препятствия и дорабатывались в соответствии с
   требованиями времени.
   
   Теперь пойдет небольшой экскурс в историю. :)
     * В 1977 году Биллом Гейтсом и Марком МакДональдом была
       разработана первая файловая система FAT. Ради совместимости с
       CP/M в ней было ограничено имя файла. Максимальная длина имени
       составляла 8 символов, и 3 символа можно было использовать для
       расширения файла. Регистр букв не различался и не сохранялся.
       Размер кластера не превышал 4 килобайта. Размер диска не мог
       превышать 16 мегабайт.
     * В 1981 году вышла первая версия MSDOS, которая базировалась на
       FAT.
     * Начиная с MSDOS версии 3.0, в файловой системе появилось
       понятие каталога.
     * Для поддержки разделов более 16 мегабайт размер элемента FAT
       был увеличен до 16 бит, (первая версия была 12-битная) а
       максимальный размер кластера увеличен до 32 килобайт. Это
       позволило создавать разделы до 2 гигабайт.
     * В таком состоянии FAT просуществовал до появления VFAT,
       появившегося вместе с выходом Windows'95, в которой появилась
       поддержка длинных имен файлов. Теперь имя файлов могло иметь
       длину до 255 символов, но ради совместимости старый формат
       имен так же остался существовать.
     * Немного позже FAT был еще расширен, размер элемента FAT стал
       32 бита, при этом максимальный размер кластера вновь
       уменьшился до 4 килобайт, но это позволило создавать разделы
       до 2 терабайт. Кроме того, была расширена информация о файлах.
       Теперь она позволяли хранить помимо времени создания файла
       время модификации и время последнего обращения к файлу.
       
   Ну а теперь подробнее рассмотрим структуру этой файловой системы.
   
   Общий формат файловой системы на базе FAT таков:
     * Boot sector (в нем так же содержится "Блок параметров FS")
     * Reserved Sectors (могут отсутствовать)
     * FAT (Таблица размещения файлов)
     * FAT (вторая копия таблицы размещения файлов, может
       отсутствовать)
     * Root directory (корневая директория)
     * Область файлов. (Кластеры файловой системы)
       
   Boot sector имеет размер 512 байт, как мы уже знаем, может
   содержать в себе загрузчик системы, но помимо этого для FAT он
   содержит Блок параметров. Блок параметров размещается в boot
   sector'е по смещению 0x0b и содержит в себе следующую информацию:
   
struct FAT_Parameter_block {
  u_int16       Sector_Size;
  u_int8        Sectors_Per_Cluster;
  u_int16       Reserved_Sectors;
  u_int8        FAT_Count;
  u_int16       Root_Entries;
  u_int16       Total_Sectors;
  u_int8        Media_Descriptor;
  u_int16       Sectors_Per_FAT;
  u_int16       Sectors_Per_Track;
  u_int16       Heads;
  u_int32       Hidden_sectors;
  u_int32       Big_Total_Sectors;
};

   Размер кластера можно вычислить, умножив Sector_Size на
   Sectors_Per_Cluster.
   
   Общий размер диска определяется следующим образом: Если значение
   Total_Sectors равно 0, то раздел более 32 мегабайт и его длина в
   секторах храниться в Big_Total_Sectors. Иначе размер раздела
   показан в Total_Sectors.
   
   Таблица FAT начинается с сектора, номер которого храниться в
   Reserved_Sectors и имеет длину Sectors_Per_FAT; при 16-битном FAT
   размер таблицы может составлять до 132 килобайт (или 256 секторов)
   (в FAT12 до 12 килобайт).
   Вторая копия FAT служит для надежности системы... но может
   отсутствовать.
   
   После таблицы FAT следует корневая директория диска. Размер этой
   директории ограничен Root_Entries записями. Формат записи в
   директории таков:
   
struct FAT_Directory_entry {
  char          Name[8];
  char          Extension[3];
  u_int16       File_Attribute;
  char          Reserved[10];
  u_int16       Time;
  u_int16       Date;
  u_int16       Cluster_No;
  u_int32       Size;
};

   Размер записи - 32 байта, следовательно, общий размер корневой
   директории можно вычислить, умножив Root_Entries на 32.
   
   Далее на диске следуют кластеры файловой системы. Из записи в
   директории берется первый номер кластера, с него начинается файл.
   В FAT под этим номером может содержаться либо код последнего
   кластера (0xffff или 0xfff для FAT12) либо номер кластера,
   следующего за этим.
   
   При записи файла из FAT выбираются свободные кластеры по порядку
   от начала. В результате возникает фрагментация файловой системы, и
   существенно замедляется ее работа. Но это уже выходит за тему
   рассылки.
   
   Все выше сказанное про FAT справедливо для FAT12 и FAT16. FAT32
   более существенно отличается, но общие принципы организации для
   нее примерно такие же. VFAT ничем не отличается от FAT16, для
   хранения длинных имен там используется однеа запись в директории
   для хранения короткого имени файла и несколько записей для
   хранения длинного. Длинное имя храниться в unicode, и на запись в
   директории приходится 13 символов длинного имени, причем они
   разбросаны по некоторым полям записи, остальные поля заполняются с
   таким расчетом, чтобы старые программы не реагировали на такую
   запись.
   
   С первого взгляда видна не высокая производительность таких
   файловых систем. Не буду поливать грязью Microsoft, у них и без
   меня достаточно проблем... :) К тому же и у них есть другие
   разработки, которые не столь плохи. Но о них мы поговорим ниже...
   А сейчас давайте посмотрим на ext2fs. Правда, эта файловая система
   несколько другого уровня, и сравнивать ее с FAT - нельзя. Но обо
   всем по порядку.
   
  Ext2fs (Расширенная файловая система версия 2)
  
   Linux разрабатывался на операционной системе Minix. В ней была (да
   и есть) файловая система minixfs. Система не очень гибкая и
   достаточно ограниченная. После появления Linux была разработана
   (на базе minixfs) файловая система extfs, которую в скором времени
   заменила ext2fs, которая и используется в большинстве Linux, по
   сей день.
   
   Для начала давайте рассмотрим основное устройство этой файловой
   системы:
     * Boot sector (1 сектор)
     * Свободно (1 сектор, может быть использован для расширения Boot
       sector'а до килобайта)
     * Super block (2 сектора или 1024 байта длиной)
     * Group descriptors (2 сектора максимум)
     * Group 1
     * Group 2
     * ... и так далее... до Group 32 если необходимо.
       
   Если ext2fs находится на каком ни будь разделе жесткого диска, или
   является не загрузочной, то boot sector'а там может вообще не
   быть.
   
   Super block содержит в себе информацию о файловой системе и имеет
   следующий формат:
   
struct ext2_super_block {
  u_int32  s_inodes_count;
  u_int32  s_blocks_count;
  u_int32  s_r_blocks_count;
  u_int32  s_free_blocks_count;
  u_int32  s_free_inodes_count;
  u_int32  s_first_data_block;
  u_int32  s_log_block_size;
  int32    s_log_frag_size;
  u_int32  s_blocks_per_group;
  u_int32  s_frags_per_group;
  u_int32  s_inodes_per_group;
  u_int32  s_mtime;
  u_int32  s_wtime;
  u_int16  s_mnt_count;
  u_int16  s_max_mnt_count;
  u_int16  s_magic;
  u_int16  s_state;
  u_int16  s_errors;
  u_int16  s_pad;
  u_int32  s_lastcheck;
  u_int32  s_checkinterval;
  u_int32  s_reserved[238];
};

   Не буду описывать значение всех полей этой структуры, ограничусь
   основными. Размер блока файловой системы можно вычислить так: 1024
   * s_log_block_size. Размер блока может быть 1, 2 или 4 килобайта
   размером.
   
   Об остальных полях чуть попозже.
   А теперь рассмотрим группы дескрипторов файловой системы.
   Формат дескриптора группы таков:
   
struct ext2_group_desc {
  u_int32  bg_block_bitmap;
  u_int32  bg_inode_bitmap;
  u_int32  bg_inode_table;
  u_int16  bg_free_blocks_count;
  u_int16  bg_free_inodes_count;
  u_int16  bg_used_dirs_count;
  u_int16  bg_pad;
  u_int32  bg_reserved[3];
};

   Содержимое группы таково:
     * Block bitmap (Битовая карта занятости блоков)
     * Inode bitmap (Битовая карта занятости inode)
     * Inode table (Таблица inode)
     * Available blocks (блоки, доступные для размещения файлов)
       
   Блоки в файловой системе отсчитываются с начала раздела. В
   дескрипторе группы содержаться номер блока с битовой картой блоков
   группы, номер блока с битовой картой инодов, и номер блока с
   которого начинается таблица inode. Про inode мы поговорим чуть
   попозже, а сперва разберемся с битовыми картами.
   
   В суперблоке храниться количество блоков в группе
   (s_blocks_per_group). Битовая карта имеет соответствующий размер в
   битах (занимает она не более блока). и в зависимости от размера
   блока может содержать информацию об использовании 8, 32 или 132
   мегабайт максимум. Дисковое пространство раздела разбивается на
   группы в соответствии с этими значениями. А групп, как я уже
   упоминал, может быть до 32... что позволяет создавать разделы, в
   зависимости от размера блока, 256, 1024 или 4096 мегабайт
   соответственно.
   
   В битовую карту блоков группы входят так же те блоки, которые
   используются под саму карту, под карту inode и под таблицу inode.
   Они сразу помечаются как занятые.
   
   Теперь давайте разберемся, что такое inode. В отличии от FAT
   информация о файле здесь храниться не в директории, а в
   специальной структуре, которая носит название inode
   (информационный узел). В записи директории содержится только адрес
   inode и имя файла. При этом на один inode могут ссылаться
   несколько записей директории. Это называется hard link.
   
   Формат inode таков:
   
struct ext2_inode {
  u_int16  i_mode;
  u_int16  i_uid;
  u_int32  i_size;
  u_int32  i_atime;
  u_int32  i_ctime;
  u_int32  i_mtime;
  u_int32  i_dtime;
  u_int16  i_gid;
  u_int16  i_links_count;
  u_int32  i_blocks;
  u_int32  i_flags;
  u_int32  i_reserved1;
  u_int32  i_block[14];
  u_int32  i_version;
  u_int32  i_file_acl;
  u_int32  i_dir_acl;
  u_int32  i_faddr;
  u_int8   i_frag;
  u_int8   i_fsize;
  u_int16  i_pad1;
  u_int32  i_reserved2[2];
};

   Как видно из приведенной выше структуры в inode содержится
   следующая информация:
     * Тип и права доступа файла (i_mode)
     * идентификатор хозяина файла (i_uid)
     * Размер (i_size)
     * Время доступа, создания, модификации и удаления файла (после
       удаления inode не удаляется, а просто перестает занимать блоки
       файловой системы)
     * Идентификатор группы
     * Количество записей в директориях, указывающих на этот inode...
     * Количество занимаемых блоков fs
     * дополнительные флаги ext2fs
     * таблица занимаемых блоков
     * Ну и другая, не столь существенная в данных момент информация.
       
   Остановимся поподробнее на таблице занимаемых блоков. Как видите
   там всего 14 записей. Но 14 блоков - это мало для одного файла.
   Дело в том, что не все записи содержат номера блоков. 13-я запись
   содержит косвенный блок, то есть блок, в котором содержится
   таблица блоков. А 14-я запись содержит номер блока в котором
   содержится таблица номеров блоков, в которых содержаться таблицы
   блоков занимаемых файлом... так что размер файла практически ничто
   не ограничивает.
   
   Первые 10 inode зарезервированы для специфического использования.
   
   Для корневой директории в этой файловой системе не отводится
   заранее отведенного места. Любая, в том числе и корневая
   директория в этой файловой системе является по сути своей
   обыкновенным файлом. Но для облегчения поиска корневой директории
   для нее зарезервирован inode номер 2.
   
   В этой файловой системе в отличие от FAT существуют методы защиты
   файлов, которые обеспечиваются указанием идентификаторов
   пользователя и группы, а так же правами доступа, которые
   указываются в inode в поле i_mode.
   
   За счет нескольких групп блоков уменьшается перемещение головки
   носителя при обращении к файлам, что увеличивает скорость
   обращения и уменьшает износ носителя. Да и сама файловая система
   организована так, что для чтения файлов не требуется загрузка
   больших объемов служебной информации, Что тоже не может не
   сказаться на производительности.
   
   Примерно так же устроены файловые системы FFS, HPFS, NTFS. Но в их
   устройство я не буду вдаваться. И так уже выпуск очень большой
   получается. :)
   
   Но в недавнее время появился еще один тип файловых систем. Эти
   системы унаследовали некоторые черты от баз данных и получили
   общее название "Журналируемые файловые системы". Особенность их
   заключается в том что все действия, производимые в файловой
   системе фиксируются в журнале, который правда съедает некоторый
   объем диска, но это позволяет значительно повысит надежность
   систем. В случае сбоя проверяется состояние файловой системы и
   сверяется с записями в журнале. В случае обнаружения
   несоответствий довести операцию до конца не составляет проблем, и
   отпадает необходимость в ремонте файловой системы. К таким
   файловым системам относятся ext3fs, RaiserFS и еще некоторые.
   
   Но на этом я завершаю свой выпуск. Повторю только, что мы в первую
   очередь планируем ориентироваться на ext2fs, и возможно в
   следующем выпуске мы уже сможем рассмотреть программную работу с
   ext2fs. А я прощаюсь с вами до следующего выпуска, пишите. Мой
   адрес, как всегда, можно найти чуть ниже.
Отправлено 2001-08-24 для 4145 подписчиков. 
ведущий рассылки Dron - dron@infosec.ru 
Сайт проекта - http://spawnhole.narod.ru/asmos/asmos.html 
Архив Рассылки - http://subscribe.ru/archive/comp.soft.prog.asmos 
 
При поддержке http://www.Kalashnikoff.ru 
 
---------------------------------------------------------------------------

Подписка на рассылки Subscribe.Ru:

  Операционная система "с нуля" на Ассемблере и Cи
    http://subscribe.ru/catalog/comp.soft.prog.asmos

  Ассемблер? Это просто! Учимся программировать
    http://subscribe.ru/catalog/comp.prog.assembler

  Ассемблер? Это просто! Учимся программировать (FAQ)
    http://subscribe.ru/catalog/comp.soft.prog.faq
 
---------------------------------------------------------------------------

(C)Москва, 2001. Авторское право принадлежит Валяеву А.Ю. Публичное 
размещение материала из рассылки, а также его использование полностью или 
частично в коммерческих или иных подобных целях без письменного согласия 
автора влечет ответственность за нарушение авторских прав. 
 
-*--------------------------------------------------------------------------
Отписаться: http://subscribe.ru/member/unsub?grp=comp.soft.prog.asmos

http://subscribe.ru/                                mailto:ask@subscribe.ru