новости
статьи
.мнение

Inside NTFS или как выглядят потороха - мнение системного программиста

вступление

Я думаю, что вряд ли найдется человек, имеющий дело с компьютерами и ни разу не слышавший аббревиатуру NTFS. Я даже расшифрую ее полностью: New Technology File System. Хвалебных статей и восторженных криков можно найти массу — как в прессе, так и в Интернете.. Я предлагаю вам свое видение этой новой технологичной файловой системы.

Внешне все выглядит очень благопристойно — максимальная емкость 64к * 2^64 (при размере сектора 512 байт), длина имени файла 255 символов (юникодных), имена файлов хранятся в юникоде, с файлом можно связывать всяческие посторонние данные, типа прав доступа, комментариев и чего там еще захочется. Имеется также журнал изменений и даже средство для пометки "плохих" кластеров.

Поддерживается сжатие и шифрование данных. Все выглядит очень замечательно и красиво, быть может она и была бы замечательной и красивой если бы ее делал не MicroSoft. Это все внешнее и это все усиленно раздувается и рекламируется.
Итак, заглянем в "потроха" NTFS. Единственное, что позволю себе еще заметить: NTFS — файловая система не для бедных (не по причине крутости FS, а по причине излишне занимаемых ресурсов).

итак, приступим...

Первое, о чем хотелось бы поговорить — это BootBlock. Вся идея NTFS заключается в объектности: есть небольшая кучка объектов со своими свойствами, эти свойства могут наследоваться, размножаться и видоизменятся — мечта C++ программиста... и кошмар системного программиста. Итак, начинаем с бутблока. Вопреки уже установишейся традиции поле OEM бутблока (начало +4) содержит не вендора/производителя, а гордое название NTFS (лично мне такой вендор не знаком), и поле метки тома содержит не символьную метку, а бинарный код, обозначающий серийный номер тома. Там есть еще небольшая кучка несоотвествий, приводящяя к тому, что для обработки бутблока надо писать отдельную процедуру. Лично для меня стало загадкой, почему MS декларировала максимальный размер кластера в 64к, хотя поле бутблок "Секторов на кластер" может принимать значение 256, что соотвествует 128к... Наверное опять синдром MS 64к сработал. Замечу, что ID партиции у NTFS равен 7, у HPFS тоже равен 7... Хотя в OS/2 в принципе это и называется ID Installable File System, но для JFS существует отдельный ID... впрочем называемый LVM partition. Соотвественно, системный программист, вспоминая всех родителей MS поименно, пишет на все это отдельные процедуры с кучей сравнений. В структуре NTFS также имеется файл $Boot, коий по всем канонам должен содержать как раз бутблок с загрузочной записью. На самом деле он указывает в никуда, занимая полезное место. Кроме того, постулировано, что загрузочная запись всегда занимает логический кластер 0. Теперь представим, что у нас размер кластера 512 байт и файл $Boot показывает в никуда. Что мы имеем? Правильно, небольшую кучку логических кластеров начиная с 0-го, которые по всем канонам должны считаться потеряными, так как никому не принадлежат.

Второе «чудо света» — File record. У NTFS есть несколько видов системных записей, из них мы будем рассматривать только две: File Record (FR) и Index Record (IR). Есстественно, начинать надо с FR, потому как с нее начинается любая работа с NTFS. Практически все системные записи NTFS имеют имя. Самая главная FR имеет имя $MFT и ссылка на ее размещение содержится в бутблоке, также имеется копия этой $MFT под названием $MFTmirr. "Это же великолепно! — воскликните вы, — Это же увеличивает надежность!". Да, конечно, заодно съедая полезное пространство, увеличивая количество операций записи и вдобавок полностью неуправляемо пользователем, чисто в стиле MS — "пользователь — полный идиот, мы лучше знаем, что ему надо". Все полезное место адресуется логическими кластерами, но каждая запись имеет свою адресацию, под названием виртуальные кластеры. Теперь заметим, что если логические кластеры имеют постоянный размер, записанный в бутблоке, то размер виртуального кластера может изменятся даже в одной цепочке распределения тех или иных данных. Подхватили упавшую челюсть? Продолжим, сразу заметив, что такой подход к делу исключает прогнозирование или предварительный расчет местонахождения сразу и навсегда, заодно делая кошмаром перевод виртуального кластера в логический. Надеюсь понятно, что для того, чтобы мне прочесть N-ый виртуальный кластер, мне придется вычитать все N-1 кластера в худшем случае. Надо отдать должное, MS вроде как поспособствовала тому, что бы экономить место, предусмотрела даже так называемые sparce-кластеры, но предусмотрела только один единственный случай, когда весь кластер состоит из нулей.

