Файловая система NTFS

Министерство РФ по связи и информатизации

Сибирский государственный университет телекоммуникаций и информатики

Уральский технический институт связи и информатики

(филиал)

Колледж УрТИСИ

Реферат

тема:  «Файловая система NTFS»

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

Исполнитель:

студент группы 271

Морозов  А.В.

Преподаватель:

Скрябина Е.А.

Екатеринбург

2003

Содержание:

 TOC \o "1-3" \h \z \u Файловая система. Что это и как работает?. \h 3

NTFS: Немного истории. \h 3

Основа NTFS. \h 3

Файлы и каталоги. \h 4

Конфиденциальность и сохранность данных. \h 4

Журналирование NTFS. \h 5

Некоторые специальные возможности. \h 8

Обслуживание диска. \h 9

Требовательность к ресурсам компьютера. \h 9

Что предпочтительнее: FAT32 или NTFS?. \h 9

Информационные источники: \h 11

Файловая система. Что это и как работает?

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

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

Сектор - минимальная единица пользовательских данных, которую могут использовать программы, работающие с жестким диском напрямую, в обход операционной системы.

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

NTFS: Немного истории

В апреле 1987 г. Microsoft и IBM начали совместную разработку новой операционной системы OS/2. Под эту ОС специально была разработана файловая система, призванная обеспечить стабильную и быструю работу с диском и облегчить труд администраторов. Но некоторые разногласия компаний привели к тому, что в сентябре 1990 г. сотрудничество было прекращено и каждый пошел своей дорогой. В результате мир получил OS/2 и файловую систему HPFS (High Perfomance File System) от IBM и Windows NT с файловой системой NTFS (New Technology File System) от Microsoft. У файловых систем было много общего, и до версии Windows NT 3.51 включительно Microsoft обеспечивала в своих операционных системах поддержку HPFS.

На сегодняшний день из семейства Windows файловую систему NTFS поддерживают только те операционные системы, которые базируются на ядре NT. Это Windows NT 3.xx, Windows NT 4.0, Windows 2000 и Windows XP.

Основа NTFS

Базисом NTFS является главная таблица файлов (Master File Table, MFT). MFT изначально резервирует под себя одну восьмую часть раздела (примерно 12%). Если место на разделе заканчивается, MFT сокращается в два раза, освобождая для файлов пользователя свободное пространство. Процедура может повторяться несколько раз. При появлении незанятого места MFT снова резервирует под себя 12% от объема раздела, что приводит к нежелательному эффекту - фрагментации MFT. При этом эффективность работы с NTFS-диском падает.

Файлы и каталоги

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

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

Каталоги в NTFS представляют собой ссылки на другие директории и файлы.

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

Есть ли ограничения при создании логического диска?

Практически нет. Дело в том, что объем раздела NTFS теоретически не ограничен, так как он может занимать до двух экзабайт (2 000 000 Гбайт). При этом логический диск может содержать до 224 файлов. А кластер не зависит от объема раздела, и стандартом де-факто является объем в 4 Кбайт.

Конфиденциальность и сохранность данных

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

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

Однако главное достоинство NTFS - журналирование и методы, которыми файловая система проводит операции с данными. Любое действие в разделе NTFS выполняется транзакцией. Транзакция - это пакет операций, который или выполняется полностью или не выполняется совсем, третьего не дано. Любое действие с данными записывается в журнал; из него в случае какого-либо сбоя в дальнейшем можно узнать, какая транзакция не смогла успешно завершиться и почему. Основные объекты NTFS ко всему прочему зеркалируются, т. е. делается резервная копия загрузочной записи и некоторых элементов MFT. Такая логика операций с данными приводит к высокой стабильности файловой системы. Сбой во время дефрагментации, скорее всего, будет просто незаметен для пользователя, в то время как для FAT32 такая ошибка стала бы в большинстве случаев фатальной.

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

Прежде всего, мне хотелось бы рассказать о том, какие именно операции журналируются. Совершенно очевидно, что полный undo-файл, способный откатить абсолютно все операции, абсолютно невозможен как с точки зрения быстродействия, так и с точки зрения здравого смысла. Да, такое журналирование дало бы возможность восстановить большее число данных - например, при осуществлении перезаписи трех мегабайт в середине файла мы могли бы сначала сохранить новые данные в логе, затем переписать туда же предыдущие три мегабайта файла, и уж только затем осуществлять операции с реальными данными. Такой подход гарантировал бы полную определенность с судьбой информации - мы всегда смогли бы понять, какая часть данных уже записалась на диск, а какая находится в исходном, не обновленном состоянии. Он имеет всего один скромный недостаток - небольшая накладочка по быстродействию: для записи на диск трех мегабайт мы вынуждены будем осуществить разнообразные дисковые операции на объем в три раза больший - девять мегабайт. Да, полное журналирование также применяется - но в основном при работе с базами данных. Если вы желаете обеспечить полное журналирование каких-либо данных, вы можете поставить MS SQL или даже Oracle, который вообще не будет пользоваться средствами какой либо файловой системы и обеспечит сохранность ваших данных в любых разумных условиях.

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

