Продовження читайте в статті "Надійність дискової системи NT"

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

Частина 1. Фізична структура NTFS

Почнемо з загальних фактів. Розділ NTFS, теоретично, може бути майже будь-якого розміру. Межа, звичайно, є, але я навіть не буду вказувати його, так як його з запасом вистачить на наступні сто років розвитку обчислювальної техніки - при будь-яких темпах зростання. Як справи з цим справа на практиці? Майже так само. Максимальний розмір розділу NTFS в даний момент обмежений лише розмірами жорстких дисків. NT4, щоправда, буде мати проблеми при спробі установки на розділ, якщо хоч якась його частина відступає більш ніж на 8 Гб від фізичного початку диска, але ця проблема стосується лише завантажувального розділу.

Метод інсталяції NT4.0 на порожній диск досить оригінальний і може навести на неправильні думки про можливості NTFS. Якщо ви вкажете програмі установки, що бажаєте відформатувати диск в NTFS, максимальний розмір, який вона вам запропонує, буде всього 4 Гб. Чому так мало, якщо розмір розділу NTFS насправді практично необмежений? Справа в тому, що установча секція просто не знає цієї файлової системи :) Програма установки форматує цей диск у звичайний FAT, максимальний розмір якого в NT становить 4 Гбайт (з використанням не зовсім стандартного величезного кластеру 64 Кбайта), і на цей FAT встановлює NT . А ось вже в процесі першого завантаження самої операційної системи (ще в настановної фазі) проводиться швидке перетворення розділу в NTFS; так що користувач нічого і не помічає, крім дивного «обмеження» на розмір NTFS при установці. :)

Структура розділу - загальний погляд

Як і будь-яка інша система, NTFS ділить все корисне місце на кластери - блоки даних, що використовуються одноразово. NTFS підтримує майже будь-які розміри кластерів - від 512 байт до 64 Кбайт, певним стандартом ж вважається кластер розміром 4 Кбайт. Ніяких аномалій кластерної структури NTFS не має, тому на цю, загалом-то, досить банальну тему, сказати особливо нічого.

Диск NTFS умовно ділиться на дві частини. Перші 12% диска відводяться під так звану MFT зону - простір, в яке росте метафайл MFT (про це нижче). Запис будь-яких даних в цю область неможлива. MFT-зона завжди тримається порожньою - це робиться для того, щоб найголовніший, службовий файл (MFT) НЕ фрагментованих при своєму зростанні. Решта 88% диска є звичайне простір для зберігання файлів.

Вільне місце диска, проте, включає в себе все фізично вільне місце - незаповнені шматки MFT-зони туди теж включаються. Механізм використання MFT-зони такий: коли файли вже не можна записувати в звичайний простір, MFT-зона просто скорочується (в поточних версіях операційних систем рівно в два рази), звільняючи таким чином місце для запису файлів. При звільненні місця у звичайній області MFT зона може знову розшириться. При цьому не виключена ситуація, коли в цій зоні залишилися і звичайні файли: ніякої аномалії тут немає. Що ж, система намагалася залишити її вільною, але нічого не вийшло. Життя триває ... Метафайл MFT все-таки може фрагментований, хоч це і було б небажано.

MFT і його структура

Файлова система NTFS являє собою видатне досягнення структуризації: кожен елемент системи являє собою файл - навіть службова інформація. Найголовніший файл на NTFS називається MFT, або Master File Table - загальна таблиця файлів. Саме він розміщується в MFT зоні і являє собою централізований каталог всіх інших файлів диска, і, хоч як це парадоксально, себе самого. MFT поділений на записи фіксованого розміру (зазвичай 1 Кбайт), і кожна запис відповідає якому або файлу (в загальному розумінні цього слова). Перші 16 файлів носять службовий характер і недоступні операційній системі - вони називаються метафайлами, причому найперший метафайл - сам MFT. Ці перші 16 елементів MFT - єдина частина диска, що має фіксоване положення. Цікаво, що друга копія перших трьох записів, для надійності - вони дуже важливі - зберігається рівно посередині диска. Решта MFT-файл може розташовуватися, як і будь-який інший файл, в довільних місцях диска - відновити його положення можна за допомогою його самого, «зачепившись» за саму основу - за перший елемент MFT.

метафайли

Перші 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, то використовуються декілька, причому не обов'язково підряд.
• Опціональний елемент - потоки даних файлу. Може здатися дивним визначення «опціональний», але, тим не менш, нічого дивного тут немає. По-перше, файл може не мати даних - в такому випадку на нього не витрачається вільне місце самого диска. По-друге, файл може мати не дуже великий розмір. Тоді йде в хід досить вдале рішення: дані файлу зберігаються прямо в MFT, в що залишився від основних даних місці в межах одного запису MFT. Файли, що займають сотні байт, зазвичай не мають свого «фізичного» втілення в основний файлової області - всі дані такого файлу зберігаються в одному місці - в MFT.

Досить цікаво йде справа і з даними файлу. Кожен файл на NTFS, в общем-то, має кілька абстрактне будову - у нього немає як таких даних, а є потоки (streams). Один з потоків і носить звичний нам сенс - дані файлу. Але більшість атрибутів файлу - теж потоки! Таким чином, виходить, що базова сутність у файлу тільки одна - номер в MFT, а все інше опціонально. Дана абстракція може використовуватися для створення досить зручних речей - наприклад, файлу можна «приліпити» ще один потік, записавши в нього будь-які дані - наприклад, інформацію про автора і зміст файлу, як це зроблено в Windows 2000 (сама права закладка у властивостях файлу, переглядаються з провідника). Цікаво, що ці додаткові потоки не видно стандартними засобами: спостережуваний розмір файлу - це лише розмір основного потоку, який містить традиційні дані. Можна, наприклад, мати файл нульової довжини, при стирання якого звільниться 1 Гбайт вільного місця - просто тому, що якась хитра програма або технологія приліпила в нього додатковий потік (альтернативні дані) гигабайтового розміру. Але насправді в поточний момент потоки практично не використовуються, так що побоюватися подібних ситуацій не слід, хоча гіпотетично вони можливі. Просто майте на увазі, що файл на NTFS - це більш глибоке і глобальне поняття, ніж можна собі уявити просто переглядаючи каталоги диска. Ну і наостанок: ім'я файлу може містити будь-які символи, включаючи порожній набір національних алфавітів, так як дані представлені в Unicode - 16-бітному поданні, яке дає 65535 різних символів. Максимальна довжина імені файлу - 255 символів.

Каталоги

Каталог на NTFS є специфічний файл, який зберігає посилання на інші файли і каталоги, створюючи ієрархічну будову даних на диску. Файл каталогу поділений на блоки, кожен з яких містить ім'я файлу, базові атрибути і посилання на елемент MFT, який вже надає повну інформацію про елемент каталогу. Внутрішня структура каталогу є бінарне дерево. Ось що це означає: для пошуку файлу з такою назвою в лінійному каталозі, такому, наприклад, як у FAT-а, операційній системі доводиться переглядати всі елементи каталогу, поки вона не знайде потрібний. Бінарне ж дерево має в своєму розпорядженні імена файлів таким чином, щоб пошук файлу здійснювався більш швидким способом - за допомогою отримання двозначних відповідей на питання про становище файлу. Питання, на який бінарне дерево здатне дати відповідь, такий: в якій групі, щодо даного елемента, знаходиться шукане ім'я - вище або нижче? Ми починаємо з такого питання до середнього елементу, і кожен відповідь звужує зону пошуку в середньому в два рази. Файли, скажімо, просто відсортовані за алфавітом, і відповідь на питання здійснюється очевидним способом - порівнянням початкових букв. Область пошуку, звужена в два рази, починає досліджуватися аналогічним чином, починаючи знову ж зі середнього елемента.

Висновок - для пошуку одного файлу серед 1000, наприклад, FAT доведеться здійснити в середньому 500 порівнянь (найбільш імовірно, що файл буде знайдений на середині пошуку), а системі на основі дерева - всього близько 12-ти (2 ^ 10 = 1024). Економія часу пошуку в наявності. Не варто, однак думати, що в традиційних системах (FAT) все так запущено: по-перше, підтримку списку файлів у вигляді бінарного дерева досить трудомістким, а по-друге - навіть FAT у виконанні сучасної системи (Windows2000 або Windows98) використовує подібну оптимізацію пошуку. Це просто ще один факт в вашу скарбничку знань. Хочеться також розвіяти поширена помилка (яке я сам розділяв зовсім ще недавно) про те, що додавати файл в каталог у вигляді дерева важче, ніж в лінійний каталог: це досить порівнянні за часом операції - справа в тому, що для того, щоб додати файл в каталог, потрібно спочатку переконається, що файлу з такою назвою там ще немає :) - і ось тут-то в лінійній системі у нас будуть труднощі з пошуком файлу, описані вище, які з лишком компенсують саму простоту додавання файлу в каталог.