Дааалее... Директории. MS показалось мало записей типа FR, и в случае директорий в NTFS используется еще и IR. Сразу оговорим, что заранее размер IR узнать невозможно, нужно вычитать то место, где он указывается (+1 операция чтения). Можно только из BOOT Record узнать масксимальный размер, дабы отвести для этого буферы заранее. Штатная структура дирестории NTFS состоит из последовательности Имя — Кластер списка — Кластер распределения списка, итого уже надо читать 3 кластера в лучшем варианте (в отдельных случаях конечно может быть и один, но это для директорий содержащих максимум 2 файла). Далее учитываем, что и список, и распределение списка может быть фрагментировано, а фрагментированные записи тоже могут быть фрагментированы, мы получаем, мы получаем... Сразу заметим, что избыточность информации здесь на высшем уровне, сведения об файле типа имя и атрибуты хранятся аж в двух местах — FR и IR, зато размер файла надо узнавать через какое-то место, то бишь, вычитывая распределение. Если вспомнить, что сейчас не осталось таких ОС, которые по DIR или ls не показывают размер файла... Сразу замечу, что я даже таких FS не упомню, где размер файла не прописывался явно. Кроме того, мня позабавила адресация записей. По всем крикам MS, NTFS вся 64 бит, но... в одном месте номер файла 64 бита, в другом 48... Я встречал 32-ричную систему исчисления в t-mail, но 48-ричную... Далее заглянем в поле типа "время создания/доступа e.t.c." файла. Что мы видим? Правильно, время файла исчисляется с января 1601 года, выраженно в 100 наносекундных интервалах... Лично я весьма сомневаюсь, что в 1601 году вообще такое понятие, как секунда, было известно, уже не говоря о наносекундах, ну что можно сказать на это — "размахнись рука — раззудись плечо"?

Разберемся теперь с доступом к файлам — тем, ради чего вся эта FS и делалась. Сразу отметим, что с файлами небольших размеров (как показывает практика, до 512 байт) NTFS себя чуствует великолепно. Еще бы: они не требуют отдельного диского пространства, как в прочих FS. Но... как только на такой файл навесить права доступа, то, хотя данные и содержатся в самой FR, права доступа начинают фрагментироваться... Если навесить на этот файл комментарий (широко рекламируется как огромная фича) она тоже зафрагментируется. Итак, для того, чтобы наконец-таки поиметь хоть часть информации с файла, мы должны:
1. прочитать директрию;
2. выловить имя;
3. узнать распределение;
4. прочитать то что надо.

Во сколько обращений к диску эта примитивная операция чтения куска файла встанет, лично я прогнозировать не берусь. Если требовать от файла дополнительную информацию типа прав доступа или комментариев, то во что это выливается, я думаю, вы и сами сможете подсчитать. Я уже даже умолчу об упоминаемом размере файла, который необходим хотя бы для того, чтобы позиционироваться по файлу. Если учесть, что позицию в файле я могу определить только вычиткой сначала всего распределения файла по диску, становится грустно. Теперь призадумаемся, а сколько же надо сделать операций, дабы записать файл на NTFS?
1. запись MFT-записи;
2. правка $MFT;
3. правка $MFTmirr;
4. правка битмап;
5. правка директории;
6. правка записи самого файла;
7. запись собственно файла.

Нравится? Я согласен, что тут без журнала ну просто никуда, это, на мой взгляд, единственная FS, где журнал не тормозит работу, а ускоряет. С испорльзованием журнала, ессесно, все будет несколько иначе, как то:
1. запись в журнал;
2. молитва, чтоб не отключили питание.

Слегка подытожим. Итого, есть FS, объектная, как ящики в бывшем совке. Так же засекреченная и так же сжирающяя все что, подвернется под руку (ну или шину, или че там у нее). Так собственно чего же нового в этой New Techology FS? В общем только то, что данные мелких файлов могут хранится в самом описателе. Я достаточно детально изучал JFS/2 и до сих пор не могу отделаться от мысли, что они близнецы-братья, но только JFS сделана с участвием системных программистов, а вот NTFS явно нет.

Pavel Shtemenko
обсуждение статьи

© сетевые решения
.
.