Чому дефрагментація диска С збільшила мій вільний простір на 10 Гб?

Я використовував Defraggler, щоб дефрагментувати вільний простір на моєму накопичувачі 100 Г Г: \, який був 85 Гб. Після дефрагментації накопичувач показав лише 75 Гб. Як чарівно з’явилося 10 Гб вільного місця? Я втратив будь-які дані?

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

Можливо, трапилось те, що операція defrag змусила Windows викинути деякі знімки відновлення системи. Патологічний випадок фрагментації може призвести до того, що накладні метадані становлять 10% вашого дискового простору понад те, що зазвичай використовує Windows. навіть тоді я не впевнений, що це можливо.

Я не бачу нічого в історії або документації версій Defraggler, що вказує на те, що він здатний правильно дефрагментувати файли, щоб запобігти очищенню тіньових копій. Насправді, цей потік з форуму підтримки Defraggler вказує на те, що вони знають, що це відбувається (є потік адміністратора ради з написом "Офіційний помилок виправлення помилок" в потоці), але не вказують, чи збираються виправити це.

Тіньові копії можуть бути втрачені під час дефрагментації тома : Причина цього трапляється в тому, що за замовчуванням VSS працює за замовчуванням 16 кб кластерів, тоді як більшість томів NTFS відформатовані з кластерами 4 Кб. Отже, якщо операція дефрагментації переміщує дані, які не кратні кластеру 16 Кб (або "відстань", яку вона перемістила, не кратна 16 КБ), то VSS відстежує це як зміну і може очистити всі ваші знімки.

MSDN: Дефрагментація файлів :

Коли це можливо, переміщуйте дані в блоки, вирівняні відносно один одного, з кроком 16 кілобайт (КБ). Це зменшує накладні витрати при записі під час ввімкнення, коли ввімкнено тіньові копії, оскільки збільшується простір для тіньової копії та знижується продуктивність, коли виникають такі умови:

• Розмір блоку запиту на переміщення менший або рівний 16 Кб.
• Дельта руху не збільшується з кроком 16 Кб.

Вбудована дефрагмента Vista не робить цього :

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

Кожен фрагмент треба десь відстежити. Це займає місце для зберігання (в сантехніці Файлової системи, а не до матеріалів, до яких потрібно мати прямий доступ).

Приклад. Припустимо, у вас є один файл із 1000 фрагментами. Таким чином, ваш файл зберігається через колекцію випадкових блоків. Скоріше, ніж в одному безперервному блоці. Це означає, що фрагментований файл потребує на 1000 разів більше місця для зберігання в сантехніці файлової системи, якщо тільки для зберігання адрес для кожного фрагмента. Сантехніка файлової системи зберігає мало словників / баз даних / карт / таблиць / списку до місця розташування кожного фрагмента файлу. Отже, для сантехніки файлової системи для зберігання списку одного фрагмента вказівника не потрібно багато місця, порівняно зі списком 1000 фрагментів покажчиків.

Але ей, може, я помиляюся ...

Редагувати: Інформація про підтримку тут :

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

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

Редагувати: Враховуючи вищесказане, все ще здається, що втрачається 10 Гб просто для фрагментації файлу - це шалено. Маю на те, що під час дефрагментації у вас виникла якась пошкоджена файлова система, яка виправлялася автоматично. Я думаю, що ви мали не лише масову фрагментацію, але й частково видалені файли, що займають місце для зберігання. Було б добре побачити журнал скандиска з цього дефрагменту (або прогону скандиска до дефрагментації)