Яку інформацію можна отримати, просто прочитавши файл каталогу? Рівно те, що видає команда dir. Для виконання найпростішої навігації по диску не потрібно лазити в MFT за кожним файлом, треба лише читати саму загальну інформацію про файлах з файлів каталогів. Головний каталог диска - кореневої - нічим не відрізняється про звичайні каталогів, крім спеціального посилання на нього з початку метафайлу MFT.

журнал

NTFS - відмовостійка система, яка цілком може привести себе в коректне стан при практично будь-яких реальних збої. Будь-яка сучасна файлова система заснована на такому понятті, як транзакція - дія, що здійснюється цілком і коректно або не робити взагалі. У NTFS просто не буває проміжних (помилкових чи некоректних) станів - квант зміни даних не може бути поділений на до і після збою, приносячи руйнування і плутанину - він або здійснений, або скасований.

Приклад 1: здійснюється запис даних на диск. Раптом з'ясовується, що в те місце, куди ми тільки що вирішили записати чергову порцію даних, писати не вдалося - фізичне пошкодження поверхні. Поведінка NTFS в цьому випадку досить логічно: транзакція запису відкочується цілком - система усвідомлює, що запис Нічого не зроблено. Місце позначаються як збійні, а дані записуються в інше місце - починається нова транзакція.

Приклад 2: більш складний випадок - йде запис даних на диск. Раптом, бах - відключається харчування та система перезавантажується. На якій фазі зупинилася запис, де є дані, а де чушь? На допомогу приходить інший механізм системи - журнал транзакцій. Справа в тому, що система, усвідомивши своє бажання писати на диск, позначила в метафайлі $ LogFile це свій стан. При перезавантаженні це файл вивчається на предмет наявності незавершених транзакцій, які були перервані аварією і результат яких непередбачуваний - всі ці транзакції скасовуються: місце, в яке здійснювалася запис, позначається знову як вільне, індекси і елементи MFT наводяться в с стан, в якому вони були до збою, і система в цілому залишається стабільною. Ну а якщо помилка сталася під час запису в журнал? Теж нічого страшного: транзакція або ще й не починалася (йде тільки спроба записати наміри її зробити), або вже закінчилася - тобто йде спроба записати, що транзакція насправді вже виконана. В останньому випадку при наступному завантаженні система сама цілком розбереться, що насправді все і так записано коректно, і не зверне уваги на «незакінчену» транзакцію.

І все-таки пам'ятайте, що журнал - не абсолютна панацея, а лише засіб істотно скоротити число помилок і збоїв системи. Навряд чи пересічний користувач NTFS хоч коли-небудь помітить помилку системи або змушений буде запускати chkdsk - досвід показує, що NTFS відновлюється в повністю коректне стан навіть при збоях в дуже завантажені дискової активністю моменти. Ви можете навіть оптимізувати диск і в самий розпал цього процесу натиснути reset - ймовірність втрат даних навіть в цьому випадку буде дуже низька. Важливо розуміти, однак, що система відновлення NTFS гарантує коректність файлової системи, а не ваших даних. Якщо ви проводили запис на диск і отримали аварію - ваші дані можуть і не записатися. Чудес не буває.

стиснення

Файли NTFS мають один досить корисний атрибут - "стиснутий». Справа в тому, що NTFS має вбудовану підтримку стиснення дисків - то, для чого раніше доводилося використовувати Stacker або DoubleSpace. Будь-який файл або каталог у індивідуальному порядку може зберігається на диску в стислому вигляді - цей процес абсолютно прозорий для додатків. Стиснення файлів має дуже високу швидкість і тільки одне велике негативне властивість - величезна віртуальна фрагментація стислих файлів, яка, правда, нікому особливо не заважає. Стиснення здійснюється блоками по 16 кластерів і використовує так звані «віртуальні кластери» - знову ж гранично гнучке рішення, що дозволяє домогтися цікавих ефектів - наприклад, половина файлу може бути стиснута, а половина - ні. Це досягається завдяки тому, що зберігання інформації про компрессирования певних фрагментів дуже схоже на звичайну фрагментацію файлів: наприклад, типова запис фізичної розкладки для реального, нестисненого, файлу:

кластери файлу з 1 по 43-й зберігаються у кластерах диска починаючи з 400-го

кластери файлу з 44 по 52-й зберігаються у кластерах диска починаючи з 8530-го ...

Фізична розкладка типового стисненого файлу:

кластери файлу з 1 по 9-й зберігаються у кластерах диска починаючи з 400-го

кластери файлу з 10 по 16-й ніде не зберігаються

кластери файлу з 17 по 18-й зберігаються у кластерах диска починаючи з 409-го

кластери файлу з 19 по 36-й ніде не зберігаються

Видно, що стиснений файл має "віртуальні" кластери, реальної інформації в яких немає. Як тільки система бачить такі віртуальні кластери, вона тут же розуміє, що дані попереднього блоку, кратного 16-ти, повинні бути розтиснену, а отримані дані як раз заповнять віртуальні кластери - ось, по суті, і весь алгоритм.

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

Частина 1. Фізична структура NTFS

Почнемо з загальних фактів. Розділ NTFS, теоретично, може бути майже будь-якого розміру. Межа, звичайно, є, але я навіть не буду вказувати його, так як його з запасом вистачить на наступні сто років розвитку обчислювальної техніки - при будь-яких темпах зростання. Як справи з цим справа на практиці? Майже так само. Максимальний розмір розділу NTFS в даний момент обмежений лише розмірами жорстких дисків. NT4, щоправда, буде мати проблеми при спробі установки на розділ, якщо хоч якась його частина відступає більш ніж на 8 Гб від фізичного початку диска, але ця проблема стосується лише завантажувального розділу.

Метод інсталяції NT4.0 на порожній диск досить оригінальний і може навести на неправильні думки про можливості NTFS. Якщо ви вкажете програмі установки, що бажаєте відформатувати диск в NTFS, максимальний розмір, який вона вам запропонує, буде всього 4 Гб. Чому так мало, якщо розмір розділу NTFS насправді практично необмежений? Справа в тому, що установча секція просто не знає цієї файлової системи :) Програма установки форматує цей диск у звичайний FAT, максимальний розмір якого в NT становить 4 Гбайт (з використанням не зовсім стандартного величезного кластеру 64 Кбайта), і на цей FAT встановлює NT . А ось вже в процесі першого завантаження самої операційної системи (ще в настановної фазі) проводиться швидке перетворення розділу в NTFS; так що користувач нічого і не помічає, крім дивного «обмеження» на розмір NTFS при установці. :)

Структура розділу - загальний погляд

Як і будь-яка інша система, NTFS ділить все корисне місце на кластери - блоки даних, що використовуються одноразово. NTFS підтримує майже будь-які розміри кластерів - від 512 байт до 64 Кбайт, певним стандартом ж вважається кластер розміром 4 Кбайт. Ніяких аномалій кластерної структури NTFS не має, тому на цю, загалом-то, досить банальну тему, сказати особливо нічого.

Диск NTFS умовно ділиться на дві частини. Перші 12% диска відводяться під так звану MFT зону - простір, в яке росте метафайл MFT (про це нижче). Запис будь-яких даних в цю область неможлива. MFT-зона завжди тримається порожньою - це робиться для того, щоб найголовніший, службовий файл (MFT) НЕ фрагментованих при своєму зростанні. Решта 88% диска є звичайне простір для зберігання файлів.

Вільне місце диска, проте, включає в себе все фізично вільне місце - незаповнені шматки MFT-зони туди теж включаються. Механізм використання MFT-зони такий: коли файли вже не можна записувати в звичайний простір, MFT-зона просто скорочується (в поточних версіях операційних систем рівно в два рази), звільняючи таким чином місце для запису файлів. При звільненні місця у звичайній області MFT зона може знову розшириться. При цьому не виключена ситуація, коли в цій зоні залишилися і звичайні файли: ніякої аномалії тут немає. Що ж, система намагалася залишити її вільною, але нічого не вийшло. Життя триває ... Метафайл MFT все-таки може фрагментований, хоч це і було б небажано.

MFT і його структура

Файлова система NTFS являє собою видатне досягнення структуризації: кожен елемент системи являє собою файл - навіть службова інформація. Найголовніший файл на NTFS називається MFT, або Master File Table - загальна таблиця файлів. Саме він розміщується в MFT зоні і являє собою централізований каталог всіх інших файлів диска, і, хоч як це парадоксально, себе самого. MFT поділений на записи фіксованого розміру (зазвичай 1 Кбайт), і кожна запис відповідає якому або файлу (в загальному розумінні цього слова). Перші 16 файлів носять службовий характер і недоступні операційній системі - вони називаються метафайлами, причому найперший метафайл - сам MFT. Ці перші 16 елементів MFT - єдина частина диска, що має фіксоване положення. Цікаво, що друга копія перших трьох записів, для надійності - вони дуже важливі - зберігається рівно посередині диска. Решта MFT-файл може розташовуватися, як і будь-який інший файл, в довільних місцях диска - відновити його положення можна за допомогою його самого, «зачепившись» за саму основу - за перший елемент MFT.