Отложенная запись и контрольные точки журналирования

Известно, что любая современная система для ускорения файловых операций вынуждена использовать кэширование, в том числе - кэширование операций записи. Так называемая отложенная запись - принцип кэширования, при котором данные, предназначенные для записи на диск, некоторое время сохраняются в КЭШе и лишь в свободное от других занятий время сохраняются физически. Отложенная запись существенно повышает эффективность дисковых операций, так как такое кэширование группирует множество операций в одну - это особенно эффективно, если запись производится в компактные участки диска. Еще один плюс отложенной записи - не мешать более нужным операциям чтения, и осуществлять запись только тогда, когда система свободна и ей не требуется доступ к диску для других нужд. Как согласовать отложенную запись с журналированием? Это довольно сложный вопрос, так как откладывание записи делает возможным потерю тех данных, которые находились в очереди на физическую запись и не успели записаться на диск до сбоя. Самое неприятное здесь даже не потеря данных, а то, что происходит рассогласование времени записи: какие-то служебные области могут быть обновлены, а какие-то смежные по смыслу - еще нет, так как их обновление могло отложится еще на пару секунд и не состоятся из-за сбоя.

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

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

Проблемы отложенного журналирования: концепция дублирования информации

Вся вышеописанная теория достаточно хороша, но способна, тем не менее, вызвать очень неприятные последствия, если не учесть еще нескольких вещей, о которых и пойдет речь.

Рассмотрим такой случай: мы стираем файл. Журнал получил запись - "файл N стирается". Затем запаздывающему КЭШу стало угодно осуществить сначала физическую пометку о том, что место, занимаемое файлом, освободилось, а уж только затем удалить файл из физических структур MFT и каталога. Допустим, диск находится в активной работе, и на освободившееся место тут же записывается другой файл. В этот момент происходит сбой. Система, загружаясь, исследует журнал и видит незавершенную операцию "файл N стирается" - вернее, как я уже описал выше, не незавершенную, а просто операцию, контрольная точка после которой отсутствует, что автоматически говорит о её незавершенности. Следующая фаза была бы "откат операции" - то есть восстановление файла. Одна незадача - место, физически занимаемое файлом, содержит уже другие данные.

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

Данный механизм применяется не только при стирании файла, но и при самых разных операциях: принцип журналирования - объект, убранный или перемещенный на новое место, должен иметь возможность корректно откатить своё "отбытие" - то есть данные, на которые ссылаются логические структуры удаляемого или перемещаемого объекта, необходимо еще на некоторое время зарезервировать как занятое место (диска/каталога). Это еще один шаг NTFS к полному журналированию, где специфическим журналом файловой информации служат сами данные освобождаемых областей, не уничтожаемые физически.

Допущения, обеспечивающие надежность

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

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

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

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

Четкое выполнение этих требований полностью гарантирует надежную работу NTFS. Структура файловой системы не будет содержать существенных ошибок даже после сбоя. Некоторые несущественные ошибки всё же появляются из-за того, что логика журналирования часто пытается завершить недоделанные операции - например, то же удаление файла - тогда как полную надежность обеспечивал бы только безусловный откат всего, что находится после последней контрольной точки. Малые несоответствия, рождающиеся из этих попыток, относятся к избыточной информации системы безопасности, не представляют никакой реальной опасности для данных - они действительно незначительны. Суть этих несоответствий чаще всего заключается в том, что на диске остаются "лишние" данные о тех режимах доступов, которые уже не понадобятся системе. Их прочистка - дело сугубо повышения производительности, как, например, дефрагментация, поэтому их наличие не является на самом деле ошибкой. В случае же обнаружения серьезных, реальных, проблем драйвер сам установит флажок тома "грязный", что проинструктирует систему проверить том при следующем его монтировании.

Некоторые специальные возможности

В NTFS существуют такие понятия, как жесткая ссылка и точка присоединения.

Жесткими (Hard Links) являются ссылки на такие файлы или каталоги (их может быть несколько), которые указывают на одну и ту же запись в главной таблице файлов, т. е. один и тот же элемент (файл или каталог) имеет несколько имен, а чтобы его удалить, необходимо уничтожить все ссылки на него. Тогда на счетчике указателей соответствующей этому элементу записи в MFT окажется ноль, а данные этого элемента будут стерты.

