Стиснення NTFS на SSD - підйоми та падіння

У цій темі обговорюється стиснення NTFS на жорстких дисках як метод підвищення продуктивності доступу до диска, і робиться висновок про те, що це погано при цьому частіше, ніж ні. Але я завжди розглядав стиснення як спосіб збереження простору, і дізнався його ефективність при цьому. І тепер у мене є SSD, де місце дороге, а штраф за продуктивність, наприклад, для читання / запису 2 кластерів замість 1 набагато нижчий.

З іншого боку, оскільки жорсткі диски набагато швидші, ніж жорсткі диски, я би сподівався, що більша пропускна здатність призведе до більшого використання процесора. Чи може це стати проблемою? Будь-які інші думки з цього приводу?

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

Microsoft написав це деякий час тому в своєму блозі :

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

Ця конструкція робить випадковий доступ дуже швидким, оскільки тільки один CU потрібно розпаковувати, щоб отримати доступ до будь-якого єдиного VCN у файлі. На жаль, великий послідовний доступ буде відносно повільнішим, оскільки для виконання послідовних операцій (таких як резервне копіювання) потрібна декомпресія багатьох CU.

І в статті KB пише це :

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

Оскільки стиснення NTFS є інтенсивним процесором, вартість продуктивності помітніша на серверах, які часто пов'язані з процесором. Сильно завантажені сервери з великим трафіком запису є поганими кандидатами для стиснення даних. Однак у вас можуть не спостерігатися значні зниження продуктивності на серверах лише для читання, в основному для читання або слабо завантажених серверів.

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

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

Підсумок:

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

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

Для SSD стискання NTFS не слід використовувати.

Зараз я перерахую кілька мотивів такого твердження:

Мотив Nº1: Це швидше вб'є SSD musch, оскільки він робить дві записи; Стиснення NTFS завжди записує нестиснені дані перед початком стиснення в оперативній пам'яті, а потім перезаписує стислі дані лише в тому випадку, якщо це коефіцієнт посилення принаймні 4 Кбіт.

Мотив Nº2: Використання кластера NTFS 4KiB на SSD втрачає 50% швидкості SSD, перевірте будь-який орієнтир і побачите, що блоки 128KiB роблять SSD вдвічі швидшим, ніж використання блоків 4KiB, а компресія NTFS може бути використана лише на розділах NTFS кластера 4KiB.

Мотив Nº3: Є контейнери (наприклад, PISMO File Mount), які можуть створювати контейнер, який розглядається як під час стиснення та / або шифрування льоту, такі учасники виконують стиснення в оперативній пам’яті і не надсилають нестиснені дані на диск перед повторним записом у стисненій формі також більше, PISMO отримує кращий коефіцієнт стиснення, ніж NTFS.

Мотивів набагато більше, але це найбільша важливість.

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

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

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

Ніхто не говорить про проблему мера на не SSD, це фрагментація.

Кожен блок 64KiB пишеться там, де він був би без стиснення, але його можна стиснути, так що принаймні <= 60KiB, тоді він пише менше 64KiB, бітовий гніздовий блок піде туди, де як би попередній не був компрес, тому багато прогалин.

Перевірте його за допомогою гігабайтного файлу віртуальної машини будь-якої системи Windows (вони, як правило, зменшуються на 50%, але з величезними> 10000 фрагментами).

А для SSD є щось не сказане, як на біса це пишуть? Я маю на увазі, якщо вона пише її нестиснутою, а потім перезаписує її стисненою версією (для кожного 64-мегабайтних мегаблоків), термін служби SSD дуже скорочується; але якщо він записує його безпосередньо у стиснутому вигляді, тоді живий SSD може бути довший або коротший .... довше, якщо ви пишете, що 64KiB лише відразу, коротше, на багато годин коротше, якщо ви пишете, що 64KiB в 4KiB, тому що він буде писати такі 64KiB (у стисненому вигляді) стільки разів, скільки 64/4 = 16 разів.

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

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

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

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

Оскільки PISMO робить компресію на ОЗУ перед записом на диск, це може змусити SSD тривати довше, мої тести стиснення NTFS змушують мене думати, що він надсилає дані на диск двічі, спочатку нестиснений, а після цього, якщо він може стиснути, перезаписується у стисненому вигляді .