метафайли

Перші 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, то використовуються декілька, причому не обов'язково підряд.
• Опціональний елемент - потоки даних файлу. Може здатися дивним визначення «опціональний», але, тим не менш, нічого дивного тут немає. По-перше, файл може не мати даних - в такому випадку на нього не витрачається вільне місце самого диска. По-друге, файл може мати не дуже великий розмір. Тоді йде в хід досить вдале рішення: дані файлу зберігаються прямо в MFT, в що залишився від основних даних місці в межах одного запису MFT. Файли, що займають сотні байт, зазвичай не мають свого «фізичного» втілення в основний файлової області - всі дані такого файлу зберігаються в одному місці - в MFT.

Досить цікаво йде справа і з даними файлу. Кожен файл на NTFS, в общем-то, має кілька абстрактне будову - у нього немає як таких даних, а є потоки (streams). Один з потоків і носить звичний нам сенс - дані файлу. Але більшість атрибутів файлу - теж потоки! Таким чином, виходить, що базова сутність у файлу тільки одна - номер в MFT, а все інше опціонально. Дана абстракція може використовуватися для створення досить зручних речей - наприклад, файлу можна «приліпити» ще один потік, записавши в нього будь-які дані - наприклад, інформацію про автора і зміст файлу, як це зроблено в Windows 2000 (сама права закладка у властивостях файлу, переглядаються з провідника). Цікаво, що ці додаткові потоки не видно стандартними засобами: спостережуваний розмір файлу - це лише розмір основного потоку, який містить традиційні дані. Можна, наприклад, мати файл нульової довжини, при стирання якого звільниться 1 Гбайт вільного місця - просто тому, що якась хитра програма або технологія приліпила в нього додатковий потік (альтернативні дані) гигабайтового розміру. Але насправді в поточний момент потоки практично не використовуються, так що побоюватися подібних ситуацій не слід, хоча гіпотетично вони можливі. Просто майте на увазі, що файл на NTFS - це більш глибоке і глобальне поняття, ніж можна собі уявити просто переглядаючи каталоги диска. Ну і наостанок: ім'я файлу може містити будь-які символи, включаючи порожній набір національних алфавітів, так як дані представлені в Unicode - 16-бітному поданні, яке дає 65535 різних символів. Максимальна довжина імені файлу - 255 символів.

Каталоги

Каталог на NTFS є специфічний файл, який зберігає посилання на інші файли і каталоги, створюючи ієрархічну будову даних на диску. Файл каталогу поділений на блоки, кожен з яких містить ім'я файлу, базові атрибути і посилання на елемент MFT, який вже надає повну інформацію про елемент каталогу. Внутрішня структура каталогу є бінарне дерево. Ось що це означає: для пошуку файлу з такою назвою в лінійному каталозі, такому, наприклад, як у FAT-а, операційній системі доводиться переглядати всі елементи каталогу, поки вона не знайде потрібний. Бінарне ж дерево має в своєму розпорядженні імена файлів таким чином, щоб пошук файлу здійснювався більш швидким способом - за допомогою отримання двозначних відповідей на питання про становище файлу. Питання, на який бінарне дерево здатне дати відповідь, такий: в якій групі, щодо даного елемента, знаходиться шукане ім'я - вище або нижче? Ми починаємо з такого питання до середнього елементу, і кожен відповідь звужує зону пошуку в середньому в два рази. Файли, скажімо, просто відсортовані за алфавітом, і відповідь на питання здійснюється очевидним способом - порівнянням початкових букв. Область пошуку, звужена в два рази, починає досліджуватися аналогічним чином, починаючи знову ж зі середнього елемента.

Висновок - для пошуку одного файлу серед 1000, наприклад, FAT доведеться здійснити в середньому 500 порівнянь (найбільш імовірно, що файл буде знайдений на середині пошуку), а системі на основі дерева - всього близько 12-ти (2 ^ 10 = 1024). Економія часу пошуку в наявності. Не варто, однак думати, що в традиційних системах (FAT) все так запущено: по-перше, підтримку списку файлів у вигляді бінарного дерева досить трудомістким, а по-друге - навіть FAT у виконанні сучасної системи (Windows2000 або Windows98) використовує подібну оптимізацію пошуку. Це просто ще один факт в вашу скарбничку знань. Хочеться також розвіяти поширена помилка (яке я сам розділяв зовсім ще недавно) про те, що додавати файл в каталог у вигляді дерева важче, ніж в лінійний каталог: це досить порівнянні за часом операції - справа в тому, що для того, щоб додати файл в каталог, потрібно спочатку переконається, що файлу з такою назвою там ще немає :) - і ось тут-то в лінійній системі у нас будуть труднощі з пошуком файлу, описані вище, які з лишком компенсують саму простоту додавання файлу в каталог.

Яку інформацію можна отримати, просто прочитавши файл каталогу? Рівно те, що видає команда dir. Для виконання найпростішої навігації по диску не потрібно лазити в MFT за кожним файлом, треба лише читати саму загальну інформацію про файлах з файлів каталогів. Головний каталог диска - кореневої - нічим не відрізняється про звичайні каталогів, крім спеціального посилання на нього з початку метафайлу MFT.

журнал

NTFS - відмовостійка система, яка цілком може привести себе в коректне стан при практично будь-яких реальних збої. Будь-яка сучасна файлова система заснована на такому понятті, як транзакція - дія, що здійснюється цілком і коректно або не робити взагалі. У NTFS просто не буває проміжних (помилкових чи некоректних) станів - квант зміни даних не може бути поділений на до і після збою, приносячи руйнування і плутанину - він або здійснений, або скасований.

Приклад 1: здійснюється запис даних на диск. Раптом з'ясовується, що в те місце, куди ми тільки що вирішили записати чергову порцію даних, писати не вдалося - фізичне пошкодження поверхні. Поведінка NTFS в цьому випадку досить логічно: транзакція запису відкочується цілком - система усвідомлює, що запис Нічого не зроблено. Місце позначаються як збійні, а дані записуються в інше місце - починається нова транзакція.

Приклад 2: більш складний випадок - йде запис даних на диск. Раптом, бах - відключається харчування та система перезавантажується. На якій фазі зупинилася запис, де є дані, а де чушь? На допомогу приходить інший механізм системи - журнал транзакцій. Справа в тому, що система, усвідомивши своє бажання писати на диск, позначила в метафайлі $ LogFile це свій стан. При перезавантаженні це файл вивчається на предмет наявності незавершених транзакцій, які були перервані аварією і результат яких непередбачуваний - всі ці транзакції скасовуються: місце, в яке здійснювалася запис, позначається знову як вільне, індекси і елементи MFT наводяться в с стан, в якому вони були до збою, і система в цілому залишається стабільною. Ну а якщо помилка сталася під час запису в журнал? Теж нічого страшного: транзакція або ще й не починалася (йде тільки спроба записати наміри її зробити), або вже закінчилася - тобто йде спроба записати, що транзакція насправді вже виконана. В останньому випадку при наступному завантаженні система сама цілком розбереться, що насправді все і так записано коректно, і не зверне уваги на «незакінчену» транзакцію.

І все-таки пам'ятайте, що журнал - не абсолютна панацея, а лише засіб істотно скоротити число помилок і збоїв системи. Навряд чи пересічний користувач NTFS хоч коли-небудь помітить помилку системи або змушений буде запускати chkdsk - досвід показує, що NTFS відновлюється в повністю коректне стан навіть при збоях в дуже завантажені дискової активністю моменти. Ви можете навіть оптимізувати диск і в самий розпал цього процесу натиснути reset - ймовірність втрат даних навіть в цьому випадку буде дуже низька. Важливо розуміти, однак, що система відновлення NTFS гарантує коректність файлової системи, а не ваших даних. Якщо ви проводили запис на диск і отримали аварію - ваші дані можуть і не записатися. Чудес не буває.

стиснення

Файли NTFS мають один досить корисний атрибут - "стиснутий». Справа в тому, що NTFS має вбудовану підтримку стиснення дисків - то, для чого раніше доводилося використовувати Stacker або DoubleSpace. Будь-який файл або каталог у індивідуальному порядку може зберігається на диску в стислому вигляді - цей процес абсолютно прозорий для додатків. Стиснення файлів має дуже високу швидкість і тільки одне велике негативне властивість - величезна віртуальна фрагментація стислих файлів, яка, правда, нікому особливо не заважає. Стиснення здійснюється блоками по 16 кластерів і використовує так звані «віртуальні кластери» - знову ж гранично гнучке рішення, що дозволяє домогтися цікавих ефектів - наприклад, половина файлу може бути стиснута, а половина - ні. Це досягається завдяки тому, що зберігання інформації про компрессирования певних фрагментів дуже схоже на звичайну фрагментацію файлів: наприклад, типова запис фізичної розкладки для реального, нестисненого, файлу:

