Файл: Debian Таненбаум Бос.pdf

ВУЗ: Не указан

Категория: Книга

Дисциплина: Операционные системы

Добавлен: 29.10.2018

Просмотров: 47989

Скачиваний: 190

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
background image

1036  

 Глава 11. Изучение конкретных примеров: Windows 8 

Рис. 11.25. Запись MFT для потока из трех участков и девяти блоков

Во-вторых, в то время как самый простой способ представления каждой пары требует 
2 · 8 байт, имеется также метод сжатия, который уменьшает размер пары меньше чем до 
16 байт. Многие дисковые адреса имеют нулевые старшие байты. Их можно опустить. 
Заголовок данных сообщает о том, сколько их было опущено (то есть сколько байтов 
реально используется на один адрес). Применяются и другие виды сжатия. На практике 
пара часто занимает только 4 байта.

Наш первый пример был простым: вся информация файла уместилась в одной записи 
MFT. Что произойдет, если файл настолько большой или так сильно фрагментирован, 
что информация о блоках не помещается в одну запись MFT? Ответ простой: исполь-
зуются две или более записи MFT. На рис. 11.26 мы видим файл, основная запись 
которого находится в записи 102 в MFT. Он имеет слишком много (для одной записи 
MFT) участков, поэтому вычисляется количество нужных записей расширения (на-
пример, две) и их индексы помещаются в основную запись. Остальная часть записи 
используется для первых k участков данных.

Рис. 11.26. Файл, которому требуется три записи MFT для хранения всех его участков

Обратите внимание на то, что на рис. 11.26 имеется некоторая избыточность. В теории 
не должно быть необходимости указывать конец последовательности участков, по-
скольку эту информацию можно вычислить по парам для участков. Цель избыточного 
указания этой информации в том, чтобы сделать поиск более эффективным: чтобы 


background image

11.8. Файловая система Windows NT   

1037

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

Когда все пространство записи 102 будет использовано, сохранение участков продол-
жится в записи 105 в MFT. В нее будет записано столько участков, сколько поместится. 
Когда эта запись также заполнится, остальные участки попадут в запись 108 в MFT. 
Таким образом можно использовать много записей MFT (для работы с большими 
фрагментированными файлами).

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

Элемент MFT для небольшого каталога показан на рис. 11.27. Запись содержит не-
которое количество элементов каталога, каждый из которых описывает один файл 
или каталог. Каждый элемент содержит структуру фиксированной длины, за которой 
следует имя файла (переменной длины). Фиксированная часть содержит индекс эле-
мента MFT для данного файла, длину имени файла, а также разнообразные прочие 
поля и флаги. Поиск элемента каталога состоит из опроса всех имен файлов по очереди. 
Большие каталоги используют другой формат. Вместо линейного перечисления файлов 
используется дерево В+ (чтобы сделать возможным алфавитный поиск и облегчить 
вставку новых имен в нужное место каталога).

Рис. 11.27. Запись MFT для небольшого каталога

В NTFS разбор маршрута 

\foo\bar

 начинается в корневом каталоге 

С:

, блоки которого 

можно определить из элемента 5 в MFT (см. рис. 11.24). Строка «

foo

» ищется в кор-

невом каталоге, который возвращает индекс в MFT для каталога 

foo

. В этом каталоге 

затем выполняется поиск строки «

bar

», которая ссылается на запись MFT для данного 

файла. NTFS выполняет проверки доступа (обращаясь к монитору безопасности) и, 
если все в порядке, ищет запись MFT для атрибута ::$DATA, который является потоком 
данных по умолчанию.

Обнаружив файл 

bar

, NTFS установит указатели на свои метаданные в объекте файла, 

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


background image

1038  

 Глава 11. Изучение конкретных примеров: Windows 8 

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

C:\foo\bar

 следует 

включать в запрос чтения, который передается вниз по стеку устройства 

С:

 в NTFS.

В дополнение к обычным файлам и каталогам NTFS поддерживает и жесткие ссылки 
(в UNIX-смысле), а также символические ссылки (с использованием механизма под 
названием точка повторной обработки — reparse points). NTFS поддерживает помет-
ку файла или каталога как точки повторной обработки и ассоциирование с ней блока 
данных. Когда такой файл или каталог встречается во время разбора имени файла, опе-
рация заканчивается неудачей и диспетчеру объектов возвращается этот блок данных. 
Диспетчер объектов может интерпретировать данные как представляющие альтерна-
тивный маршрут, после чего он обновляет строку для разбора и повторяет операцию 
ввода-вывода. Этот механизм используется для поддержки как символических ссылок, 
так и смонтированных файловых систем, выполняя перенаправление поиска в другую 
часть иерархии каталогов или даже в другой раздел диска.

