Загрузка...
Учебная работа. Реферат: Файловые системы, их виды
1.Введение ст. 2
2.Файловая система FAT ст. 2-3
3.Файловая система FAT32 ст. 3-8
3.1. Поиск данных файла ст. 3-4
3.2. Поиск вольного места ст. 4-5
3.3. Работа с каталогами и файлами ст. 5
3.4. кэширование ст. 5-6
3.5. Быстродействие накопителя ст. 6-7
3.6. Размер кластера ст. 7
3.7. Вывод ст. 8
4.Файловая система NTFS ст. 9-25
4.1. Физическая структура NTFS ст. 9-26
4.2. Дефрагментация NTFS ст.16-19
4.3. Программный RAID ст. 19
4.4. Шифрующая файловая система (EFS) ст. 19-22
4.5. Воздействие разных причин на быстродействие NTFS ст. 22-25
4.6 Вывод ст. 25
5.Перечень использованной литературы. ст. 26
1.Введение.
В истинное время существует огромное количество файловых систем. Для начала нужно разобраться, что все-таки такое файловая система? И что все-таки такое файл? Файловая система – это метод организации файлов на диске. Более всераспространены такие файловые системы, как FAT, FAT32, NTFS, Linux Ext2, Linux Swap. Любая операционная система (дальше ОС) употребляет свою файловую систему. к примеру, для Linux это Linux Ext2 и Linux Swap, для DOS, Windows 95/98/ME, Windows NT/2000/XP – FAT, для Windows 95 OEM release 2/98/ME/NT/2000/XP – FAT32 и для Windows NT/2000/XP – NTFS.
В файловых системах FAT, FAT32, NTFS файлы хранятся в, так именуемых, кластерах. кластер – это малая единица распределения в файловых системах FAT, FAT32, NTFS. один кластер состоит из фиксированного числа дисковых секторов. При этом, с помощью особых утилит размер кластера можно задавать самому. кластер не быть может по размеру меньше, чем один дисковый сектор (в большинстве современных винчестеров — 512 б). Если провести обзор файловых систем, то можно узнать их плюсы и минусы.
2.Файловая система FAT.
Файловая система FAT (File Allocation Table) использовалась во всех версиях ОС Ms-DOS, также в OS/2 (в версиях 1.0 и 1.1) и первых релизах Windows 95. Обозначенная файловая система полностью удовлетворяла требованиям собственного времени в главном благодаря тому, что сама по для себя весьма малогабаритна и ординарна. Благодаря этому она с легкостью использовалась на гибких носителях. Для хранения файла в FAT может употребляться один либо несколько кластеров. Любому кластеру диска в таблице FAT соответствует отдельная запись, которая или показывает на последующий кластер файла, или содержит метку конца файла. В составе всякого каталога хранятся имена входящих в него файлов. вкупе с именованием файла хранится указатель на 1-ый кластер этого файла. Кроме этого в каталоге хранится дата сотворения файла, его размер и атрибуты. Атрибуты могут указывать на то, что файл является сокрытым, зарезервированным для использования операционной системой, просит архивирования (запасного копирования) либо предназначен лишь для чтения. Чудилось бы, при таковой организации хранения данных, система обязана быть довольно резвой и надежной.
Давайте же разглядим ее недочеты. Самый 1-ый и основной недочет, с которым мы сталкиваемся при использовании FAT – это очень мощная ограниченность наибольшего размера тома FAT. Цифра 16 в заглавии FAT 16 значит, что таблица размещения файлов FAT идентифицирует записи, надлежащие дисковым кластерам, с помощью 16-разрядных чисел. Таковым образом, в таблице можно расположить не наиболее 65 536 записей (2 в 16-ой степени). А если учесть то, что наибольший размер кластера – 32 Кбайта, то выходит, что наибольший раздел дискового тома — 2 Гбайта. естественно, что эта система не удовлетворяет современным винчестерам, имеющим объемы в 10-ки гигабайтВторой недочет состоит в том, что для хранения всех файловых атрибутов система FAT употребляет всего 1 б! много ли можно поместить в один б? Как следует, просто не
представляется способности хранить данные о правах доступа к файлу, о его обладателе и т.д. Недочет номер три – при использовании большего размера тома мы обязаны применять больший размер кластера. Но, в FAT один файл занимает как минимум один кластер. К примеру, при размере кластера в 32 Кбайта мы имеем файл, размером 2 Кбайта – в итоге файл занимает весь кластер, и мы теряем 30 Кбайт. Таковым образом, выходит, что на физическом уровне файл занимает не 2, а все 32 Кбайта! 4-ый недочет – сведения о физическом расположении файлов хранятся в одном месте – таблице размещения файлов FAT. Это приводит к последующему:
— возрастает возможность повреждения и утраты всей инфы;
— понижается скорость поиска, т.к. для поиска определенного файла необходимо
обработать всю таблицу.
Подводя результат вышесказанному, можно прийти к выводу, что применять FAT в истинное время неэффективно. Но стоит увидеть, что FAT создавалась достаточно издавна и удовлетворяла требованиям тех пор.
3.Файловая система FAT 32
.
Эта файловая система пришла на замену FAT, начиная с Windows 95 OEM release 2. Основное ее отличие от FAT состоит в том, что таблица размещения файлов FAT идентифицирует записи, надлежащие дисковым кластерам, с помощью 32-разрядных чисел. В согласовании с сиим наибольшее количество записей становится равным 4 294 967 296 (2 в 32-ой степени). Как следует, значительно возрастает наибольший размер тома (до 2 Тбайт). Но в остальном система осталась фактически таковой же. Но необходимость работать с большущими по размеру томами и документами прямо показывает на недочеты FAT 32. Итак, разглядим их по порядку.
Поиск данных файла
.
В данной подглаве рассматривается конкретно поиск инфы. Доступ к самим данным (фрагментированы они либо нет) тут уже не рассматривается, потому что этот процесс схож для всех систем. Речь идет о тех излишних действиях, которые придется делать системе перед доступом к настоящим данным файлов. Этот параметр влияет на скорость доступа к произвольному фрагменту файла, указывает как очень сама файловая система
мучается от фрагментации файлов. И FAT 32 указывает себя тут не наилучшим образом. Из-за большенный области самой таблицы размещения будет испытывать большие трудности, если фрагменты файла разбросаны по всему диску. Дело в том, что таблица размещения файлов (FAT) представляет собой мини-образ диска, куда включен любой его кластер. Для доступа к фрагменту файла в системе FAT32 (как и в FAT) приходится обращаться к соответственной частице FAT. Если файл, например, размещен в 3-х фрагментах — сначала диска, посреди, и в конце — то в системе FAT нам придется обратиться к фрагменту FAT также в его начале, посреди и в конце. Если в FAT, где наибольший размер области FAT составляет 128 Кбайт, это не составляет задачи (вся область FAT просто хранится в памяти, либо же считывается с диска полностью за один проход и буферизируется), то в FAT32, которая имеет обычный размер области FAT порядка сотен кб (а на огромных дисках — даже несколько мб), это составляет довольно суровую делему. Если файл размещен в различных частях диска — это вынуждает систему совершать движения головок винчестера столько раз, сколько групп фрагментов в различных областях имеет файл, а это весьма и весьма очень замедляет процесс поиска фрагментов файла. Как следует, FAT32 испытывает большие трудности, прямо до чтения излишних сотен кб из области FAT, если файл разбросан различным областям диска. Работа с впечатляющими по размеру файлами на FAT32 в любом случае связана с большущими трудностями — осознать, в котором месте на диске размещен тот либо другой фрагмент файла, можно только исследовав всю
последовательность кластеров файла с самого начала, обрабатывая за один раз один кластер (через любые 4 Кбайт файла в обычной системе). Необходимо отметить, что если файл фрагментирован, но лежит малогабаритной кучей фрагментов — FAT32 всё же не испытывает огромных проблем, потому что физический доступ к области FAT будет также малогабаритен и буферизован.
Поиск вольного места
.
Эта операция делается в том случае, если нужно сделать файл с нуля, или скопировать его на диск. Поиск места под физические данные файла зависит от того, как хранится информация о занятых участках диска. Этот параметр влияет на скорость сотворения огромных файлов (при разработке малых файлов разница в скорости разных файловых систем фактически неприметна). Также влияет на сохранение либо создание огромных
мультимедийных файлов, копирование огромных размеров инфы и т.д. Этот параметр указывает, как стремительно система может отыскать пространство для записи на диск новейших данных и какие операции для этого придется ей сделать. Как уже указывалось выше таблица размещения файлов FAT вроде бы мини-образ диска, куда включен любой его кластер. Как следует, чтоб системе на базе FAT 32 (как вообщем, и FAT 16) найти, волен данный кластер либо нет, ей нужно просмотреть одну запись в FAT, подобающую этому кластеру. Размер одной записи в FAT 32 составляет 32 бита. Для поиска вольного места на диске может потребоваться просмотреть практически весь FAT, а он в свою очередь может достигать нескольких Мб (!!!), что ведет к чертовскому замедлению работы. Потому для нахождения вольного способа используются способы оптимизации, в итоге что достигается применимая скорость. Одно можно сказать наверное — поиск вольного места при работе в DOS на FAT32 — трагический по скорости процесс, так как никакая оптимизация невозможна без поддержки хоть сколь суровой операционной системы.
Работа с каталогами и файлами
.
Любая файловая система делает простые операции с файлами: доступ, удаление, создание, перемещение и т.д. Скорость работы этих операций зависит от принципов организации хранения данных о отдельных файлах и от устройства структур каталогов. Этот параметр влияет на скорость всех операций с файлом, в том числе на скорость хоть какой операции доступа к файлу, в особенности в каталогах с огромным числом файлов (несколько тыщ). FAT 32 имеет весьма малогабаритные сборники, размер каждой записи которых максимально мал. Наиболее того, из-за сложившейся исторически системы хранения длинноватых названий файлов (наиболее 11 знаков), в каталогах систем FAT употребляется не весьма действенная и на 1-ый взор плохая, но зато весьма экономичная структура хранения этих самих длинноватых названий файлов. Работа с каталогами FAT делается довольно стремительно, потому что в подавляющем числе случаев каталог (файл данных каталога) не фрагментирован и находится на диске в одном месте. Единственная неувязка, которая может значительно снизить скорость работы каталогов FAT — огромное количество файлов в одном каталоге (порядка тыщи либо наиболее). Система хранения данных — линейный массив — не дозволяет организовать действенный поиск файлов в таком каталоге, и для нахождения данного файла приходится перебирать большенный размер данных (в среднем половину файла каталога). Из выше произнесенного видно, что FAT 32 не может отлично работать с каталогами, содержащими огромное количество файлов.
кэширование
.
Весьма почти все данные современных файловых систем кэшируются либо буферизируются в памяти компа, что дозволяет избежать излишних операций физического чтения данных с диска. Для довольно высокопроизводительной работы системы в кэше приходится хранить
последующие данные:
— данные о физическом местоположении всех открытых файлов. Это, до этого всего, дозволит обращаться к системным файлам и библиотекам, доступ к которым идет практически повсевременно, без чтения служебной (не относящейся к самим файлам) инфы с диска. Это относится к тем файлам, которые исполняются в данный момент — т.е. к выполняемым модулям (.exe и .dll) активных действий в системе. В эту категорию попадают также файлы
системы, с которыми делается работа (до этого всего реестр и виртуальная память, разные .ini файлы, также файлы документов и приложений);
— данные о вольном месте диска — т.е. та информация, которая дозволит отыскать пространство для сохранения на диск новейших данных.
В случае, если этот базисный размер инфы не будет доступен прямо в оперативки, системе придется совершать огромное количество ненадобных операций еще до того, как она начнет работу с настоящими данными. И здесь перед нами встает вопросец: каким же объемом вольной оперативки нужно располагать, чтоб отлично работать с файловой системой? FAT 32 имеет весьма не достаточно данных, отвечающих за компанию файловой системы
(как, вообщем, и FAT 16). Из служебных областей можно выделить саму область FAT (если в FAT 16 она не могла превосходить 128 Кбайт, то в FAT 32 на томах порядка 5-10 Гбайт область FAT может занимать размер в несколько Мбайт). Это, пожалуй, единственный впечатляющий размер данных FAT 32, накрепко кэшировать который не представляется вероятным. Сборники FAT весьма малогабаритны и изредка занимают наиболее 1-го кластера. Как следует, на кэширование фрагментов области FAT, отвечающих за положение рабочих файлов, нужно несколько Мбайт вольной оперативки, что достаточно таки мало по сопоставлению с той же NTFS. Но лично я бы не стал применять FAT 32 на дисках, объемом наиболее 30 Гбайт, потому что сама таблица FAT будет иметь просто большой размер. Лучший вариант для использования FAT 32 – машинки с малыми и средними винчестерами (до 10 Гбайт) и машинками, имеющими наименее 64 Мбайт оперативки. На других машинках лучше применять NTFS.
Быстродействие накопителя.
Итак, влияют ли физические характеристики вашего накопителя на быстродействие файловой системы? Да, влияют. Не очень, но влияют (в данном случае не имеются ввиду отличия ATA-66 от ATA-100, а возможность файловой системы применять те либо другие плюсы винчестеров). Разглядим характеристики винчестеров, действующие на быстродействие системы:
— время случайного доступа (random seek time). Благодаря простоте
организации файловой системы FAT 32 (и FAT 16), для доступа к системным
областям на обычном диске не приходится совершать много движений
головками диска, что является довольно огромным плюсом в пользу FAT.
— наличие Bus Mastering. Bus Mastering – особый режим работы драйвера и контроллера, при использовании которого обмен с диском происходит без роли микропроцессора. В истинное время большая часть IDE-контроллеров идут с системой Bus Mastering. естественно таковая система будет работать мало резвее, но на быстродействие FAT она сказывается не весьма очень, в отличие от NTFS.
— кэширование чтения и записи на уровне твердых дисков (размер буфера HDD — от 128 Кбайт до 1-2 Мбайт в современных дорогих дисках) — фактор,
который будет наиболее полезен системам на базе FAT. системы FAT,
естественно, получат некий плюс, от кэширования записи на физическом
уровне, серьезно принимать размер буфера винчестера при оценке
быстродействия файловой системы не стоит.
Подводя итоги, опять получим, что FAT 32 лучше покажет себя на наиболее
неспешных винчестерах, чем та же NTFS. Это в очередной раз наталкивает
на идея о устаревании FAT как файловой системы совершенно.
Размер кластера
.
Размер кластера можно задать фактически произвольно (от 512 б до 32
Кбайт). Больший размер кластера – это фактически постоянно большее
быстродействие. В особенности размер кластера влияет на системы FAT 32. Дело
в том, что увеличивая размер кластера, скажем в 2 раза, мы сокращаем
область FAT в те же 2 раза (в связи с тем, что миниатюризируется количество
кластеров на диске). В свою очередь сокращение области FAT в несколько
раз даст приметное повышение быстродействия, потому что размер системных
данных файловой системы очень сократиться, как следует, миниатюризируется и время, затрачиваемое на чтение данных о расположении файлов, и размер
оперативки, нужный для буферизирования данной для нас инфы.
Обычный размер кластера для FAT 32 также составляет 4 Кбайта, и
повышение его до 8, а то и 16 Кбайт будет довольно разумным с точки
зрения быстродействия для огромных винчестеров (10 и наиболее Гбайт). Не
глядя на увеличение быстродействия, увеличение размера кластера не
пройдет безнаказанно. Напомню, что в FAT один файл занимает минимум один кластер. Для примера, пусть у нас будет файл, размером 2 Кбайта. При
размере кластера в 4 Кбайта, мы потеряем всего 2 Кбайта, а при размере
кластера в 16 Кбайт, утрата составит уже 14 Кбайт. Потому не необходимо,
очень увлекаться повышением размеров кластера, поэтому как повышение
быстродействия скажется на вольном месте.
Вывод.
К какому же выводу можно придти, проанализировав все выше написанное? Для начала нужно разглядеть все плюсы и минусы файловой системы FAT 32.
FAT – плюсы:
1.Не требуется огромное количество оперативки для действенной
работы с ней.
2.Стремительная работа с малыми и средними каталогами.
3.диск совершает в среднем наименьшее количество движений головками (в
сопоставлении, к примеру с NTFS).
4.Довольно отлично работает на неспешных дисках. Не требовательна к
системам Bus Mastering.
5.Резвый доступ к данным на малеханьких по размеру винчестерах.
6.Малый размер файла каталога дозволяет фактически постоянно оставлять его
не фрагментированным.
FAT – минусы:
1.Трагическая утрата быстродействия с повышением фрагментации,
в особенности для огромных дисков.
2.Трудности с произвольным доступом к огромным (~10% от размера винчестера и наиболее) файлам.
3.Весьма неспешная работа с каталогами, содержащими огромное количество
файлов.
4.1-го б очевидно недостаточно для хранения атрибутов файла, из-за
этого нет способности хранить данные о правах доступа к файлу, его
обладателе и т.д.
Вывод навязывается сам собой. FAT 32 как система уже отжила свое. Она
указывает себя лишь на машинках с маленькими дисками и объемом ОЗУ
наименее 64 Мбайт. При наилучшей машине еще удобней будет применять
NTFS как исходя из убеждений быстродействия, так и исходя из убеждений надежности.
FAT 32 просто-напросто продлила жизнь файловой системе FAT, не наиболее
того.
4.Файловая система NTFS
.
Файловая система NTFS (расшифровывается как New Technology File System)
была разработана довольно издавна для Windows NT. В истинное время она
является файловой системой всего семейства Microsoft Windows NT, также
Windows XP. NTFS довольно непростая файловая система, потому изложение ее плюсов и недочетов нужно будет представить в нескольких частях, что дозволит как-то классифицировать большущее количество документаций по ней.
Физическая структура NTFS
.
Начнем с общих фактов. Раздел NTFS, на теоретическом уровне, быть может практически
какого угодно размера. Она поддерживает большие диски – до 16 Экзабайт
(1 Экзабайт равен 1 073 741 824 гб). Как же это много? Для
наглядности возмем обычной пример: представим, что диск способен
записать 1 Мбайт за секунду, тогда чтоб записать 1 Экзабайт (один, а не
шестнадцать) ему будет нужно 1000 млрд секунд. В одном году 3
миллиона секунд. Как следует, чтоб сохранить 1 Экзабайт инфы,
диску будет нужно 300 000 лет!!! Поддержки таковых большущих дисков с
припасом хватит на следующие 100 лет развития вычислительной техники
при всех темпах роста. Как обстоит с сиим дело на практике? Практически так
же. Наибольший размер раздела NTFS в данный момент ограничен только
размерами твердых дисков. NT4, правда, будет испытывать задачи при
попытке установки на раздел, если хоть какая-нибудь его часть отступает
наиболее чем на 8 Гб от физического начала диска, но эта неувязка касается,
только загрузочного раздела.
Лирическое отступление (индивидуальности установки NT 4.0). способ установки NT4.0 на пустой диск достаточно оригинален и может навести на некорректные мысли о способностях NTFS. Если вы укажете программке установки, что желаете отформатировать диск в NTFS, наибольший размер, который она для вас предложит, будет всего 4 Гб. Почему так не достаточно, если размер раздела NTFS по сути фактически неограничен? Дело в том, что установочная секция, как это ни феноминально, просто не понимает данной для нас файловой системы. Программка установки форматирует этот диск в обыденный FAT, наибольший размер которого в NT составляет 4 Гбайт (с внедрением не совершенно обычного большого кластера 64 Кбайта), и на этот FAT устанавливает NT. А вот уже в процессе первой загрузки самой операционной системы (еще в установочной фазе) делается резвое преобразование раздела в NTFS; так что юзер ничего и не замечает, не считая необычного «ограничения» на размер NTFS при установке. сейчас что касается самой NTFS.
структура раздела хранения файлов
.
Приблизительно все это смотрится так:
Свободное пространство диска, но, содержит в себе всё на физическом уровне свободное
пространство — незаполненные кусочки MFT-зоны туда тоже врубаются. Механизм
использования MFT-зоны такой: когда файлы уже недозволено записывать в
обыденное место, MFT-зона просто сокращается (в текущих версиях
операционных систем ровно вдвое), освобождая, таковым образом, пространство
для записи файлов. При освобождении места в обыкновенной области MFT зона
может опять расширится. При всем этом не исключена ситуация, когда в данной для нас
зоне остались и обыденные файлы: никакой аномалии здесь нет. Система
старалась бросить её вольной, но ничего не вышло. Не глядя на
все эти меры по предотвращению фрагментации, метафайл MFT все-же может фрагментироваться, но это весьма не нужно.
MFT и его структура.
Файловая система NTFS представляет собой выдающееся достижение
структуризации: любой элемент системы представляет собой файл — даже
служебная информация. Самый основной файл на NTFS именуется MFT, либо
Master File Table — общая таблица файлов. Конкретно он располагается в MFT
зоне и представляет собой централизованный каталог всех других файлов
диска, и себя самого. MFT поделен на записи фиксированного размера
(обычно 1 Кбайт), и любая запись соответствует, какому или файлу (в
общем смысле этого слова). 1-ые 16 файлов носят служебный нрав и
недосягаемы операционной системе — они именуются метафайлами, при этом
самый 1-ый метафайл — сам MFT. Эти 1-ые 16 частей MFT —
единственная часть диска, имеющая фиксированное положение. Любопытно,
что 2-ая копия этих же 16 записей, для надежности (они весьма важны)
хранится ровно в центре диска. Остальной MFT-файл может размещаться, как и хоть какой иной файл, в случайных местах диска — вернуть его положение можно при помощи его самого, «зацепившись» за самую базу – за 1-ый элемент MFT.
Метафайлы
.
1-ые 16 файлов NTFS (метафайлы) носят служебный нрав. Любой из
их отвечает за какой-нибудь нюанс работы системы. Преимущество так
модульного подхода заключается в поразительной гибкости — к примеру, на
FAT-е физическое повреждение в самой области FAT фатально для
функционирования всего диска, а NTFS может сдвинуть, даже фрагментировать по диску, все свои служебные области, обойдя любые
неисправности поверхности — не считая первых 16 частей MFT. Метафайлы
находятся корневом каталоге NTFS диска — они начинаются с знака имени
«$», хотя получить какую-либо информацию о их обычными средствами
трудно. Интересно, что и для этих файлов указан полностью настоящий размер —
можно выяснить, к примеру, сколько операционная система растрачивает на
каталогизацию всего вашего диска, посмотрев размер файла $MFT. В
последующей таблице приведены применяемые в данный момент метафайлы и их предназначение.
Заглавие метафайла. Описание
— $MFT сам MFT;
— $MFTmirr копия первых 16 записей MFT, размещенная в центре диска;
— $LogFile файл поддержки журналирования;
— $Volume Служебная информация — метка тома, версия файловой системы, т.д.;
— $AttrDef Перечень обычных атрибутов файлов на томе;
— $. Корневой каталог;
— $Bitmap карта вольного места тома;
— $Boot Загрузочный сектор (если раздел загрузочный);
— $Quota файл, в каком записаны права юзеров на внедрение
дискового места (начал работать только в NT5);
-$Upcase файл – таблица соответствия больших и строчных букв в имени
файлов на текущем томе. Нужен в главном поэтому, что в NTFS названия файлов записываются в Unicode, что составляет 65 тыщ разных знаков, находить огромные и малые эквиваленты которых весьма нетривиально.
Файлы и потоки
.
Итак, у системы есть файлы — и ничего не считая файлов. Что содержит в себе
это понятие на NTFS?
До этого всего, неотклонимый элемент — запись в MFT, ведь, как было
сказано ранее, все файлы диска упоминаются в MFT. В этом месте хранится
вся информация о файле, кроме фактически данных. имя файла,
размер, положение на диске отдельных фрагментов, и т.д. Если для
инфы не хватает одной записи MFT, то употребляются несколько,
при этом не непременно попорядку.
Опциональный элемент — потоки данных файла. Может показаться странноватым
определение «опциональный», но, тем не наименее, ничего необычного здесь нет.
Во-1-х, файл может не иметь данных — в таком случае на него не
расходуется свободное пространство самого диска. Во-2-х, файл может иметь не
весьма большенный размер. Тогда идет в ход достаточно удачное решение: данные
файла хранятся прямо в MFT, в оставшемся от главных данных месте в
границах одной записи MFT. Файлы, занимающие сотки б, обычно не имеют собственного «физического» воплощения в главный файловой области — все данные такового файла хранятся в одном месте — в MFT.
Достаточно любопытно обстоит дело и с данными файла. Любой файл на NTFS, в общем-то, имеет несколько абстрактное строение — у него нет как
таких данных, а есть потоки (streams). один из потоков и носит
обычный нам смысл — данные файла. Но большая часть атрибутов файла —
тоже потоки! Таковым образом, выходит, что базисная суть у файла
лишь одна — номер в MFT, а всё остальное опционально. Данная
абстракция может употребляться для сотворения достаточно комфортных вещей —
к примеру, файлу можно «прилепить» еще один поток, записав в него любые
данные — к примеру, информацию о создателе и содержании файла, как это
изготовлено в Windows 2000 (самая правая веб-сайт на котором находится таковая ссылка в Избранное (Favorites) тк обычно таковая ссылка активизирует скрипт который без вашего подготовительного согласия зано в свойствах файла,
просматриваемых из проводника). Любопытно, что эти доп потоки не заметны обычными средствами: наблюдаемый размер файла — это только размер основного потока, который содержит классические данные. Можно, например, иметь файл нулевой длинны, при стирании которого освободится 1 Гбайт вольного места — просто поэтому, что какая-нибудь хитрецкая программка либо разработка прилепила к нему доп поток
(другие данные) гигабайтового размера. Но по сути в
текущий момент потоки фактически не употребляются, так что бояться
схожих ситуаций не следует, хотя гипотетически они вероятны. Просто
имейте в виду, что файл на NTFS — это наиболее глубочайшее и глобальное
понятие, чем можно для себя вообразить, просто просматривая сборники диска.
Ну и в итоге: имя файла может содержать любые знаки, включая полый набор государственных алфавитов, потому что данные представлены в Unicode — 16-битном представлении, которое дает 65535 различных знаков.
Наибольшая длина имени файла — 255 знаков.
Сборники
.
Каталог на NTFS представляет собой специфичный файл, хранящий ссылки
на остальные файлы и сборники, создавая иерархическое строение данных на
диске. файл каталога поделен на блоки, любой из которых содержит имя
файла, базисные атрибуты и ссылку на элемент MFT, который уже
предоставляет полную информацию о элементе каталога. Внутренняя
структура каталога представляет собой бинарное дерево. Вот что это
значит: для поиска файла с данным именованием в линейном каталоге, таком,
к примеру, как у FAT, операционной системе приходится просматривать все
элементы каталога, пока она не отыщет подходящий. Бинарное же дерево
располагает названия файлов таковым образом, чтоб поиск файла осуществлялся
наиболее резвым методом — при помощи получения двухзначных ответов на
вопросцы о положении файла. вопросец, на который бинарное дерево способно
отдать ответ, такой: в которой группе, относительно данного элемента,
находится разыскиваемое имя — выше либо ниже? Мы начинаем с такового вопросца к
среднему элементу, и любой ответ сузивает зону поиска в среднем в два
раза. Файлы, скажем, просто отсортированы по алфавиту, и ответ на вопросец
осуществляется естественным методом — сопоставлением исходных букв. Область
поиска, суженная вдвое, начинает исследоваться аналогичным образом,
начиная снова же со среднего элемента. Приблизительно это будет смотреться так:
Как следует, для поиска 1-го файла посреди 1000, к примеру, FAT
придется выполнить в среднем 500 сравнений (более возможно, что
файл будет найден на середине поиска), а системе на базе дерева —
всего около 12-ти. Экономия времени поиска налицо. Не стоит, но
мыслить, что в обычных системах (FAT) всё так запущено: во-1-х,
поддержание перечня файлов в виде бинарного дерева достаточно трудоемко, а
во-2-х — даже FAT в выполнении современной системы (Windows2000 либо
Windows98) употребляет схожую оптимизацию поиска. Это просто еще один
факт, который необходимо знать. Охото также развеять распространенное
заблуждение о том, что добавлять файл в каталог в виде дерева сложнее,
чем в линейный каталог: это довольно сравнимые по времени операции —
дело в том, что для того, чтоб добавить файл в каталог, необходимо поначалу
удостоверится, что файла с таковым именованием там еще нет, и вот тут-то в линейной
системе у нас будут трудности с поиском файла, описанные выше, которые с
лихвой возместят саму простоту прибавления файла в каталог. Какую
информацию можно получить, просто прочитав файл каталога? Ровно то, что
выдает команда dir. Для выполнения простейшей навигации по диску не
необходимо лазить в MFT за каждым файлом, нужно только читать самую общую
информацию о файлах из файлов каталогов. Основной каталог диска —
корневой — ничем не различается от обыденных каталогов, не считая специальной
ссылки на него из начала метафайла MFT.
Журналирование.
NTFS — отказоустойчивая система, которая полностью может привести себя в
корректное состояние при фактически всех настоящих сбоях. Неважно какая
современная файловая система базирована на таком понятии, как транзакция —
действие, совершаемое полностью и корректно либо не совершаемое совершенно. У
NTFS просто не бывает промежных (неверных либо неправильных)
состояний — квант конфигурации данных не быть может поделен на до и опосля
сбоя, принося разрушения и неурядицу — он или совершен, или отменен.
Чтоб почувствовать плюсы журналирования, давайте разглядим некие
примеры:
Пример 1
: осуществляется запись данных на диск. Вдруг выясняется, что в
то пространство, куда мы лишь что решили записать еще одну порцию данных,
писать не удалось — физическое повреждение поверхности. Поведение NTFS в этом случае достаточно разумно: транзакция записи откатывается полностью —
система понимает, что запись не произведена. пространство помечается как
сбойное, а данные записываются в другое пространство — начинается новенькая
транзакция.
Пример 2
: наиболее непростой вариант — идет запись данных на диск. Вдруг
отключается питание и система перезагружается. На какой фазе
тормознула запись, где есть данные, а где «мусор»? На помощь приходит
иной механизм системы — журнальчик транзакций. Дело в том, что система,
поняв свое желание писать на диск, отметила в метафайле $LogFile это
свое состояние. При перезагрузке это файл изучается на предмет наличия
незавершенных транзакций, которые были прерваны трагедией и итог
которых непредсказуем — все эти транзакции отменяются: пространство, в которое
осуществлялась запись, помечается опять как свободное, индексы и
элементы MFT приводятся в с состояние, в каком они были до сбоя, и
система в целом остается размеренна. Ну а если ошибка произошла при
записи в журнальчик? Тоже ничего ужасного: транзакция или к тому же не
начиналась (идет лишь попытка записать намерения её произвести), или
уже завершилась — другими словами идет попытка записать, что транзакция на самом
деле уже выполнена. В крайнем случае при последующей загрузке система
сама полностью разберется, что по сути всё и так записано корректно,
и не направит внимания на пометку о незаконченную транзакции.
И все-же журналирование — не абсолютная панацея, а только средство
значительно уменьшить число ошибок и сбоев системы. Навряд ли рядовой
юзер NTFS хоть когда-нибудь увидит ошибку системы либо обязан будет запускать chkdsk — опыт указывает, что NTFS восстанавливается вполне в корректное состояние даже при сбоях в весьма загруженные дисковой активностью моменты. Вы сможете даже улучшить диск и в самый разгар этого процесса надавить reset — возможность утрат данных даже в этом случае будет весьма мала. Принципиально осознавать, но, что система восстановления NTFS гарантирует правильность файловой системы, а не ваших данных. Если вы производили запись на диск и получили трагедию — ваши данные могут и не записаться. Чудес не бывает.
Сжатие
.
Файлы NTFS имеют один достаточно нужный атрибут — «сжатый». Дело в том, что NTFS имеет встроенную поддержку сжатия дисков — то, для что ранее приходилось применять Stacker либо DoubleSpace. Хоть какой файл либо каталог в личном порядке может храниться на диске в сжатом виде – этот процесс совсем прозрачен для приложений. Сжатие файлов имеет весьма высшую скорость и лишь одно огромное отрицательное свойство – большущая виртуальная фрагментация сжатых файлов, которая, правда, никому особо не мешает. Сжатие осуществляется блоками по 16 кластеров и употребляет так именуемые «виртуальные кластеры» — снова же максимально гибкое решение, позволяющее достигнуть увлекательных эффектов — к примеру, половина файла быть может сжата, а половина — нет. Это достигается благодаря тому, что хранение инфы о компрессированности определенных фрагментов весьма похоже на обыденную фрагментацию файлов. Наглядно это можно изобразить последующим образом:
Видно, что сжатый файл имеет «виртуальные» кластеры, настоящей инфы в каких нет. Как система лицезреет такие виртуальные кластеры, она здесь же соображает, что данные предшествующего блока, кратного 16-ти, должны быть разжаты, а получившиеся данные как раз заполнят виртуальные кластеры — вот, на самом деле, и весь метод.
Сохранность
.
NTFS содержит огромное количество средств разграничения прав объектов — есть
Мировоззрение, что это самая совершенная файловая система из всех сейчас
имеющихся. В теории это, вне сомнения, так, но в текущих реализациях,
к огорчению, система прав довольно далека от эталона и представляет
собой хоть и твердый, но не постоянно логичный набор черт. права,
назначаемые хоть какому объекту и совершенно точно соблюдаемые системой,
эволюционируют — большие конфигурации, и дополнения прав осуществлялись уже пару раз и к Windows 2000 все-же они пришли к довольно
разумному набору. права файловой системы NTFS неразрывно соединены с самой системой — другими словами они, совершенно говоря, необязательны к соблюдению иной системой, если ей отдать физический доступ к диску. Для предотвращения физического доступа в Windows2000 (NT5) всё же ввели обычную возможность — о этом см. ниже. Система прав в собственном текущем состоянии довольно сложна, и ее описание далековато выводит за рамки нашей темы.
В принципе, на этом описание строения файловой системы можно окончить,
осталось только некое количество просто удобных и уникальных
вещей:
Hard Links. Эта штука была в NTFS с давних времен, но использовалась весьма изредка — и тем не наименее: Hard Link — это когда один
и этот же файл имеет два имени (несколько указателей файла-каталога либо
различных каталогов указывают на одну и ту же MFT запись). Допустим, один и
этот же файл имеет имена 1.txt и 2.txt: если юзер сотрет файл 1,
остается файл 2. Если сотрет 2 — остается файл 1, т. е. оба имени, с
момента сотворения, совсем равноправны. файл на физическом уровне стирается только тогда, когда будет удалено его крайнее имя.
Symbolic Links (NT5). Еще наиболее удобная возможность, позволяющая
созодать виртуальные сборники. Говоря другими словами, дозволяет монтировать сборники. к примеру, чтоб повсевременно не применять каталог с длинноватым именованием, к примеру C:documents and settingsadministratormy documents, его можно смотировать в иной каталог, к примеру в C:doc, при всем этом данный каталог будет являться виртуальным, другими словами содержать просто
ссылку на изначальный каталог, что весьма комфортно. Если возникнет желание
порвать связь виртуального и монтируемого каталогов, то необходимо быть
усмотрительным, потому что при попытке удалить его с помощью, к примеру, FAR’а, удалиться сам монтируемый каталог! Для удаления связей можно
применять обычную команду rd из командной строчки.
Шифрование (NT5). Нужная возможность для людей, которые волнуются за свои секреты — любой файл либо каталог может также быть зашифрован, что не даст возможность прочитать его иной установкой NT. В сочетании со обычным и фактически непрошибаемым паролем на загрузку самой
системы, эта возможность обеспечивает достаточную для большинства
применений сохранность избранных вами принципиальных данных. Наиболее тщательно о этом ниже, потому что тема довольно пространна и увлекательна.
Дефрагментация NTFS
Довольно увлекательный момент – это фрагментация и дефрагментация NTFS.
Дело в том, что ситуация, сложившаяся с этими 2-мя понятиями в
реальный момент, никак не быть может названа удовлетворительной. В
самом начале утверждалось, что NTFS не подвержена фрагментации файлов.
Это оказалось не совершенно так, и утверждение сменили — NTFS препятствует
фрагментации. Оказалось, что и это не совершенно так. Другими словами она, естественно,
препятствует, но толк от этого близок к нулю… на данный момент уже понятно, что
NTFS — система, которая как никакая иная предрасположена к
фрагментации, что бы ни утверждалось официально. Единственное что —
логически она не весьма от этого мучается. Все внутренние структуры
построены таковым образом, что фрагментация не мешает стремительно отыскивать
фрагменты данных. Но от физического последствия фрагментации — излишних
движений головок — она, естественно, не выручает. Мы же попробуем узнать,
почему так происходит. Как понятно, система посильнее всего фрагментирует
файлы, когда свободное пространство кончается, когда приходится применять
маленькие дырки, оставшиеся от остальных файлов. здесь возникает 1-ое свойство
NTFS, которое прямо содействует суровой фрагментации. Диск NTFS
поделен на две зоны. Сначала диска идет MFT зона — зона, куда вырастает
MFT, Master File Table. Зона занимает минимум 12% диска, и запись данных
в эту зону невозможна. Это изготовлено для того, чтоб не фрагментировался
хотя бы MFT. Но когда весь остальной диск заполняется — зона сокращается
ровно вдвое. И так дальше. Таковым образом, мы имеем не один заход
окончания диска, а несколько. В итоге если NTFS работает при диске,
заполненном приблизительно на 90% — фрагментация вырастает как бешенная. Попутное противное следствие заключается в том, что диск, заполненный наиболее чем на 88%, дефрагментировать практически нереально — даже API дефрагментации не может перемещать данные в MFT зону. Может оказаться так, что у нас не будет вольного места для маневра. Да и это еще не все. NTFS фрагментируется даже в том случае, если свободное пространство далековато от
истощения. Этому содействует странноватый метод нахождения вольного
места для записи файлов — 2-ое суровое упущение. метод действий
при хоть какой записи таковой: берется некий определенный размер диска и
заполняется файлом до упора. При этом по весьма увлекательному методу:
поначалу заполняются огромные дырки, позже мелкие. Т.е. обычное
распределение фрагментов файла по размеру на фрагментированной NTFS
смотрится так (размеры фрагментов):
16-16-16-16-16 – (скачок вспять) – 15-15-15-15 – (скачок вспять) …
Так процесс идет до самых маленьких дырок в 1 кластер, невзирая на то, что
на диске наверное есть и еще наиболее огромные кусочки вольного места.
А если еще вспомянуть сжатые файлы — при активной перезаписи огромных
размеров сжатой инфы на NTFS появляется циклопическое количество
«дырок» из-за перераспределения на диске сжатых размеров — если
какой-нибудь участок файла стал сжиматься лучше либо ужаснее, его приходится,
или изымать из непрерывной цепочки и располагать в другом месте, или
стягивать в объеме, оставляя за собой дырку. Вот и выходит в итоге,
что NTFS не препятствует фрагментации, а напротив, с «радостью»
фрагментирует даже то, что можно было не фрагментировать.
средства решения заморочек фрагментации
.
В NT существует обычное API дефрагментации. Владеющее увлекательным ограничением для перемещения блоков файлов: за один раз можно перемещать не наименее 16 кластеров (!), при этом начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. В общем, операция осуществляется только по 16 кластеров. А из этого следует вот что:
в дырку вольного места наименее 16 кластеров недозволено ничего переместить
(не считая сжатых файлов, но это неинтересные в данный момент тонкости).
Файл, будучи перемещенный в другое пространство, оставляет опосля себя (на новеньком
месте) «временно занятое пространство», дополняющее его по размеру до кратности
16 кластерам. При попытке как-то некорректно («не кратно 16») переместить файл, итог нередко непредсказуем. Что-то округляется, что-то просто не
{перемещается}… Тем не наименее, всё пространство деяния щедро рассыпается
«временно занятым местом» («временно занятое пространство» служит для облегчения восстановления системы в случае аппаратного сбоя и
освобождается через некое время, обычно кое-где пол минутки).
Тем не наименее, разумно было бы применять этот API, раз он есть. Его и
употребляют. И этот процесс дефрагментации состоит из последующих фаз:
— Вынимание файлов из MFT зоны. Не специально – просто возвратить их туда
назад не представляется вероятным. Безопасная фаза, и даже в чем то
нужная.
— Дефрагментация файлов. Непременно, нужный процесс, несколько, правда,
осложняемый ограничениями кратности перемещений — файлы нередко приходится перекладывать посильнее, чем это было бы разумно создать по разуму.
— Дефрагментация MFT, файла виртуальной памяти (pagefile.sys) и каталогов.
Вероятна через API лишь в Windows2000, по другому — при перезагрузке,
отдельным действием.
— Складывание файлов поближе к началу — так именуемая дефрагментация
вольного места. Вот о этом ужасном процессе подробнее.
Допустим, мы желаем положить файлы попорядку в начало диска. Кладем один
файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем
последующий — опосля хвоста, естественно. Через некое время, по
освобождению хвоста, имеем дырку размером наименее 16 кластеров, которую
позже нереально заполнить через API дефрагментации! В итоге, до
оптимизации картина вольного места смотрелась так: много дырок приблизительно схожего размера. Опосля оптимизации — одна дыра в конце диска, и много малеханьких (наименее 16 кластеров) дырок в заполненном файлами участке. Какие места сначала заполняются? Верно,
находящиеся поближе к началу диска маленькие дырки наименее 16 кластеров. Хоть какой
файл, плавненько сделанный на прооптимизированном диске, будет состоять из
одичавшего числа фрагментов, что востребует очередной оптимизации диска уже
через недельку! Таковым образом, имеется два приблизительно равнозначных варианта.
1-ый — нередко улучшить диск таковым дефрагментатором, смирясь при
этом с одичавшей фрагментацией поновой сделанных файлов. 2-ой вариант —
совершенно ничего не трогать, и смириться с равномерной, но еще наиболее
слабенькой фрагментацией всех файлов на диске. Но еще есть один метод –
применять дефрагментатор, который игнорирует API. На нынешний денек существует один таковой дефрагментатор – Norton SpeedDisk 5.x для NT. Все другие дефрагментаторы при разовом применении просто вредоносны. Если вы запускали его хоть раз — необходимо запускать его позже хотя бы раз за месяц, чтоб избавится от фрагментации новоприбывающих файлов. В этом и состоит основная сущность трудности фрагметирования и дефрагментирования файлов.
Программный RAID.
Журналирование NTFS, как уже указывалось ранее, ни в коей мере не
гарантирует от сбоев с потерей пользовательской инфы. Меж тем,
NT дает несколько вариантов сотворения систем, где, в разумных
критериях, гарантируется полностью всё. Можно также применять большее
число дисков для обеспечения не завышенной надежности, а, напротив,
завышенной скорости — либо того и другого сразу. О таковых
конфигурациях и речь пойдет в данной для нас части.
RAID (Redundant Array of Inexpensive Disks) — лишний массив
дешевых дисков. разработка, заключающаяся в одновременном
использовании нескольких дисковых устройств для обеспечения
черт надежности либо скорости, отсутствующих у накопителей в
отдельности. Windows NT поддерживает на программном уровне три уровня
RAID (так именуются стратегии работы дисковых массивов. Совершенно
существует 10 уровней RAID – RAID 0,1,2,3,4,5,6,7,10,53).
Шифрующая файловая система (EFS)
.
Шифрующая файловая система (Encrypting File System) — это тесновато
встроенная с NTFS служба, размещающаяся в ядре Windows 2000. Ее
предназначение: защита данных, хранящихся на диске, от несанкционированного
доступа методом их шифрования. Возникновение данной для нас службы не случаем, и
ожидалось издавна. Дело в том, что имеющиеся на нынешний денек
файловые системы не обеспечивают нужную защиту данных от
несанкционированного доступа. Возможно, бывалые юзеры могут
сделать возражение, сказав, что в NTFS есть функция разграничения доступа,
которая дозволит защитить данные от несанкционированного доступа. Да,
это так. Но что, если доступ к разделу будет осуществляться не через NT,
a впрямую физически? Ведь это просто организовать с помощью
той же системной дискеты. Загрузившись с нее можно будет просмотреть
нужные данные и никакие ограничения NT не посодействуют. естественно, можно
предугадать это и запретить загрузку с дискет либо CD-ROM и поставить
пароль на BIOS. Но таковая защита малоэффективна, потому что если есть
возможность вынести винчестер, то это не выручит ваши данные. Остается
один выход – зашифровать их. Самый обычной метод – архивирование файлов с паролем. Но тут есть ряд суровых недочетов. Во-1-х,
юзеру требуется всякий раз вручную шифровать и дешифрировать (то
есть, в нашем случае архивировать и разархивировать) данные перед
началом и опосля окончания работы, что уже {само по себе} уменьшает
защищенность данных. юзер может запамятовать зашифровать
(заархивировать) файл опосля окончания работы, либо (еще наиболее обыденно)
просто бросить на диске копию файла. Во-2-х, пароли, выдуманные
юзером, как правило, просто угадываются. В любом случае,
существует достаточное количество программ, позволяющих распаковывать
архивы, защищенные паролем. Как правило, такие программки производят
подбор пароля методом перебора слов, записанных в словаре. С целью
преодоления всех этих недочетов и была разработана система EFS. EFS
употребляет архитектуру Windows CryptoAPI. В ее базе лежит разработка
шифрования с открытым ключом. Для шифрования всякого файла случайным образом генерируется ключ шифрования файла. При всем этом для шифрования файла может применяться хоть какой симметричный метод шифрования. В истинное же время в EFS употребляется один метод, это DESX, являющийся специальной модификацией обширно всераспространенного эталона DES. Ключи шифрования EFS хранятся в резидентном пуле памяти (сама EFS размещена в ядре Windows 2000), что исключает несанкционированный доступ к ним через файл подкачки.
По дефлоту EFS сконфигурирована таковым образом, что юзер может сходу начать применять шифрование файлов. Операция шифрования и оборотная поддерживаются для файлов и каталогов. В том случае, если шифруется каталог, автоматом шифруются все файлы и подкаталоги этого каталога. нужно отметить, что если зашифрованный файл {перемещается} либо переименовывается из зашифрованного каталога в незашифрованный, то он все равно остается зашифрованным. Операции шифрования/дешифрования можно выполнить 2-мя разными методами — используя Windows Explorer либо консольную утилиту Cipher. Для того чтоб зашифровать каталог из Windows Explorer, юзеру необходимо просто избрать один либо несколько каталогов и установить флаг шифрования в окне расширенных параметров каталога. Все создаваемые позднее файлы и подкаталоги в этом каталоге будут также зашифрованы. Таковым образом, зашифровать файл можно, просто скопировав (либо перенеся) его в «зашифрованный» каталог. Зашифрованные файлы хранятся на диске в зашифрованном виде. При чтении файла данные автоматом расшифровываются, а при записи — автоматом шифруются.
юзер может работать с зашифрованными файлами так же, как и с
обыкновенными файлами, другими словами открывать и редактировать в текстовом
редакторе Microsoft Word документы, редактировать картинки в Adobe
Photoshop либо графическом редакторе Paint, и так дальше. Нужно
отметить, что ни в коем случае недозволено шифровать файлы, которые
употребляются при запуске системы — в это время личный ключ юзера,
с помощью которого делается дешифровка, еще недоступен. Это может
привести к невозможности пуска системы! В EFS предусмотрена обычная
защита от таковых ситуаций: файлы с атрибутом «системный» не шифруются.
Но будьте внимательны: это может сделать «дыру» в системе
сохранности! Инспектируйте, не установлен ли атрибут файла «системный» для
того, чтоб убедиться, что файл вправду будет зашифрован. Принципиально
также держать в голове о том, что зашифрованные файлы не могут быть сжаты
средствами Windows 2000 и напротив. Другими словами, если каталог сжат,
его содержимое не быть может зашифровано, а если содержимое каталога
зашифровано, то он не быть может сжат. В том случае, если будет нужно
дешифровка данных, нужно просто снять флажки шифрования у избранных каталогов в Windows Explorer, и файлы и подкаталоги автоматом будут дешифрованы. Необходимо подчеркнуть, что эта операция обычно не требуется, потому что EFS обеспечивает «прозрачную» работу с зашифрованными данными для юзера.
Восстановление данных
.
EFS обеспечивает встроенную поддержку восстановления данных на тот
вариант, если будет нужно их расшифровать, но, по любым причинам,
это не быть может выполнено обыденным методом. По дефлоту, EFS
автоматом сгенерирует ключ восстановления, установит сертификат
доступа в учетной записи админа и сохранит его при первом входе
в систему. Таковым образом, админ становится так именуемым
агентом восстановления, и сумеет расшифровать хоть какой файл в системе.
Очевидно, политику восстановления данных можно поменять, и назначить в
качестве агента восстановления специального человека, ответственного за
сохранность данных, либо даже несколько таковых лиц. Итак, кратко факты о
EFS:
Система EFS в Windows 2000 предоставляет юзерам возможность
зашифровывать сборники NTFS, используя устойчивую, основанную на общих ключах криптографическую схему, при всем этом все файлы в закрытых каталогах будут зашифрованы. Шифрование отдельных файлов поддерживается, но не рекомендуется из-за непредсказуемого поведения приложений.
Система EFS также поддерживает шифрование удаленных файлов, доступ к
которым осуществляется как к вместе применяемым ресурсам. Если имеют пространство пользовательские профили для подключения, употребляются ключи и сертификаты удаленных профилей. В остальных вариантах генерируются локальные профили и употребляются локальные ключи.
Система EFS предоставляет установить политику восстановления данных
таковым образом, что зашифрованные данные могут быть восстановлены при
помощи EFS, если это будет нужно.
Политика восстановления данных встроена в общую политику сохранности
Windows 2000. Контроль за соблюдением политики восстановления быть может делегирован уполномоченным на это лицам. Для всякого подразделения организации быть может сконфигурирована своя Политика восстановления данных.
Восстановление данных в EFS — закрытая операция. В процессе
восстановления расшифровываются данные, но не ключ юзера, при
помощи которого эти данные были зашифрованы.
Работа с зашифрованными файлами в EFS не просит от юзера
каких-то особых действий по шифрованию и дешифрованию данных. Дешифрование и шифрование происходят неприметно для юзера в процессе считывания и записи данных на диск.
Система EFS поддерживает запасное копирование и восстановление
зашифрованных файлов без их расшифровки. программка NtBackup поддерживает запасное копирование зашифрованных файлов.
Система EFS встроена в операционную систему таковым образом, что утечка
инфы через файлы подкачки невозможна, при всем этом гарантируется, что
все создаваемые копии будут зашифрованы. Предусмотрены бессчетные меры предосторожности для обеспечения сохранности восстановления данных, также защита от утечки и утраты данных в случае фатальных сбоев системы.
Воздействие разных причин на быстродействие NTFS
.
Для удобства сопоставления, причины будут взяты те же, по которым проводился
анализ быстродействия FAT 32. Потому что общие слова о значении всякого
параметра были сказаны в описании FAT 32, поясняться любой параметр не
будет, а будет сходу написано воздействие этого параметра на NTFS.
Поиск данных файла
.
NTFS способна обеспечить резвый поиск фрагментов, так как вся
информация хранится в нескольких весьма малогабаритных записях (обычный
размер — несколько кб). Если файл весьма очень фрагментирован, то
NTFS придется применять много записей, что нередко принудит хранить их
в различных местах. Излишние движения головок при поиске этих данных, в таком
случае, приведут к сильному замедлению процесса поиска данных о
местоположении файла. Как вывод, можно сказать, что NTFS указывает себя достаточно таки хорошо, потому что эта система не просит чтения излишней
инфы до того момента, пока файл имеет уместно число фрагментов.
Поиск вольного места
.
В отличие от FAT 32, NTFS имеет битовую карту вольного места (другими словами
одному кластеру соответствует один бит). Как следует, для поиска
вольного места на диске NTFS не придется оценивать огромные объемы
инфы.
Работа с каталогами и файлами
.
NTFS употребляет довольно действенный метод адресации – бинарное
дерево. Таковая организация дозволяет отлично работать с каталогами
хоть какого размера (NTFS указывает высочайшее быстродействие даже в каталогах, где количество файлов превосходит 10-ки тыщ). Подробнее о структуре каталогов было написано выше.
кэширование
.
NTFS, к огорчению, имеет огромные требования к памяти, нужной для
работы системы. До этого всего, кэширование очень затрудняет огромные
размеры каталогов. Размер одних лишь каталогов, с которыми интенсивно
ведет работу система, может просто доходить до нескольких Мбайт и даже
10-ов Мбайт! Добавьте к этому необходимость кэшировать карту
вольного места тома (сотки Кбайт) и записи MFT для файлов, с которыми
осуществляется работа (в обычной системе — по 1 Кбайт на любой файл).
К счастью, NTFS имеет удачную систему хранения данных, которая не
приводит к повышению каких-то фиксированных областей при увеличении размера диска. количество данных, с которым оперирует система на базе NTFS, фактически не зависит от размера тома, и главный вклад в объемы данных, которые нужно кэшировать, заносят сборники. Тем не наименее, уже этого полностью довольно для того, чтоб лишь малый размер данных, нужных для кэширования базисных областей NTFS, доходил до 5 — 8 Мбайт. Потому можно с уверенностью сказать, что NTFS теряет большущее количество собственного теоретического быстродействия из-за
недостающего кэширования. 64 Мбайта ОЗУ для NTFS – самый минимум! Но даже таковой размер памяти не дает способности организовать более
эффективную работу NTFS. системы с огромным объемом памяти (идеальнее всего 128 Мбайт и наиболее) сумеют уверенно кэшировать все, что нужно для работы систем. На таковых машинках NTFS покажет наибольшее
быстродействие.
Быстродействие накопителя
.
время случайного доступа (random seek time). К огорчению, для доступа к
системным областям на обычном диске наиболее сложной файловой системы
(NTFS) приходится совершать, в среднем, больше движений головками диска, чем в наиболее обычных системах (FAT16 и FAT32). Еще большая
фрагментация каталогов, возможность фрагментации системных областей —
всё это делает диски NTFS еще наиболее чувствительными к скорости
считывания случайных (случайных) областей диска. По данной для нас причине
применять NTFS на неспешных (старенькых) дисках не рекомендуется.
наличие Bus Mastering. Система запаздывающего кэширования NTFS сумеет
действовать еще наиболее отлично при наличии Bus Mastering, потому что
NTFS производит отложенную запись еще большего числа данных. системы без Bus Mastering в истинное время встречаются довольно изредка (обычно это накопители либо контроллеры, работающие в режиме PIO3 либо PIO4), и если вы работаете с таковым диском — то, быстрее всего, NTFS растеряет еще пару очков быстродействия, в особенности при операциях модификации каталогов (к примеру, активная работа в вебе — работа с кэшем веба).
кэширование как чтения, так и записи на уровне твердых дисков (размер
буфера HDD — от 128 Кбайт до 1-2 Мбайт в современных дорогих дисках).
NTFS из суждений надежности хранения инфы производит
модификацию системных областей с флагом «не кэшировать запись», потому быстродействие системы NTFS слабо зависит от способности кэширования самого HDD.
Размер кластера
.
Обычный размер кластера для NTFS — 4 Кбайта. Необходимо отметить, что при
большем размере кластера отключается интегрированная в файловую систему
возможность сжатия личных файлов, также перестает работать
обычный API дефрагментации — т.е. подавляющее число
дефрагментаторов, в том числе интегрированный в Windows 2000, будут
неспособны дефрагментировать этот диск. SpeedDisk, вообщем, сумеет — он
работает без использования данного API. Хорошим исходя из убеждений
быстродействия, по последней мере, для средних и огромных файлов, считается
(самой Microsoft) размер 16 Кбайт. Наращивать размер дальше неразумно
из-за очень огромных расходов на неэффективность хранения данных и
из-за маленького предстоящего роста быстродействия. Если вы желаете
повысить быстродействие NTFS ценой утраты способности сжатия —
подумайте о форматировании диска с размером кластера, огромным чем 4
Кбайта. Но имейте в виду, что это даст достаточно умеренный прирост
быстродействия, который нередко не стоит даже уменьшения эффективности
размещения файлов на диске.
Некие остальные суждения
.
NTFS является довольно сложной системой, потому, в отличие от FAT и
FAT32, имеются и остальные причины, которые могут привести к существенному замедлению работы NTFS:
Диск NTFS был получен преобразованием раздела FAT либо FAT32
(специальной программкой, напр. Partition Magic). Данная процедура в
большинстве случаев представляет собой тяжкий вариант для
быстродействия, потому что структура служебных областей NTFS, быстрее всего,
получится весьма фрагментированной. Если есть возможность нужно
избегать преобразования остальных систем в NTFS, потому что это приведет к
созданию весьма плохого диска, которому не поможет даже обычный
(неспециализированный) дефрагментатор, типа Diskeeper-а либо встроенного
в Windows 2000.
Активная работа с диском, заполненным наиболее чем на 80% — 90%,
представляет собой трагический для быстродействия NTFS вариант, так
как фрагментация файлов и, самое основное, служебных областей, будет
расти фантастически стремительно. Если ваш диск употребляется в таком режиме —
FAT32 будет наиболее удачным выбором при всех остальных критериях.
Вывод.
NTFS – это система грядущего. Но в истинное время не любой может ее для себя дозволить из-за огромного количества “но” в на теоретическом уровне безупречной системе. До этого всего, это высочайшие системные требования: наличие наиболее 64 Мб ОЗУ, неплохой винчестер поддерживающий Bus Mastering, высококачественное «железо» для размеренной работы. FAT же наименее требовательна к системе.
]]>