кластери файлу з 1 по 43-й зберігаються у кластерах диска починаючи з 400-го

кластери файлу з 44 по 52-й зберігаються у кластерах диска починаючи з 8530-го ...

Фізична розкладка типового стисненого файлу:

кластери файлу з 1 по 9-й зберігаються у кластерах диска починаючи з 400-го

кластери файлу з 10 по 16-й ніде не зберігаються

кластери файлу з 17 по 18-й зберігаються у кластерах диска починаючи з 409-го

кластери файлу з 19 по 36-й ніде не зберігаються

Видно, що стиснений файл має "віртуальні" кластери, реальної інформації в яких немає. Як тільки система бачить такі віртуальні кластери, вона тут же розуміє, що дані попереднього блоку, кратного 16-ти, повинні бути розтиснену, а отримані дані як раз заповнять віртуальні кластери - ось, по суті, і весь алгоритм.

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

Частина 1. Фізична структура NTFS

Почнемо з загальних фактів. Розділ NTFS, теоретично, може бути майже будь-якого розміру. Межа, звичайно, є, але я навіть не буду вказувати його, так як його з запасом вистачить на наступні сто років розвитку обчислювальної техніки - при будь-яких темпах зростання. Як справи з цим справа на практиці? Майже так само. Максимальний розмір розділу NTFS в даний момент обмежений лише розмірами жорстких дисків. NT4, щоправда, буде мати проблеми при спробі установки на розділ, якщо хоч якась його частина відступає більш ніж на 8 Гб від фізичного початку диска, але ця проблема стосується лише завантажувального розділу.

Метод інсталяції NT4.0 на порожній диск досить оригінальний і може навести на неправильні думки про можливості NTFS. Якщо ви вкажете програмі установки, що бажаєте відформатувати диск в NTFS, максимальний розмір, який вона вам запропонує, буде всього 4 Гб. Чому так мало, якщо розмір розділу NTFS насправді практично необмежений? Справа в тому, що установча секція просто не знає цієї файлової системи :) Програма установки форматує цей диск у звичайний FAT, максимальний розмір якого в NT становить 4 Гбайт (з використанням не зовсім стандартного величезного кластеру 64 Кбайта), і на цей FAT встановлює NT . А ось вже в процесі першого завантаження самої операційної системи (ще в настановної фазі) проводиться швидке перетворення розділу в NTFS; так що користувач нічого і не помічає, крім дивного «обмеження» на розмір NTFS при установці. :)

Структура розділу - загальний погляд

Як і будь-яка інша система, NTFS ділить все корисне місце на кластери - блоки даних, що використовуються одноразово. NTFS підтримує майже будь-які розміри кластерів - від 512 байт до 64 Кбайт, певним стандартом ж вважається кластер розміром 4 Кбайт. Ніяких аномалій кластерної структури NTFS не має, тому на цю, загалом-то, досить банальну тему, сказати особливо нічого.

Диск NTFS умовно ділиться на дві частини. Перші 12% диска відводяться під так звану MFT зону - простір, в яке росте метафайл MFT (про це нижче). Запис будь-яких даних в цю область неможлива. MFT-зона завжди тримається порожньою - це робиться для того, щоб найголовніший, службовий файл (MFT) НЕ фрагментованих при своєму зростанні. Решта 88% диска є звичайне простір для зберігання файлів.

Вільне місце диска, проте, включає в себе все фізично вільне місце - незаповнені шматки MFT-зони туди теж включаються. Механізм використання MFT-зони такий: коли файли вже не можна записувати в звичайний простір, MFT-зона просто скорочується (в поточних версіях операційних систем рівно в два рази), звільняючи таким чином місце для запису файлів. При звільненні місця у звичайній області MFT зона може знову розшириться. При цьому не виключена ситуація, коли в цій зоні залишилися і звичайні файли: ніякої аномалії тут немає. Що ж, система намагалася залишити її вільною, але нічого не вийшло. Життя триває ... Метафайл MFT все-таки може фрагментований, хоч це і було б небажано.

MFT і його структура

Файлова система NTFS являє собою видатне досягнення структуризації: кожен елемент системи являє собою файл - навіть службова інформація. Найголовніший файл на NTFS називається MFT, або Master File Table - загальна таблиця файлів. Саме він розміщується в MFT зоні і являє собою централізований каталог всіх інших файлів диска, і, хоч як це парадоксально, себе самого. MFT поділений на записи фіксованого розміру (зазвичай 1 Кбайт), і кожна запис відповідає якому або файлу (в загальному розумінні цього слова). Перші 16 файлів носять службовий характер і недоступні операційній системі - вони називаються метафайлами, причому найперший метафайл - сам MFT. Ці перші 16 елементів MFT - єдина частина диска, що має фіксоване положення. Цікаво, що друга копія перших трьох записів, для надійності - вони дуже важливі - зберігається рівно посередині диска. Решта MFT-файл може розташовуватися, як і будь-який інший файл, в довільних місцях диска - відновити його положення можна за допомогою його самого, «зачепившись» за саму основу - за перший елемент MFT.

метафайли

Перші 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, то використовуються декілька, причому не обов'язково підряд.
• Опціональний елемент - потоки даних файлу. Може здатися дивним визначення «опціональний», але, тим не менш, нічого дивного тут немає. По-перше, файл може не мати даних - в такому випадку на нього не витрачається вільне місце самого диска. По-друге, файл може мати не дуже великий розмір. Тоді йде в хід досить вдале рішення: дані файлу зберігаються прямо в MFT, в що залишився від основних даних місці в межах одного запису MFT. Файли, що займають сотні байт, зазвичай не мають свого «фізичного» втілення в основний файлової області - всі дані такого файлу зберігаються в одному місці - в MFT.

Досить цікаво йде справа і з даними файлу. Кожен файл на NTFS, в общем-то, має кілька абстрактне будову - у нього немає як таких даних, а є потоки (streams). Один з потоків і носить звичний нам сенс - дані файлу. Але більшість атрибутів файлу - теж потоки! Таким чином, виходить, що базова сутність у файлу тільки одна - номер в MFT, а все інше опціонально. Дана абстракція може використовуватися для створення досить зручних речей - наприклад, файлу можна «приліпити» ще один потік, записавши в нього будь-які дані - наприклад, інформацію про автора і зміст файлу, як це зроблено в Windows 2000 (сама права закладка у властивостях файлу, переглядаються з провідника). Цікаво, що ці додаткові потоки не видно стандартними засобами: спостережуваний розмір файлу - це лише розмір основного потоку, який містить традиційні дані. Можна, наприклад, мати файл нульової довжини, при стирання якого звільниться 1 Гбайт вільного місця - просто тому, що якась хитра програма або технологія приліпила в нього додатковий потік (альтернативні дані) гигабайтового розміру. Але насправді в поточний момент потоки практично не використовуються, так що побоюватися подібних ситуацій не слід, хоча гіпотетично вони можливі. Просто майте на увазі, що файл на NTFS - це більш глибоке і глобальне поняття, ніж можна собі уявити просто переглядаючи каталоги диска. Ну і наостанок: ім'я файлу може містити будь-які символи, включаючи порожній набір національних алфавітів, так як дані представлені в Unicode - 16-бітному поданні, яке дає 65535 різних символів. Максимальна довжина імені файлу - 255 символів.

Каталоги

Каталог на NTFS є специфічний файл, який зберігає посилання на інші файли і каталоги, створюючи ієрархічну будову даних на диску. Файл каталогу поділений на блоки, кожен з яких містить ім'я файлу, базові атрибути і посилання на елемент MFT, який вже надає повну інформацію про елемент каталогу. Внутрішня структура каталогу є бінарне дерево. Ось що це означає: для пошуку файлу з такою назвою в лінійному каталозі, такому, наприклад, як у FAT-а, операційній системі доводиться переглядати всі елементи каталогу, поки вона не знайде потрібний. Бінарне ж дерево має в своєму розпорядженні імена файлів таким чином, щоб пошук файлу здійснювався більш швидким способом - за допомогою отримання двозначних відповідей на питання про становище файлу. Питання, на який бінарне дерево здатне дати відповідь, такий: в якій групі, щодо даного елемента, знаходиться шукане ім'я - вище або нижче? Ми починаємо з такого питання до середнього елементу, і кожен відповідь звужує зону пошуку в середньому в два рази. Файли, скажімо, просто відсортовані за алфавітом, і відповідь на питання здійснюється очевидним способом - порівнянням початкових букв. Область пошуку, звужена в два рази, починає досліджуватися аналогічним чином, починаючи знову ж зі середнього елемента.

