Главная страница  Межпроцессное взаимодействие (состязание) 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 [ 164 ] 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187

ния файловой системы имеется утилита mkfs. Она может быть вызвана, например, так:

mkfs /dev/fdO 1440

Такая команда создаст файловую систему из 1440 блоков на гибком диске в приводе 1. Ей можно указать файл-прототип с перечислением каталогов и файлов, подлежащих включению в созданную файловую систему. Эта же команда записывает в суперблок необходимую сигнатуру, идентифицирующую файловую систему как файловую систему MINIX. Эта сигнатура идентифицирует версию программы mkfs, при помощи которой создана файловая система, что позволяет в дальнейшем учесть различия между версиями. MINIX развивается, и в ранних версиях некоторые аспекты файловой системы (например, размер г-узла) были другими. При попытке монтировать дискету, имеющую другой формат, например дискету MS-DOS, системный вызов mount, проверяющий суперблок иа наличие сигнатуры, сообщит об ошибке.

5.6.3. Битовые карты

MINIX следит за свободными и занятыми г-узлами и зонами при помощи двух битовых карт (см. рис. 5.25). Когда удаляется файл, несложно подсчитать, какой бит в битовой карте соответствует освободившемуся г-узлу, и найти его при помощи обычного механизма кэширования. В найденном блоке бит, соответствующий освободившемуся г-узлу, сбрасывается в 0. Зоны освобождаются точно так же, только используется битовая карта зон.

Логически, при создании файла файловая система должна последовательно просмотреть битовые карты, чтобы найти первый свободный г-узел. Фактически же, хранящийся в памяти суперблок содержит поле, указывающее на следующий свободный г-узел, поэтому потребуется искать свободный г-узел, начиная с этого положения (зачастую свободным оказывается следующий узел). Аналогичным образом, когда г-узел освобождается, проверяется, есть ли перед ним другие свободные, и при необходимости обновляется значение указателя. Если оказалось, что все г-узлы на диске заняты, процедура поиска указывает на 0-й элемент. Именно поэтому 0-й г-узел не используется (другими словами, он является индикатором заполнения диска). (Когда программа mkfs создает новую файловую систему, она обнуляет г-узел О и устанавливает младший бит в битовой карте, соответственно, файловая система никогда не пытается выделить этот блок.) Все, что только что было сказано для г-узлов, относится и к зонам. Когда необходимо дисковое пространство, логически ищется первая свободная зона, начиная с начала, а чтобы избежать ненужного последовательного поиска, поддерживается указатель на первую свободную зону.

Теперь мы можем объяснить разницу между зонами и блоками. В основе идеи зон лежит надежда гарантировать, что блоки одного файла расположены на одном цилиндре, с целью увеличения производительности последовательного чтения. Для этого используется подход, когда за один раз выделяется несколько блоков. Если, например, размер блока равен 1 Кбайт, а зоны - 4 Кбайт, битовая



карта зон отслеживает зоны, а не блоки. Диск объемом 20 Мбайт будет разбит на 5 К зон по 4 Кбайт, и в битовой карте зон, таким образом, будет 5 Кбит.

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

В процессе разработки файловой системы MINIX необходимо было принять некоторые решения о ее дизайне. В 1985 году, когда была задумана MINIX, диски имели небольшой объем, и ожидалось, что у многих пользователей будет только дисковод. Поэтому было решено в файловой системе VI ограничить дисковый адрес 16 битами, чтобы впоследствии хранить большую их часть в блоках косвенной адресации. При 16-битном номере зоны и размере зоны в 1 Кбайт такая система позволяла работать с дисками объемом до 64 Мбайт. В те дни это был огромный объем, и казалось, что если диски станут больше, будет несложно переключиться на зоны размером 2 Кбайт или 4 Кбайт, не меняя размер блока. Благодаря 16-битному номеру зоны размер г-узла был ограничен 32 байтами.

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

В конце концов, было принято решение увеличить разрядность дискового указателя до 32 бит. Благодаря этому файловая система MINIX V2 могла бы работать с дисками объемом до 4 Тбайт, сохраняя размеры зоны и блока равным 1 Кбайт. Частично к этому выводу подталкивали и другие решения, касающиеся того, что должно храниться в г-узле. В результате стало разумным увеличение г-узла до 64 байт.

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

Предположим, что кто-то установил файловый указатель на 32 768 и дописал 1 байт. Теперь размер файла станет равным 32 769. Если после этого установить файловый указатель на 1 К и прочитать данные, удастся получить данные, которые были в данном блоке ранее, что является серьезной угрозой безопасности.



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

5.6.4. 1-узлы

Схема г-узла MINIX показана на рис. 5.26. Она практически совпадает со строением г-узла в UNIX. Имеются девять 32-битных указателей на зоны диска, из которых семь прямых и два косвенных. В MINIX г-узел занимает 64 байта, как и в стандартной UNIX, поэтому остается место для дополнительного, десятого указателя, хотя в текущей версии файловой системы он не поддерживается. Время последнего доступа, модификации и изменения г-узла в MINIX хранятся стандартным образом, как в UNIX. Последний из этих параметров обновляется практически при каждой операции, за исключением чтения файла.

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

Главное предназначение г-узла в том, чтобы хранить сведения о положении блоков файла на диске. Первые семь номеров зон записываются в г-узел напрямую. Таким образом, при стандартных параметрах, когда зоны и блоки имеют размер 1 Кбайт, файлы размером до 7 Кбайт не требуют использования блоков косвенной адресации. После 7 Кбайт применяются косвенные блоки, подобно тому, как это показано на рис. 5.26, за тем исключением, что это только блоки первого и второго уровней косвенности. Если блоки и зоны имеют размер 1 Кбайт, косвенный блок первого уровня содержит 256 записей, что соответствует четверти мегабайта. Косвенный блок второго уровня ссылается на 256 блоков первого уровня, обеспечивая доступ к области в 64 Мбайт. Максимальный объем файловой системы MINIX составляет 1 Гбайт, и если потребуется реализовать работу с очень большими файлами, можно будет задействовать блоки третьего уровня косвенности, а также увеличить размер зоны.

Кроме того, г-узел хранит информацию о типе файла (обычный файл, каталог, специальный блочный файл, специальный символьный файл, канал ввода/ вывода) и биты защиты, а также биты SETUID и SETGID. В поле link фиксируется, сколько разных каталогов ссылаются на данный файл, чтобы файловая система могла знать, когда следует освободить занимаемое им место. Не путайте этот счетчик со счетчиком количества открытий файла, обычно разными процессами (этот счетчик есть только в памяти в таблице inode).



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 [ 164 ] 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187

© 2000 - 2024 ULTRASONEX-AMFODENT.RU.
Копирование материалов разрешено исключительно при условии цититирования.