Точка присоединения (Reparse Point) - это, грубо говоря, ссылка, указывающая на какой-либо каталог (понятие <точка присоединения> нельзя применять к файлам). С ее помощью можно создать некий виртуальный каталог-дублер, неотличимый от оригинала, но располагающийся в другом месте структуры каталогов. Это бывает полезно при администрировании и работе с файлами.

Точка монтирования отличается от точки присоединения тем, что применяется не к каталогам, а к томам (логическим дискам). То есть если примонтировать диск D: к каталогу C:\Distrib, раздел D: как бы вообще перестает существовать для пользователя; к любому файлу бывшего диска D: он может обращаться через C:\Distrib.

Жесткая ссылка, точка присоединения и точка монтирования объединяются общим понятием <точка повторной обработки>.

Для администраторов серверов пригодится сервис квотирования - разграничение свободного пространства, доступного пользователю. Хотя на домашнем или обычном рабочем компьютере это не так уж и актуально.

Рассматриваемая файловая система обладает еще одной интересной функцией - возможностью сжатия. Сжатым может быть каталог, файл или даже часть файла. И уплотненный элемент не будет чем-либо отличаться от обычного в <понимании> приложений, его использующих. Таким образом, достигается увеличение свободного пространства, но время доступа к данным возрастает.

Обслуживание диска

Несколько хуже у NTFS обстоят дела с фрагментацией, особенно когда диск заполнен более чем на 88%. Выход в дефрагментации, но здесь есть проблема. Практически ни одна из созданных для этого программ не способна провести нормальную оптимизацию, поскольку возможности используемых ими стандартных функций ОС очень ограниченны. В результате этот процесс придется повторять чуть ли не каждый месяц. Один из немногих, а может быть, и единственный дефрагментатор, который способен исправить ситуацию, - Speed Disk из пакета программ Norton Utilities. Его методы работы позволяют обходить ограничения, наложенные функциями ОС. Так что выбор за вами: или не проводить дефрагментацию вообще, потому что оптимизацию раздела не этой утилитой можно назвать вредной, или использовать Speed Disk. Хотя падение производительности на NTFS из-за фрагментации гораздо менее заметно, чем в случае FAT32.

Требовательность к ресурсам компьютера

Для приятной (без заметного падения производительности) работы с рассматриваемой файловой системой необходимо достаточное количество оперативной памяти (64 Мбайт и более).

Наконец, как уже, наверное, понятно, для работы с NTFS-диском необходимо пользоваться ОС из семейства Windows NT. В принципе существуют обходные пути решения этой <проблемы>. Можно использовать специальные утилиты, делающие возможным доступ к разделу NTFS при работе операционной системы с другой файловой системой. Но большая часть из них обеспечит только чтение, являясь по сути лишь неким файловым протезом. Кроме того, эти программы чаще всего являются коммерческими продуктами, что невыгодно для обычных пользователей.

Что предпочтительнее: FAT32 или NTFS?

Если у вас есть желание выбрать NTFS, подумайте, сможете ли вы в полной мере насладиться ее возможностями. Целиком использовать преимущества этой файловой системы под силу только опытному пользователю, да и на домашнем компьютере обычно нет необходимости в шифровании данных, разделении прав и выделении квот. Конечно, в качестве главного критерия может выступать надежность, но в этом плане ничто не сравнится с резервным копированием данных. Однако почему бы не использовать RAID-массив из, скажем, двух жестких дисков в режиме <зеркало>?

Существует еще одна хитрость, подстерегающая любителей поэкспериментировать над своим жестким диском. Дело в том, что если преобразование FAT32 в NTFS легко осуществимо средствами, например, Windows NT/2000/XP, то обратное преобразование без потери данных не сделаешь. Поэтому, прежде чем решиться на настойчивое предложение Windows переформатировать FAT32 в NTFS, следует тщательно подумать, так как единственным методом обратного преобразования будет перепись содержимого NTFS-раздела диска на другой раздел с последующим форматированием NTFS-раздела и его преобразованием в FAT32.

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

А когда компьютер для вас большей частью является эдаким местом из печатной машинки и развлекательно-коммуникационного центра, то расширенные возможности, предоставляемые NTFS, едва ли стоят сложностей, например, с выбором ОС, поддерживающей NTFS и ваши любимые игры.

Информационные источники:

1.     http://www.iatp.irklib.ru

2.     http://www.osp.ru/pcworld

3.     Русский перевод книги Windows 2000.