Висновок - для пошуку одного файлу серед 1000, наприклад, FAT доведеться здійснити в середньому 500 порівнянь (найбільш імовірно, що файл буде знайдений на середині пошуку), а системі на основі дерева - всього близько 12-ти (2 ^ 10 = 1024). Економія часу пошуку в наявності. Не варто, однак думати, що в традиційних системах (FAT) все так запущено: по-перше, підтримку списку файлів у вигляді бінарного дерева досить трудомістким, а по-друге - навіть FAT у виконанні сучасної системи (Windows2000 або Windows98) використовує подібну оптимізацію пошуку. Це просто ще один факт в вашу скарбничку знань. Хочеться також розвіяти поширена помилка (яке я сам розділяв зовсім ще недавно) про те, що додавати файл в каталог у вигляді дерева важче, ніж в лінійний каталог: це досить порівнянні за часом операції - справа в тому, що для того, щоб додати файл в каталог, потрібно спочатку переконається, що файлу з такою назвою там ще немає :) - і ось тут-то в лінійній системі у нас будуть труднощі з пошуком файлу, описані вище, які з лишком компенсують саму простоту додавання файлу в каталог.

Яку інформацію можна отримати, просто прочитавши файл каталогу? Рівно те, що видає команда dir. Для виконання найпростішої навігації по диску не потрібно лазити в MFT за кожним файлом, треба лише читати саму загальну інформацію про файлах з файлів каталогів. Головний каталог диска - кореневої - нічим не відрізняється про звичайні каталогів, крім спеціального посилання на нього з початку метафайлу MFT.

журнал

NTFS - відмовостійка система, яка цілком може привести себе в коректне стан при практично будь-яких реальних збої. Будь-яка сучасна файлова система заснована на такому понятті, як транзакція - дія, що здійснюється цілком і коректно або не робити взагалі. У NTFS просто не буває проміжних (помилкових чи некоректних) станів - квант зміни даних не може бути поділений на до і після збою, приносячи руйнування і плутанину - він або здійснений, або скасований.

Приклад 1: здійснюється запис даних на диск. Раптом з'ясовується, що в те місце, куди ми тільки що вирішили записати чергову порцію даних, писати не вдалося - фізичне пошкодження поверхні. Поведінка NTFS в цьому випадку досить логічно: транзакція запису відкочується цілком - система усвідомлює, що запис Нічого не зроблено. Місце позначаються як збійні, а дані записуються в інше місце - починається нова транзакція.

Приклад 2: більш складний випадок - йде запис даних на диск. Раптом, бах - відключається харчування та система перезавантажується. На якій фазі зупинилася запис, де є дані, а де чушь? На допомогу приходить інший механізм системи - журнал транзакцій. Справа в тому, що система, усвідомивши своє бажання писати на диск, позначила в метафайлі $ LogFile це свій стан. При перезавантаженні це файл вивчається на предмет наявності незавершених транзакцій, які були перервані аварією і результат яких непередбачуваний - всі ці транзакції скасовуються: місце, в яке здійснювалася запис, позначається знову як вільне, індекси і елементи MFT наводяться в с стан, в якому вони були до збою, і система в цілому залишається стабільною. Ну а якщо помилка сталася під час запису в журнал? Теж нічого страшного: транзакція або ще й не починалася (йде тільки спроба записати наміри її зробити), або вже закінчилася - тобто йде спроба записати, що транзакція насправді вже виконана. В останньому випадку при наступному завантаженні система сама цілком розбереться, що насправді все і так записано коректно, і не зверне уваги на «незакінчену» транзакцію.

І все-таки пам'ятайте, що журнал - не абсолютна панацея, а лише засіб істотно скоротити число помилок і збоїв системи. Навряд чи пересічний користувач NTFS хоч коли-небудь помітить помилку системи або змушений буде запускати chkdsk - досвід показує, що NTFS відновлюється в повністю коректне стан навіть при збоях в дуже завантажені дискової активністю моменти. Ви можете навіть оптимізувати диск і в самий розпал цього процесу натиснути reset - ймовірність втрат даних навіть в цьому випадку буде дуже низька. Важливо розуміти, однак, що система відновлення NTFS гарантує коректність файлової системи, а не ваших даних. Якщо ви проводили запис на диск і отримали аварію - ваші дані можуть і не записатися. Чудес не буває.

стиснення

Файли NTFS мають один досить корисний атрибут - "стиснутий». Справа в тому, що NTFS має вбудовану підтримку стиснення дисків - то, для чого раніше доводилося використовувати Stacker або DoubleSpace. Будь-який файл або каталог у індивідуальному порядку може зберігається на диску в стислому вигляді - цей процес абсолютно прозорий для додатків. Стиснення файлів має дуже високу швидкість і тільки одне велике негативне властивість - величезна віртуальна фрагментація стислих файлів, яка, правда, нікому особливо не заважає. Стиснення здійснюється блоками по 16 кластерів і використовує так звані «віртуальні кластери» - знову ж гранично гнучке рішення, що дозволяє домогтися цікавих ефектів - наприклад, половина файлу може бути стиснута, а половина - ні. Це досягається завдяки тому, що зберігання інформації про компрессирования певних фрагментів дуже схоже на звичайну фрагментацію файлів: наприклад, типова запис фізичної розкладки для реального, нестисненого, файлу:

кластери файлу з 1 по 43-й зберігаються у кластерах диска починаючи з 400-го

кластери файлу з 44 по 52-й зберігаються у кластерах диска починаючи з 8530-го ...

Фізична розкладка типового стисненого файлу:

кластери файлу з 1 по 9-й зберігаються у кластерах диска починаючи з 400-го

кластери файлу з 10 по 16-й ніде не зберігаються

кластери файлу з 17 по 18-й зберігаються у кластерах диска починаючи з 409-го

кластери файлу з 19 по 36-й ніде не зберігаються

Видно, що стиснений файл має "віртуальні" кластери, реальної інформації в яких немає. Як тільки система бачить такі віртуальні кластери, вона тут же розуміє, що дані попереднього блоку, кратного 16-ти, повинні бути розтиснену, а отримані дані як раз заповнять віртуальні кластери - ось, по суті, і весь алгоритм.

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

Частина 1. Фізична структура NTFS

Почнемо з загальних фактів. Розділ NTFS, теоретично, може бути майже будь-якого розміру. Межа, звичайно, є, але я навіть не буду вказувати його, так як його з запасом вистачить на наступні сто років розвитку обчислювальної техніки - при будь-яких темпах зростання. Як справи з цим справа на практиці? Майже так само. Максимальний розмір розділу NTFS в даний момент обмежений лише розмірами жорстких дисків. NT4, щоправда, буде мати проблеми при спробі установки на розділ, якщо хоч якась його частина відступає більш ніж на 8 Гб від фізичного початку диска, але ця проблема стосується лише завантажувального розділу.

Метод інсталяції NT4.0 на порожній диск досить оригінальний і може навести на неправильні думки про можливості NTFS. Якщо ви вкажете програмі установки, що бажаєте відформатувати диск в NTFS, максимальний розмір, який вона вам запропонує, буде всього 4 Гб. Чому так мало, якщо розмір розділу NTFS насправді практично необмежений? Справа в тому, що установча секція просто не знає цієї файлової системи :) Програма установки форматує цей диск у звичайний FAT, максимальний розмір якого в NT становить 4 Гбайт (з використанням не зовсім стандартного величезного кластеру 64 Кбайта), і на цей FAT встановлює NT . А ось вже в процесі першого завантаження самої операційної системи (ще в настановної фазі) проводиться швидке перетворення розділу в NTFS; так що користувач нічого і не помічає, крім дивного «обмеження» на розмір NTFS при установці. :)

Структура розділу - загальний погляд

Як і будь-яка інша система, NTFS ділить все корисне місце на кластери - блоки даних, що використовуються одноразово. NTFS підтримує майже будь-які розміри кластерів - від 512 байт до 64 Кбайт, певним стандартом ж вважається кластер розміром 4 Кбайт. Ніяких аномалій кластерної структури NTFS не має, тому на цю, загалом-то, досить банальну тему, сказати особливо нічого.

Диск NTFS умовно ділиться на дві частини. Перші 12% диска відводяться під так звану MFT зону - простір, в яке росте метафайл MFT (про це нижче). Запис будь-яких даних в цю область неможлива. MFT-зона завжди тримається порожньою - це робиться для того, щоб найголовніший, службовий файл (MFT) НЕ фрагментованих при своєму зростанні. Решта 88% диска є звичайне простір для зберігання файлів.

