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

Операційні системи сімейства Microsoft Windows NT не можна уявити без файлової системи NTFS - однієї з найбільш складних і вдалих з існуючих на даний момент файлових систем. Дана стаття розповість вам, у чому особливості та недоліки цієї системи, на яких принципах заснована організація інформації, і як підтримувати систему в стабільному стані, які можливості пропонує 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, яку написав відомий фахівець Mark Russinovich (http://www.sysinternals.com/). Програма працює тільки в 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 кластерів. Наслідки:

В дірку вільного місця менше 16 кластерів не можна нічого перемістити (крім стислих файлів, але це нецікаві в даний момент тонкощі).

Файл, будучи переміщений в інше місце, залишає після себе (на новому місці) "тимчасово зайняте місце", доповнює його за розміром до кратності 16 кластерів.

При спробі якось неправильно ( "не кратно 16") перемістити файл результат часто непередбачуваний. Что-то округляється, щось просто не перемещаетсяЕ Тим не менше, все місце дії щедро розсипається "тимчасово зайнятим місцем ".

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

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

виймання файлів з MFT зони. Чи не спеціально - просто назад туди їх покласти не представляється можливим:) Невинна фаза, і навіть в чому то корисна.

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

Дефрагментація MFT, віртуалки (pagefile.sys) і каталогів. Можлива через API тільки в Windows2000, інакше - Після перезавантаження окремим процесом, як у старому Diskeeper-е.

Складання файлів ближче до початку - так звана дефрагментація вільного місця. Ось це - Воістину страшний процес ...

Припустимо, ми хочемо покласти файли поспіль у початок диска. Кладемо один файл. Він залишає хвіст зайнятості додатки до кратності 16. Кладемо наступний - після хвоста, природно. Через деякий час, за звільнення хвоста, маємо дірку <16 кластерів розміром. Яку потім неможливо заповнити через API дефрагментації! В результаті, до оптимізації картина вільного місця виглядала так: багато дірок приблизно однакового розміру. Після оптимізації - одна дірка в наприкінці диска, і багато маленьких <16 кластерів дірок у заповненому файлами ділянці. Які місця у першу чергу заповнюються? Правильно, що знаходяться ближче до початку диска дрібні дірки <16 кластерів ... Будь-який файл, плавно створений на прооптімізірованном диску, складатиметься з дикого числа фрагментів. Так, диск потім можна оптимізувати знову. А потім ще раз .. і ще .. і так - бажано щотижня. Бред? Реальність.

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

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

До жаль, в Windows 2000 помістили дефрагментатор, який працює через API, і, відповідно плодить дірки <16 кластерів. Так що як тільки з'явиться (якщо ще не з'явився) - так відразу треба качати Speeddisk для W2k.

Як деякий висновок з усього цього: всі інші дефрагментатори при одноразовому застосуванні просто шкідливі. Якщо ви запускали його хоч раз - потрібно запускати його потім хоча б раз на місяць, щоб позбутися фрагментації новопрібивающіх файлів. У цьому основна суть складності дефрагментації 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 має сенс лише для сумісності - якщо у вас стоїть завдання читати ці диски з будь-яких інших систем.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.nodevice.ru/