Дефрагментатор Windows 8?

Здається, що defragкоманда Windows 8 має нові параметри, зокрема:

/K Виконують ущільнення плит за заданими обсягами.

Хтось знає, що це означає англійською?

Цей PDF, схоже, має пояснення цього, а також нові функції NTFS.

Він говорить:

• Ущільнення плит

  • Ефективно дефрагментує файли, щоб мінімізувати кількість виділених плит

  • Плита - це одиниця розподілу на тонкий передбачений об'єм

  • Потрібна підтримка для IOCTL_STORAGE_QUERY_PROPERTYзапиту ідентифікатора власності:StorageDeviceLBProvisioningProperty

    • Вилучає розмір плити в обсязі

Я не зміг знайти нічого конкретного, що пояснює, що це означає в контексті дефрагментатора Windows 8. Але "консолідація плит", як правило, стосується рухомих об'єктів, так що об'єкти, що округляються до однакового розміру розподілу, розміщуються разом.

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

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

На мою думку, він використовується для зменшення затримки для виділень на великих обсягах, що в іншому випадку спричинить занадто багато паралельних доступу паралельними нитками, коли їм потрібно виділити простір на томі, оскільки це поставить замок на ту ж частину розподілу томів растровий малюнок Щоб уникнути обробки великих растрових зображень, її можна підрозділити на "плити", розмір яких у бітах являє собою суміжні області на диску, використовуючи той самий фрагмент растрової карти (що займає щонайменше 1 або більше кластерів; якщо розмір кластера становить 4 КБ, його кластер в растровій карті представляє 4K * 8 = 32K кластери, що виділяються, тобто зберігання 128 Мб; фактичний розмір плити в обсязі налаштований на рівні між 33 і 64, що дозволяє приблизно 33 одночасним потокам виділяти простір у растровій карті на відстані, не блокуючи один одного)

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

Це пояснює, чому розподіл на диску "розподіляється" по томі. Це також пояснює, чому MFT на NTFS має щонайменше 2 фрагменти, що належать до інших плит, оскільки це дозволяє уникнути серйозних замикань між багатьма потоками з використанням гучності. Ви можете дефрагментацію MFT, але він залишиться принаймні одним фрагментом, який зберігається у «зарезервованій області» для одночасних виділень, які повинні уникати блокування вводу / виводу на об’єм NTFS).

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

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

Інформацію про розміри плит можна отримати за допомогою:

fsutil fsinfo ntfsinfo c:

Очевидно, що плити налаштовують параметри, призначені для продуктивності. Але багато інструментів дефрагментації сторонніх сторін ігнорують цей параметр і не використовують оптимальне розташування. В ідеалі у вас має бути вільний простір на кожній плиті об'єму, якщо тільки на плитах повно файлів та індексів, які не перерозподіляються і повинні залишатися стабільними. Для багатьох невеликих тимчасових файлів і транзакцій, які постійно створюються та переробляються, потрібно розмістити їх у достатній кількості плит залежно від кількості одночасних потоків і уникати їх занадто далеко від інших кластерів, які потрібно прочитати, якщо обсяг є жорсткий диск або RAID масив (це не має значення на SSD).

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

Нам ще потрібна інформація від Microsoft про такі параметри настройки в реєстрі:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfrg\SlabifyFunction]
MinimumReclaimSlabsMB      = REG_DWORD: 10240
MinimumReclaimSlabsPercent = REG_DWORD: 10
SlabEvictUpperBoundKB      = REG_DWORD: 204800
SlabEvictUpperBoundPercent = REG_DWORD: 20

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

Все, що ми знаємо, - це те, що плити піддаються короткому опроміненню параметром "/ K" інструменту командного рядка DEFRAG.EXE, який не дуже деталізує їх. Але неважко помітити, що оптимізація / K дає величезні підвищення продуктивності після первинної установки Windows (навіть до того, як оптимізація Bootvis буде зроблена після 6 перезавантажень і вимірювань). Є також параметри / L, пов’язані з обрізкою на SSD.