Вільне місце диска, проте, включає в себе все фізично вільне місце - незаповнені шматки MFT-зони туди теж включаються. Механізм використання MFT-зони такий: коли файли вже не можна записувати в звичайний простір, MFT-зона просто скорочується (в поточних версіях операційних систем рівно в два рази), звільняючи таким чином місце для запису файлів. При звільненні місця у звичайній області MFT зона може знову розшириться. При цьому не виключена ситуація, коли в цій зоні залишилися і звичайні файли: ніякої аномалії тут немає. Що ж, система намагалася залишити її вільною, але нічого не вийшло. Життя триває ... Метафайл MFT все-таки може фрагментований, хоч це і було б небажано.

MFT і його структура

Файлова система NTFS являє собою видатне досягнення структуризації: кожен елемент системи являє собою файл - навіть службова інформація. Найголовніший файл на NTFS називається MFT, або Master File Table - загальна таблиця файлів. Саме він розміщується в MFT зоні і являє собою централізований каталог всіх інших файлів диска, і, хоч як це парадоксально, себе самого. MFT поділений на записи фіксованого розміру (зазвичай 1 Кбайт), і кожна запис відповідає якому або файлу (в загальному розумінні цього слова). Перші 16 файлів носять службовий характер і недоступні операційній системі - вони називаються метафайлами, причому найперший метафайл - сам MFT. Ці перші 16 елементів MFT - єдина частина диска, що має фіксоване положення. Цікаво, що друга копія перших трьох записів, для надійності - вони дуже важливі - зберігається рівно посередині диска. Решта MFT-файл може розташовуватися, як і будь-який інший файл, в довільних місцях диска - відновити його положення можна за допомогою його самого, «зачепившись» за саму основу - за перший елемент MFT.

метафайли

Перші 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, то використовуються декілька, причому не обов'язково підряд.
• Опціональний елемент - потоки даних файлу. Може здатися дивним визначення «опціональний», але, тим не менш, нічого дивного тут немає. По-перше, файл може не мати даних - в такому випадку на нього не витрачається вільне місце самого диска. По-друге, файл може мати не дуже великий розмір. Тоді йде в хід досить вдале рішення: дані файлу зберігаються прямо в MFT, в що залишився від основних даних місці в межах одного запису MFT. Файли, що займають сотні байт, зазвичай не мають свого «фізичного» втілення в основний файлової області - всі дані такого файлу зберігаються в одному місці - в MFT.

Досить цікаво йде справа і з даними файлу. Кожен файл на NTFS, в общем-то, має кілька абстрактне будову - у нього немає як таких даних, а є потоки (streams). Один з потоків і носить звичний нам сенс - дані файлу. Але більшість атрибутів файлу - теж потоки! Таким чином, виходить, що базова сутність у файлу тільки одна - номер в MFT, а все інше опціонально. Дана абстракція може використовуватися для створення досить зручних речей - наприклад, файлу можна «приліпити» ще один потік, записавши в нього будь-які дані - наприклад, інформацію про автора і зміст файлу, як це зроблено в Windows 2000 (сама права закладка у властивостях файлу, переглядаються з провідника). Цікаво, що ці додаткові потоки не видно стандартними засобами: спостережуваний розмір файлу - це лише розмір основного потоку, який містить традиційні дані. Можна, наприклад, мати файл нульової довжини, при стирання якого звільниться 1 Гбайт вільного місця - просто тому, що якась хитра програма або технологія приліпила в нього додатковий потік (альтернативні дані) гигабайтового розміру. Але насправді в поточний момент потоки практично не використовуються, так що побоюватися подібних ситуацій не слід, хоча гіпотетично вони можливі. Просто майте на увазі, що файл на NTFS - це більш глибоке і глобальне поняття, ніж можна собі уявити просто переглядаючи каталоги диска. Ну і наостанок: ім'я файлу може містити будь-які символи, включаючи порожній набір національних алфавітів, так як дані представлені в Unicode - 16-бітному поданні, яке дає 65535 різних символів. Максимальна довжина імені файлу - 255 символів.

Каталоги

Каталог на NTFS є специфічний файл, який зберігає посилання на інші файли і каталоги, створюючи ієрархічну будову даних на диску. Файл каталогу поділений на блоки, кожен з яких містить ім'я файлу, базові атрибути і посилання на елемент MFT, який вже надає повну інформацію про елемент каталогу. Внутрішня структура каталогу є бінарне дерево. Ось що це означає: для пошуку файлу з такою назвою в лінійному каталозі, такому, наприклад, як у FAT-а, операційній системі доводиться переглядати всі елементи каталогу, поки вона не знайде потрібний. Бінарне ж дерево має в своєму розпорядженні імена файлів таким чином, щоб пошук файлу здійснювався більш швидким способом - за допомогою отримання двозначних відповідей на питання про становище файлу. Питання, на який бінарне дерево здатне дати відповідь, такий: в якій групі, щодо даного елемента, знаходиться шукане ім'я - вище або нижче? Ми починаємо з такого питання до середнього елементу, і кожен відповідь звужує зону пошуку в середньому в два рази. Файли, скажімо, просто відсортовані за алфавітом, і відповідь на питання здійснюється очевидним способом - порівнянням початкових букв. Область пошуку, звужена в два рази, починає досліджуватися аналогічним чином, починаючи знову ж зі середнього елемента.

Висновок - для пошуку одного файлу серед 1000, наприклад, FAT доведеться здійснити в середньому 500 порівнянь (найбільш імовірно, що файл буде знайдений на середині пошуку), а системі на основі дерева - всього близько 12-ти (2 ^ 10 = 1024). Економія часу пошуку в наявності. Не варто, однак думати, що в традиційних системах (FAT) все так запущено: по-перше, підтримку списку файлів у вигляді бінарного дерева досить трудомістким, а по-друге - навіть FAT у виконанні сучасної системи (Windows2000 або Windows98) використовує подібну оптимізацію пошуку. Це просто ще один факт в вашу скарбничку знань. Хочеться також розвіяти поширена помилка (яке я сам розділяв зовсім ще недавно) про те, що додавати файл в каталог у вигляді дерева важче, ніж в лінійний каталог: це досить порівнянні за часом операції - справа в тому, що для того, щоб додати файл в каталог, потрібно спочатку переконається, що файлу з такою назвою там ще немає :) - і ось тут-то в лінійній системі у нас будуть труднощі з пошуком файлу, описані вище, які з лишком компенсують саму простоту додавання файлу в каталог.

Яку інформацію можна отримати, просто прочитавши файл каталогу? Рівно те, що видає команда dir. Для виконання найпростішої навігації по диску не потрібно лазити в MFT за кожним файлом, треба лише читати саму загальну інформацію про файлах з файлів каталогів. Головний каталог диска - кореневої - нічим не відрізняється про звичайні каталогів, крім спеціального посилання на нього з початку метафайлу MFT.

журнал

NTFS - відмовостійка система, яка цілком може привести себе в коректне стан при практично будь-яких реальних збої. Будь-яка сучасна файлова система заснована на такому понятті, як транзакція - дія, що здійснюється цілком і коректно або не робити взагалі. У NTFS просто не буває проміжних (помилкових чи некоректних) станів - квант зміни даних не може бути поділений на до і після збою, приносячи руйнування і плутанину - він або здійснений, або скасований.

Приклад 1: здійснюється запис даних на диск. Раптом з'ясовується, що в те місце, куди ми тільки що вирішили записати чергову порцію даних, писати не вдалося - фізичне пошкодження поверхні. Поведінка NTFS в цьому випадку досить логічно: транзакція запису відкочується цілком - система усвідомлює, що запис Нічого не зроблено. Місце позначаються як збійні, а дані записуються в інше місце - починається нова транзакція.

Приклад 2: більш складний випадок - йде запис даних на диск. Раптом, бах - відключається харчування та система перезавантажується. На якій фазі зупинилася запис, де є дані, а де чушь? На допомогу приходить інший механізм системи - журнал транзакцій. Справа в тому, що система, усвідомивши своє бажання писати на диск, позначила в метафайлі $ LogFile це свій стан. При перезавантаженні це файл вивчається на предмет наявності незавершених транзакцій, які були перервані аварією і результат яких непередбачуваний - всі ці транзакції скасовуються: місце, в яке здійснювалася запис, позначається знову як вільне, індекси і елементи MFT наводяться в с стан, в якому вони були до збою, і система в цілому залишається стабільною. Ну а якщо помилка сталася під час запису в журнал? Теж нічого страшного: транзакція або ще й не починалася (йде тільки спроба записати наміри її зробити), або вже закінчилася - тобто йде спроба записати, що транзакція насправді вже виконана. В останньому випадку при наступному завантаженні система сама цілком розбереться, що насправді все і так записано коректно, і не зверне уваги на «незакінчену» транзакцію.