Чому швидкість запису NTFS на моєму SSD становить близько 1/2 нестисненого файлу, ніж компресія, що становить близько 1/2 його розміру або менших розмірів стислих? У моєму AMD Threadripper 2950 (32 ядра та 64 потоку) із 128 Гбіт оперативної пам’яті (швидкий процесор, дуже швидкий процесор) при використанні його менше ніж 1%, тому є багато процесора для стиснення швидше, ніж максимальна секундна швидкість SSD, можливо, тому Стиснення NTFS починається після того, як блоки 64KiB надсилаються на диск нестисненим, а потім перезаписується стисненою версією ... о, якщо я це роблю на віртуальній машині під управлінням Linux на хості та Windows у гостях, тоді кеш Linux повідомляє, що такі кластери записуються двічі , і швидкість набагато, набагато швидша (Linux кешує не стиснені записи NTFS, що надсилаються гостем Windows, і оскільки після цього вони перезаписуються стислими даними, Linux не надсилає нестиснені дані на диск,

Моя рекомендація, не використовуйте стиснення NTFS, за винятком випадків, коли всередині віртуальних машин гості запускають вікна, якщо хостом є Linux, і ніколи, якщо ви використовуєте локомоти процесора, якщо ваш процесор недостатньо швидкий.

Сучасний SSD має величезний внутрішній кеш-пам'ять, так що запис + перезапис, викликаний стисненням NTFS, може бути пом’якшений системою внутрішнього кешу SSD.

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

Зробіть власні тести та використовуйте величезні розміри файлів (більший за встановлений там, щоб уникнути прихованих результатів кешу).

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

Стиснення NTFS co приймає блокування 64KiB, стискає їх, і якщо це може зменшити один кластер (4KiB), тоді він пишеться стиснутим, 64KiB - це 16 блоків 4KiB (послідовно).

Якщо файл 8KiB, коли стискання закінчується, кінцевий результат становить більше 4KiB, він не зберігає жодного кластеру, тому він записується без стиснення, ... і так далі ... натискання має набрати не менше 4 Кбіт.

А, а для стиснення NTFS NTFS повинен бути розміром кластера 4KiB.

Спробуйте зробити тест: Використовуючи кластер 128KiB на NTFS на SSD, ви побачите величезне покращення продуктивності швидкості запису.

Файлові системи на SSD з кластером 4KiB втрачають велику швидкість, в більшості випадків втрачається більше ніж на 50% ... дивіться будь-який орієнтир, який перевіряється з різними розмірами блоків, від 512Bytes до 2MiB, більшість SSD записують у подвійному розмірі швидкість, коли на розмірі кластера 64KiB (або 128KiB), ніж на 4KiB.

Хочете справжній натяк на ваш SSD? Не використовуйте кластер 4KiB у файловій системі, використовуйте 128KiB.

Використовуйте кластер 4KiB, лише якщо більше 99% ваших файлів менше 128 Кбіт.

І т. Д., І т. Д. ... тестуйте, тестуйте і перевіряйте свій власний випадок.

Примітка: Створіть системний розділ NTFS за допомогою дискової частини в консольному режимі під час встановлення Windows з кластером 128KiB або з іншої Windows, але не дозволяйте форматувати Windows під час графічної частини інсталятора (він завжди буде форматувати його як 4KiB кластер NTFS).

Усі мої Windows зараз встановлені на розділі NTFS кластера 128KiB на> 400GiB SSD (SLC).

Сподіваюся, що все стане зрозуміло, M $ не говорить про те, як я пише компресований NTFS, мої тести говорять мені, що він пише два рази (64KiB нестиснений, потім <= 60KiB стиснений), а не один раз (будьте обережні, якщо на SSD).

Остерігайтеся: Windows намагається NTFS стискати деякі внутрішні бруси, незалежно від того, якщо ви скажете, що NTFS не стискається, єдиний спосіб дійсно уникнути цього, якщо розмір кластера NFTS відрізняється від 4KiB, оскільки стиснення NTFS працює лише на розділах розміру кластеру NTFS розміром 4KiB.

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

28,5 ГБ Дані 30,6 ГБ Розмір на диску Містить 729,246 файлів та 15 000 папок (!!!)

Це на моєму ноутбуці з 500 ГБ SSD, де розділ Windows становить 200 ГБ.

Я знаю, що Matlab є дещо екстремальним у цьому плані, але багато розробників мають подібні властивості: тонна невеликих текстових файлів, які дуже стискаються (заголовки, код, XML-файли). Я стискаю Matlab прямо перед тим, як встановити Intel Quartus FPGA devtool, і Octave вже стискається наступним чином:

1,55 ГБ Розмір даних на диску: 839 ГБ Містить 34,362 файли 1,955 папок

Цей матеріал пишеться один раз і читається мільйони разів під час складання проекту. Має сенс витратити деяку потужність процесора, щоб розпакувати його і заощадити, можливо, половину дорогоцінного місця на SSD.

Щоб знати, потрібно двічі орієнтуватись. Стиснута. Нестиснений. Забудьте про зношення SSD-дисків. Вам потрібен швидкий ssd і процесор, щоб не виникало вузького місця.

SSD 512 Гб становить 50 баксів в ці дні. Для мене найшвидший доступ до диска досі використовує Linux, де це можливо, та механізм черги на диски LIFO. Замість CFQ.

Windows 10 створює нескінченну активність на диску з 12 Гб оперативної пам’яті, встановленої на моєму ноутбуці. Після цього відбувається монетне навантаження Linux та майже нульовий доступ до диска. Якщо ви не ініціюєте це. У Windows просто є спосіб зайнятися без видимих ​​завдань.