Точки повторной обработки используются также для пометки отдельных файлов 
для драйверов-фильтров файловой системы. На рис. 11.11 мы показали, как фильтры 
файловой системы можно установить между диспетчером ввода-вывода и файловой 
системой. Запросы ввода-вывода завершаются при помощи вызова IoCompleteRequest
передающего управление процедурам завершения, которые каждый драйвер пред-
ставил в стеке устройств (вставленном в IRP во время запроса). Желающий пометить 
файл драйвер ассоциирует тег повторной обработки, а затем отслеживает закончив-
шиеся неудачно (потому что им встретилась точка повторной обработки) запросы на 
завершение операций открывания файлов. Из блока (передаваемых обратно с IRP) 
данных драйвер может определить, тот ли это блок данных, который сам драйвер ас-
социировал с файлом. Если это так, то драйвер останавливает обработку завершения 
и продолжает обработку исходного запроса ввода-вывода. Обычно при этом продолжа-
ется выполнение запроса на открытие, но имеется флаг, который дает указание NTFS 
игнорировать точку повторной обработки и открыть файл.

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

Сжатие работает следующим образом. Когда NTFS пишет файл (помеченный как сжа-
тый) на диск, то она изучает первые 16 (логических) блоков файла — независимо от 
того, сколько участков они занимают. Затем запускает по ним алгоритм сжатия. Если 
полученные данные можно записать в 15 или менее блоков, то сжатые данные записы-
ваются на диск (по возможности — одним участком). Если сжатые данные по-прежнему 
занимают 16 блоков, то эти 16 блоков записываются в несжатом виде. Затем исследуются 
блоки 16–31, чтобы узнать, можно ли их сжать до размера 15 блоков (или менее), и т. д.

На рис. 11.28, а показан файл, в котором первые 16 блоков успешно сжались до 8 бло-
ков, вторые 16 блоков не сжались, а третьи 16 блоков также сжались на 50 %. Эти три 
части были записаны как три участка и сохранены в записи MFT. «Отсутствующие» 
блоки хранятся в элементе MFT с дисковым адресом 0 (рис. 11.28, б). Здесь за заго-


background image

11.8. Файловая система Windows NT   

1039

ловком (0, 48) следует пять пар: две для первого (сжатого) участка, одна для несжатого 
участка и две для последнего (сжатого) участка.

Рис. 11.28. а — пример сжатия файла из 48 блоков до размера в 32 блока; 

б — запись MFT для файла после сжатия

Когда файл считывается обратно, NTFS должна знать, какие участки сжаты, а какие — 
нет. Она может определить это по дисковым адресам. Дисковый адрес 0 указывает 
на то, что это последняя часть 16 сжатых блоков. Дисковый блок 0 не может исполь-
зоваться для хранения данных (во избежание неоднозначности). Поскольку блок 0 
тома содержит загрузочный сектор, использование его для данных в любом случае 
невозможно.

Получить произвольный доступ к сжатым файлам возможно, но это сложно. Предполо-
жим, что процесс выполняет поиск блока 35 (см. рис. 11.28). Как NTFS найдет блок 35 
в сжатом файле? Сначала ей нужно прочитать и распаковать весь участок. Затем она 
узнает, где находится блок 35, и сможет передать его в любой процесс (который его 
прочитает). Выбор в качестве единицы сжатия 16 блоков — это компромисс: меньший 
размер снизил бы эффективность сжатия, больший сделал бы произвольный доступ 
еще более дорогим.

Журналирование

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

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


background image

1040  

 Глава 11. Изучение конкретных примеров: Windows 8 

(опция FSCTL_QUERY_USN_JOURNAL вызова NtFsControlFile). Файл журнала обычно 
очень большой, поэтому вероятность затирания записей до того, как они будут изучены, 
очень мала.

Шифрование файлов

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

Windows решает эти проблемы при помощи опции шифрования файлов, чтобы даже 
в случае кражи или загрузки в MS-DOS файлы были нечитаемыми. Для использова-
ния шифрования обычным способом необходимо пометить нужные каталоги как за-
шифрованные, после чего все находящиеся в них файлы будут зашифрованы, а новые 
(переносимые или создаваемые файлы) также будут шифроваться. Шифрование и рас-
шифровка управляются не файловой системой NTFS, а драйвером под названием EFS 
(Encryption File System), который регистрирует обратные вызовы в NTFS.

EFS шифрует конкретные файлы и каталоги. В Windows есть еще одно средство шиф-
рования под названием BitLocker, которое шифрует почти все данные тома, что может 
помочь защитить данные несмотря ни на что — если только пользователь использует 
механизмы сильных ключей. С учетом того, что множество компьютеров теряют или 
крадут, а также высокой опасности «кражи личности» (identify theft) обеспечение за-
щиты секретов является очень важным. Каждый день пропадает потрясающее количе-
ство ноутбуков. Основные компании Wall Street теряют в такси Нью-Йорка в среднем 
один компьютер в неделю.

11.9. Управление электропитанием в Windows

Диспетчер электропитания

 (power manager) глаз не спускает с показателей исполь-

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

Новые средства управления электропитанием включают уменьшение потребления 
энергии компонентами, когда система не используется, для этого отдельные устрой-
ства переключаются в состояние резервирования или даже полностью отключаются 
(при помощи выключателя питания). Мультипроцессорные системы отключают от-
дельные процессоры, когда они не нужны, и даже могут уменьшать тактовую частоту 
процессоров (для уменьшения энергопотребления). Когда процессор бездействует, 
потребление им энергии также уменьшается, поскольку ему не нужно делать ничего, 
кроме ожидания возникновения прерывания.