І все-таки пам'ятайте, що журнал - не абсолютна панацея, а лише засіб істотно скоротити число помилок і збоїв системи. Навряд чи пересічний користувач NTFS хоч коли-небудь помітить помилку системи або змушений буде запускати chkdsk - досвід показує, що NTFS відновлюється в повністю коректне стан навіть при збоях в дуже завантажені дискової активністю моменти. Ви можете навіть оптимізувати диск і в самий розпал цього процесу натиснути reset - ймовірність втрат даних навіть в цьому випадку буде дуже низька. Важливо розуміти, однак, що система відновлення NTFS гарантує коректність файлової системи, а не ваших даних. Якщо ви проводили запис на диск і отримали аварію - ваші дані можуть і не записатися. Чудес не буває.

стиснення

Файли NTFS мають один досить корисний атрибут - "стиснутий». Справа в тому, що NTFS має вбудовану підтримку стиснення дисків - то, для чого раніше доводилося використовувати Stacker або DoubleSpace. Будь-який файл або каталог у індивідуальному порядку може зберігається на диску в стислому вигляді - цей процес абсолютно прозорий для додатків. Стиснення файлів має дуже високу швидкість і тільки одне велике негативне властивість - величезна віртуальна фрагментація стислих файлів, яка, правда, нікому особливо не заважає. Стиснення здійснюється блоками по 16 кластерів і використовує так звані «віртуальні кластери» - знову ж гранично гнучке рішення, що дозволяє домогтися цікавих ефектів - наприклад, половина файлу може бути стиснута, а половина - ні. Це досягається завдяки тому, що зберігання інформації про компрессирования певних фрагментів дуже схоже на звичайну фрагментацію файлів: наприклад, типова запис фізичної розкладки для реального, нестисненого, файлу:

кластери файлу з 1 по 43-й зберігаються у кластерах диска починаючи з 400-го

кластери файлу з 44 по 52-й зберігаються у кластерах диска починаючи з 8530-го ...

Фізична розкладка типового стисненого файлу:

кластери файлу з 1 по 9-й зберігаються у кластерах диска починаючи з 400-го

кластери файлу з 10 по 16-й ніде не зберігаються

кластери файлу з 17 по 18-й зберігаються у кластерах диска починаючи з 409-го

кластери файлу з 19 по 36-й ніде не зберігаються

Видно, що стиснений файл має "віртуальні" кластери, реальної інформації в яких немає. Як тільки система бачить такі віртуальні кластери, вона тут же розуміє, що дані попереднього блоку, кратного 16-ти, повинні бути розтиснену, а отримані дані як раз заповнять віртуальні кластери - ось, по суті, і весь алгоритм.

Безпека

NTFS містіть безліч ЗАСОБІВ розмежування прав об'єктів - є думка, что це найдосконаліша файлової системи з усіх ніні існуючіх. У теорії це, без сумніву, так, але в поточних реалізаціях, на жаль, система прав достатньо далека від ідеалу і являє собою хоч і жорсткий, але не завжди логічний набір характеристик. Права, що призначаються будь-якого об'єкта і однозначно дотримувані системою, еволюціонують - великі зміни і доповнення прав здійснювалися вже кілька разів і до Windows 2000 все-таки вони прийшли до досить розумному набору.

Права файлової системи NTFS нерозривно пов'язані з самою системою - тобто вони, взагалі кажучи, не є обов'язковими до дотримання іншою системою, якщо їй дати фізичний доступ до диску. Для запобігання фізичного доступу в Windows2000 (NT5) все ж ввели стандартну можливість - про це див. Нижче. Система прав в свій поточний стан досить складна, і я сумніваюся, що зможу сказати широкому читачеві що-небудь цікаве і корисне йому в звичайному житті. Якщо вас цікавить ця тема - ви знайдете безліч книг по мережевій архітектурі NT, в яких це описано більш ніж докладно.

На цьому опис будова файлової системи можна закінчити, залишилося описати лише кілька просто практичних або оригінальних речей.

Hard Links

Ця штука була в NTFS з незапам'ятних часів, але використовувалася дуже рідко - і тим не менше: Hard Link - це коли один і той же файл має два імені (кілька покажчиків файлу-каталогу або різних каталогів вказують на одну і ту ж MFT запис) . Припустимо, один і той же файл має імена 1.txt і 2.txt: якщо користувач зітре файл 1, залишиться файл 2. Якщо зітре 2 - залишиться файл 1, тобто обидва імені, з моменту створення, абсолютно рівноправні. Файл фізично стирається лише тоді, коли буде видалено його останнім ім'я.

Symbolic Links (NT5)

Набагато більш практична можливість, що дозволяє робити віртуальні каталоги - рівно так само, як і віртуальні диски командою subst в DOSе. Застосування досить різноманітні: по-перше, спрощення системи каталогів. Якщо вам не подобається каталог Documents and settingsAdministratorDocuments, ви можете прілінкованние його в кореневий каталог - система буде як і раніше спілкуватися з каталогом з дрімучим шляхом, а ви - з набагато коротшим ім'ям, повністю йому еквівалентним. Для створення таких зв'язків можна скористатися програмою junction ( junction.zip , 15 Кб), яку написав відомий фахівець Mark Russinovich. Програма працює тільки в NT5 (Windows 2000), як і сама можливість.

Для видалення зв'язку можна скористатися стандартною командою rd.
УВАГА: Спроба приділення зв'язку за допомогою провідника або інших файлових менеджерів, які не розуміють віртуальну природу каталогу (наприклад, FAR), призведе до видалення даних, на які посилається посилання! Будьте обережні.

Шифрування (NT5)

Корисна можливість для людей, які турбуються за свої секрети - кожен файл або каталог може також бути зашифрований, що не дасть можливість прочитати його інший інсталяцією NT. У поєднанні зі стандартним і практично непрошібаемая паролем на завантаження самої системи, ця можливість забезпечує достатню для більшості застосувань безпеку обраних вами важливих данних.Часть 2. Особливості дефрагментації NTFS

Повернемося до одного досить цікавого і важливого моменту - фрагментації і дефрагментації NTFS. Справа в тому, що ситуація, що склалася з цими двома поняттями зараз, ніяк не може бути названа задовільною. На самому початку стверджувалося, що NTFS не схильна до фрагментації файлів. Це виявилося не зовсім так, і твердження змінили - NTFS перешкоджає фрагментації. Виявилося, що і це не зовсім так. Тобто вона, звичайно, перешкоджає, але толк від цього близький до нуля ... Зараз вже зрозуміло, що NTFS - система, яка як ніяка інша схильна до фрагментації, що б не стверджувалося офіційно. Єдине що - логічно вона не дуже від цього страждає. Всі внутрішні структури побудовані таким чином, що фрагментація не заважає швидко знаходити фрагменти даних. Але від фізичного наслідки фрагментації - зайвих рухів головок - вона, звичайно, не рятує. І тому - вперед і з піснею.

До витоків проблеми

Як відомо, система найсильніше фрагментірует файли коли вільне місце кінчається, коли доводиться використовувати дрібні дірки, що залишилися від інших файлів. Тут виникає перша властивість NTFS, яке прямо сприяє серйозної фрагментації.

Диск NTFS поділений на дві зони. В початку диска йде MFT зона - зона, куди зростає MFT, Master File Table. Зона займає мінімум 12% диска, і запис даних в цю зону неможлива. Це зроблено для того, щоб не фрагментований хоча б MFT. Але коли увесь інший диск заповнюється - зона скорочується рівно в два рази :). І так далі. Таким чином ми маємо не один візит закінчення диска, а декілька. В результаті якщо NTFS працює при диску, заповненому на близько 90% - фрагментація росте як скажена.

Попутне наслідок - диск, заповнений більш ніж на 88%, дефрагментувати майже неможливо - навіть API дефрагментації не може переміщати дані в MFT зону. Може виявитися так, що у нас не буде вільного місця для маневру.

Далі. NTFS працює собі і працює, і все таки фрагментируется - навіть в тому випадку, якщо вільне місце далеко від виснаження. Цьому сприяє дивний алгоритм знаходження вільного місця для запису файлів - друга серйозне упущення. Алгоритм дій при будь-якому записі такий: береться якийсь певний обсяг диска і заповнюється файлом до упору. Причому по дуже цікавому алгоритму: спочатку заповнюються великі дірки, потім маленькі. Тобто типове розподіл фрагментів файлу за розміром на фрагментованою NTFS виглядає так (розміри фрагментів):

16 - 16 - 16 - 16 - 16 - [скачок назад] - 15 - 15 - 15 - [назад] - 14 - 14 - 14 .... 1 - 1 - 1 -1 - 1 ...

Так процес іде до самих дрібних дірок в 1 кластер, незважаючи на те, що на диску напевно є і набагато більш великі шматки вільного місця.

Згадайте стислі файли - при активній перезапису великих обсягів стислій інформації на NTFS утворюється гігантська кількість «дірок» через перерозподіл на диску стислих обсягів - якщо який-небудь ділянку файлу став стискатися краще або гірше, його доводиться або вилучати з безперервного ланцюжка і розміщувати в іншому місці, або стягувати в обсязі, залишаючи за собою дірку.

