Inside NTFS или как выглядят потроха

Самое главное - начать. Лозунг революционеров

Первое - 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 не могла так поступить с нами!", но история показывает, что MS поступает всегда так как удобно ей, а отнюдь не тем, кого она присадила на свою иглу под названием Windows. Надо отдать должное, MS типа поспособствовала тому, что бы экономить место, предусмотрела даже так называемые sparce кластера, но предусмотрела только один единственный случай, когда весь кластер состоит из нулей.

Трактор в поле dir, dir, dir - мы за мир, мы за мир.
Народная присказка

Второе - директории

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, то права доступа начинают фрагментироваться... Если навесить на этот файл комментарий (широко рекламируется как огромная фича) она тоже зафрагментируется. Итак, для того чтобы наконец таки поиметь хоть часть информации с файла, мы должны:

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

Во сколько обращений к диску эта примитивная операция чтения куска файла встанет, лично я прогнозировать не берусь, думаю и из MS engine никто на это не ответит. Если требовать от файла доп информацию типа прав доступа или комментариев, то во что это выливается, я думаю, что вы и сами сможете подсчитать. Я уже даже умолчу об упоминаемом размере файла, который необходим хотя бы для того, чтобы позиционироваться по файлу. Если учесть, что позицию в файле я могу определить только вычиткой сначала всего распределения файла по диску, становится грустно. Теперь призадумаемся, а сколько же надо сделать операций, дабы записать файл на NTFS? Наверняка ошибетесь, кучу, итого:

• Запись MFT записи
• правка $MFT
• правка $MFTmirr
• правка битмап
• правка директории
• правка записи самого файла
• запись файла собственно

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

• запись в журнал
• молитва, чтоб не отключили питание

Заключение

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

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

Послесловие

На мой взгляд плохих FS уже нет, есть только или плохо сделанный кеш или его недостаток. Hадо отдать должное, MS кешированию отдало куда больше сил, чем проектированию FS.