Який алгоритм розподілу блоків використовує NTFS?

У Windows XP 64 я завантажив файл 1,2 Гб, і він виявився фрагментарним, як показує зображення. На жаль, перед тим, як зробити знімок з Piriform Defraggler, я дефрагментував інші файли, тож ви не змогли побачити точний стан у тому місці, у якому файл був записаний. Однак диск був весь час таким же порожнім, як зараз (25% раніше) і навряд чи фрагментарно.

Який алгоритм розподілу блоків використовує NTFS? Це виглядає як випадкове або, можливо, помістити його там, де фактично стоїть головка диска.

ОНОВЛЕННЯ:

Саме це сталося сьогодні після написання 67 МіБ нового файлу. Він розбився на 731 фрагмент, середній розмір всього 95 Кб. Цей файл використовувався для заповнення деяких прогалин, але не всі вони також не використовують величезний безперервний вільний простір. Дивно, чи не так?

ОНОВЛЕННЯ 2:

На відміну від ПК Гуру , я дійсно не вважаю винуватцем опера. Я думаю, що це (на відміну від Google Chrome) не вказує на очікуваний розмір Windows, однак, існує багато випадків, коли це неможливо, і відповідальність за операційну операційну систему належить виконувати. На наступному малюнку видно, що сталося через пару днів зі мною, які майже нічого не робили на цьому розділі - каталог TEMP і всі мої дані (за винятком тих, якими керує Windows) розташовані в іншому місці. Сам Windows, здається, не використовує SetEndOfFileі фрагментує власні файли жахливим чином (600 фрагментів на пару невеликих файлів розміром близько 40 Мб). Схоже, NTFS не використовує перший доступний сектор, оскільки знову є файли в середині, а також в кінці зовсім порожнього диска (використання 23%),

IIRC, файлова система NTFS намагається виділити файл у суміжних сховищах. Однак це може зробити це лише в тому випадку, якщо файлова система знає розмір файлу. Якщо ви відкриєте файл і почнете писати в нього, він напише в "найкраще" місце, щоб вмістити файл (як правило, на зовнішній стороні тарілки). Але це "найкраще" місце може бути недостатньо великим, щоб вмістити файл.

Якщо програма повідомляє NTFS фактичний розмір файлу (за допомогою SetEndOfFile ()), NTFS може зробити кращу роботу з пошуку суміжного простору для файлу (API SetEndOfFile змушує NTFS виділяти сховище для всього файлу).

Ваша проблема повинна бути з Opera. Я щойно переглянув купу файлів на дуже повному та фрагментарному диску. Великі файли, завантажені за допомогою Chrome, були суміжними.

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

Якщо програма не знає розмір файлу або не намагається повідомити NTFS, а натомість просто відкриває файл і починає записувати послідовні дані, виявляється, що NTFS діє дуже схоже на FAT32, який просто запускається на першому доступному кластері (або перший доступний після останнього, виділеного в цьому сеансі), потім використовує все, що доступно звідти вперед. Як приклад, приблизно в той же час я попросив CCleaner сканувати реєстр, викликаючи його резервне копіювання до великого txt ".Reg" файла. Цей файл розпочався майже на початку диска, а потім був розсіяний по 127 різних фрагментів. На відміну від файлів, скопійованих із Провідника або завантажених з Chrome, у кожному файлі, який я переглянув, кластери були розподілені у порядку зростання.

Для цього дослідження я використав Winhex (безкоштовна пробна версія, доступна на Winhex.com). Дивлячись на запис каталогу. клацніть правою кнопкою миші на ім'я файлу та виберіть Позиція, Список кластерів, щоб побачити список кластерів, використовуваних цим файлом.