Сенс в цього цього вступу в поясненні того простого факту, що ніяк не можна сказати, що NTFS перешкоджає фрагментації файлів. Навпаки, вона з радістю їх фрагментірует. Фрагментація NTFS через пів року роботи доведе до щирого здивування будь-якої людини, знайомого з роботою файловою системою. Тому доводиться запускати дефрагментатор. Але на цьому всі наші проблеми не закінчуються, а, на жаль, тільки починаються.

Засоби вирішення?

В NT існує стандартне API дефрагментації. Те, що володіє цікавим обмеженням для переміщення блоків файлів: за один раз можна переміщати не менше 16 кластерів (!), Причому починатися ці кластери повинні з позиції, кратній 16 кластерам у файлі. Загалом, операція здійснюється виключно по 16 кластерів. наслідки:

1. У дірку вільного місця менше 16 кластерів не можна нічого перемістити (крім стислих файлів, але це нецікаві в даний момент тонкощі).
2. Файл, будучи переміщений в інше місце, залишає після себе (на новому місці) «тимчасово зайняте місце», яке доповнює його за розміром до кратності 16 кластерам.
3. При спробі якось неправильно ( "не кратно 16») перемістити файл результат часто непередбачуваний. Щось округляється, щось просто не переміщається ... Проте, все місце дії щедро розсипається «тимчасово зайнятим місцем».

«Тимчасово зайняте місце» служить для полегшення відновлення системи в разі апаратного збою і звільняється через деякий час, зазвичай десь пів хвилини.

Проте, логічно було б використовувати це API, раз він є. Його і використовують. Тому процес стандартної дефрагментації, з поправками на обмеженість API, складається з наступних фаз (не обов'язково в цьому порядку):

• Виймання файлів з MFT зони. Чи не спеціально - просто назад туди їх покласти не представляється можливим :) Невинна фаза, і навіть у чомусь корисна.
• Дефрагментація файлів. Безумовно, корисний процес, кілька, правда, що ускладнюється обмеженнями кратності переміщень - файли часто доводиться перекладати сильніше, ніж це було б логічно зробити по розуму.
• Дефрагментація MFT, виртуалки (pagefile.sys) і каталогів. Можлива через API тільки в Windows2000, інакше - при перезавантаженні, окремим процесом, як в старому Diskeeper-е.
• Складання файлів ближче до початку - так звана дефрагментація вільного місця. Ось це - воістину страшний процес.

Припустимо, ми хочемо покласти файли поспіль в початок диска. Кладемо один файл. Він залишає хвіст зайнятості доповнення до кратності 16. Кладемо наступний - після хвоста, природно. Через деякий час, зі звільнення хвоста, маємо дірку Таким чином, є два приблизно рівнозначних варіанту. Перший - часто оптимізувати диск таким дефрагментатором, упокорюючись при цьому з дикою фрагментацією заново створених файлів. Другий варіант - взагалі нічого не чіпати, і змиритися з рівномірною, але набагато слабшою фрагментацією всіх файлів на диску.

Поки є всього один дефрагментатор, який ігнорує API дефрагментації і працює як-то більш безпосередньо - Norton Speeddisk 5.0 для NT. Коли його намагаються порівняти з усіма іншими - Diskeeper, O & O defrag, т. Д. - не згадують цього головного, найважливішого, відмінності. Просто тому, що ця проблема ретельно ховається, принаймні вже точно не афішується на кожному кроці. Speeddisk - єдина на сьогоднішній день програма, яка може оптимізувати диск повністю, не створюючи маленьких незаповнених фрагментів вільного місця. Варто додати також, що за допомогою стандартного API неможливо дефрагментировать томи NTFS з кластером більше 4 Кбайт, а SpeedDisk і це може.

На жаль, в Windows 2000 помістили дефрагментатор, який працює через API, і, відповідно, плодить дірки Як деякий висновок з усього цього: всі інші дефрагментатори при одноразовому застосуванні просто шкідливі. Якщо ви запускали його хоч раз - потрібно запускати його потім хоча б раз на місяць, щоб позбавиться від фрагментації новопрібивающіх файлів. У цьому основна суть якої складності дефрагментації NTFS тими засобами, які склалися історіческі.Часть 3. Що вибрати?

Будь-яка з представлених нині файлових систем сягає своїм корінням в глибоке минуле - ще до 80-х років. Так, NTFS, як це не дивно - дуже стара система! Справа в тому, що довгий час персональні комп'ютери користувалися лише операційною системою DOS, якій і завдячує своєю появою FAT. Але паралельно розроблялися і тихо існували системи, націлені на майбутнє. Дві таких системи, які отримали все ж широке визнання - NTFS, створена для операційної системи Windows NT 3.1 ще в незапам'ятні часи, і HPFS - вірна супутниця OS / 2.

Впровадження нових систем йшло важко - ще в 95м році, з виходом Windows95, ні у кого не було і думок про те, що щось треба міняти - FAT отримав друге дихання за допомогою наліплені зверху латочки "довгі імена», реалізація яких там хоч і близька до ідеально можливою без зміни системи, але все ж досить безглузда. Але в наступні роки необхідність змін назріла остаточно, оскільки природні обмеження FAT стали давати про себе знати. FAT32, що з'явилася в Windows 95 OSR2, просто зрушила рамки - не змінивши суті системи, яка просто не дає можливості організувати ефективну роботу з великою кількістю даних.

HPFS (High Performance File System), активно застосовується до сих пір користувачами OS / 2, показала себе досить вдалою системою, але і вона мала істотні недоліки - повна відсутність засобів автоматичної восстанавливаемости, зайву складність організації даних і невисоку гнучкість.

NTFS ж довго не могла завоювати персональні комп'ютери через те, що для організації ефективної роботи з її структурами даних були потрібні значні обсяги пам'яті. Системи з 4 або 8 Мбайт (стандарт 95-96 років) були просто нездатні одержати хоч який-небудь плюс від NTFS, тому за нею закріпилася не надто правильна репутація повільної і громіздкої системи. Насправді це не відповідає дійсності - сучасні комп'ютерні системи з пам'яттю більше 64 Мб отримують просто величезний приріст продуктивності від використання NTFS.

В даній таблиці зведені воєдино всі істотні плюси і мінуси поширених в наш час систем, таких як FAT32, FAT і NTFS. Навряд чи розумно обговорювати інші системи, так як в даний час 97% користувачів роблять вибір між Windows98, Windows NT4.0 і Windows 2000 (NT5.0), а інших варіантів там просто немає.

FAT

FAT32

NTFS

Системи, її підтримують DOS, Windows9Х, NT всіх версій Windows98, NT5 NT4, NT5 Максимальний розмір томи 2 Гбайт практично необмежений практично необмежений Макс. число файлів на томі приблизно 65 тисяч практично не обмежена практично не обмежена Файл з підтримкою довгих імен - 255 символів, системний набір символів з підтримкою довгих імен - 255 символів, системний набір символів 255 символів, будь-які символи будь-яких алфавітів (65 тисяч різних накреслень) можливі атрибути файлу Базовий набір Базовий набір все, що прийде в голову виробникам програмного забезпечення Безпека немає немає да (починаючи з NT5.0 вбудована можливість фізично шифрувати дані) Стиснення немає немає да Стійкість до сб оям середня (система занадто проста і тому ламатися особливо нічому :)) погана (засоби оптимізації по швидкості призвели до появи слабких по надійності місць) повна - автоматичне відновлення системи при будь-яких збоях (не рахуючи фізичні помилки запису, коли пишеться одне, а на самому справі записується інше) Економічність мінімальна (величезні розміри кластерів на великих дисках) поліпшена за рахунок зменшення розмірів кластерів максимальна. Дуже ефективна і різноманітна система зберігання даних Швидкодія висока для малого числа файлів, але швидко зменшується з появою великої кількості файлів в каталогах. результат - для слабо заповнених дисків - максимальна, для заповнених - погане повністю аналогічно FAT, але на дисках великого розміру (десятки гігабайт) починаються серйозні проблеми із загальною організацією даних система не дуже ефективна для малих і простих розділів (до 1 Гбайт), але робота з величезними масивами даних і значними каталогами організована як не можна більш ефективно і дуже сильно перевершує за швидкістю інші системи

Хотілося б сказати, що якщо ваша операційна система - NT (Windows 2000), то використовувати будь-яку файлову систему, відмінну від NTFS - значить істотно обмежувати свою зручність і гнучкість роботи самої операційної системи. NT, а особливо Windows 2000, складає з NTFS як би дві частини єдиного цілого - безліч корисних можливостей NT безпосередньо зав'язано на фізичну і логічну структуру файлової системи, і використовувати там FAT або FAT32 має сенс лише для сумісності - якщо у вас стоїть завдання читати ці диски з будь-яких інших систем.

Продовження читайте в статті "Надійність дискової системи NT"