Kompresi NTFS pada SSD - pasang surut

Topik ini membahas kompresi NTFS pada HDD sebagai metode untuk meningkatkan kinerja akses disk, dan menyimpulkan bahwa itu buruk karena lebih sering daripada tidak. Tetapi saya selalu melihat kompresi sebagai cara untuk menghemat ruang, dan belajar efektivitasnya pada saat itu. Dan sekarang saya memiliki SSD di mana ruang mahal dan hukuman kinerja misalnya untuk membaca / menulis 2 kluster bukannya 1 jauh lebih rendah.

Di sisi lain, karena SSD jauh lebih cepat daripada HDD, saya berharap bahwa throughput yang lebih tinggi akan menghasilkan penggunaan CPU yang lebih tinggi. Bisakah ini menjadi masalah? Ada pemikiran lain tentang masalah ini?

Saya suka efek menghemat ruang, tidak besar tapi ada di sana. Namun, jika kinerja menjadi masalah, saya lebih baik mematikannya:

Microsoft menulis ini beberapa waktu lalu di sebuah blog :

NTFS memampatkan file dengan membagi aliran data ke dalam CU (ini mirip dengan bagaimana file jarang bekerja). Ketika konten aliran dibuat atau diubah, setiap CU dalam aliran data dikompresi secara individual. Jika kompresi menghasilkan pengurangan oleh satu atau lebih cluster, unit terkompresi akan ditulis ke disk dalam format terkompresi. Kemudian rentang VCN yang jarang ditempelkan ke ujung rentang VCN yang dikompresi untuk tujuan penyelarasan (seperti yang ditunjukkan dalam contoh di bawah). Jika data tidak cukup kompres untuk mengurangi ukuran oleh satu cluster, maka seluruh CU ditulis ke disk dalam bentuk yang tidak terkompresi.

Desain ini membuat akses acak sangat cepat karena hanya satu CU perlu didekompresi untuk mengakses VCN tunggal dalam file. Sayangnya, akses berurutan besar akan relatif lebih lambat karena dekompresi banyak CU diperlukan untuk melakukan operasi berurutan (seperti cadangan).

Dan dalam artikel KB menulis ini :

Sementara kompresi sistem file NTFS dapat menghemat ruang disk, mengompresi data dapat mempengaruhi kinerja. Kompresi NTFS memiliki karakteristik kinerja berikut. Ketika Anda menyalin atau memindahkan file NTFS terkompresi ke folder yang berbeda, NTFS mendekompres file, menyalin atau memindahkan file ke lokasi baru, dan kemudian mengkompres ulang file. Perilaku ini terjadi bahkan ketika file disalin atau dipindahkan di antara folder di komputer yang sama. File yang dikompresi juga diperluas sebelum menyalin melalui jaringan, sehingga kompresi NTFS tidak menghemat bandwidth jaringan.

Karena kompresi NTFS bersifat intensif-prosesor, biaya kinerja lebih terlihat pada server, yang sering kali terikat pada prosesor. Server yang dimuat dengan banyak lalu lintas tulis adalah kandidat yang buruk untuk kompresi data. Namun, Anda mungkin tidak mengalami penurunan kinerja yang signifikan dengan server baca-saja, baca-kebanyakan, atau ringan.

Jika Anda menjalankan program yang menggunakan pencatatan transaksi dan yang terus-menerus menulis ke database atau log, konfigurasikan program untuk menyimpan file-nya pada volume yang tidak dikompresi. Jika suatu program memodifikasi data melalui bagian yang dipetakan dalam file terkompresi, program dapat menghasilkan halaman "kotor" lebih cepat daripada penulis yang dipetakan dapat menulisnya. Program seperti Microsoft Message Queuing (juga dikenal sebagai MSMQ) tidak berfungsi dengan kompresi NTFS karena masalah ini.

Karena folder beranda pengguna dan profil roaming menggunakan banyak operasi baca dan tulis, Microsoft merekomendasikan agar Anda meletakkan folder beranda pengguna dan profil roaming pada volume yang tidak memiliki kompresi NTFS pada folder induk atau pada root volume.

Ringkasan:

hanya kompres file kecil yang tidak pernah berubah (hanya membaca dan tidak menulis untuk itu) karena membaca cepat, tetapi menulis memerlukan kompresi dan kompresi baru yang membutuhkan daya CPU dan jenis penyimpanan tidak begitu penting.

Ketika Claudio mengatakan banyak hal secara rinci, saya akan melanjutkan pendapatnya yang juga milik saya, saya telah melihat efek yang sama setelah mencoba apa yang dia katakan.

Untuk SSD, kompresi NTFS tidak boleh digunakan.

Sekarang saya akan menyebutkan beberapa motif untuk penegasan tersebut:

Motif Nº1: Ini akan membunuh SSD lebih cepat, karena membuat dua tulisan; Kompresi NTFS selalu membuat data yang tidak terkompresi sebelum memulai kompresi pada RAM dan kemudian menulis ulang data terkompresi hanya jika itu adalah keuntungan setidaknya 4KiB.

Motif Nº2: Menggunakan kluster NTFS 4KiB pada SSD kehilangan 50% kecepatan SSD, periksa benchmark apa saja dan akan melihat 128KiB blok membuat SSD dua kali lebih cepat daripada menggunakan blok 4KiB, dan kompresi NTFS hanya dapat digunakan pada partisi NTFS kluster 4KiB.

Motif Nº3: Ada wadah (seperti PISMO File Mount) yang dapat membuat wadah yang terlihat seperti pada kompresi lalat dan / atau enkripsi, seperti itu pengompresi melakukan kompresi pada RAM dan tidak mengirim data terkompresi ke disk sebelum menulis ulang pada bentuk terkompresi, juga lebih banyak, PISMO mendapatkan rasio kompresi yang lebih baik daripada NTFS.

Ada lebih banyak motif, tetapi itu adalah importir paling top.

Titik otrer adalah SPEED, setiap kompresi dilakukan pada CPU, jadi jika Anda tidak memiliki CPU yang sangat cepat (mono-thread digunakan untuk itu pada NTFS sementara multi-thread digunakan pada beberapa wadah) akan melihat sangat lambat baca / tulis saat dikompresi; terburuk, Anda dapat memiliki cpu yang sangat cepat, tetapi jika digunakan untuk hal-hal lain (seperti rendering, transcoding, dll) tidak ada cpu yang tersisa untuk kompresi, jadi sekali lagi Anda akan mendapatkan kinerja yang buruk.

Kompresi NTFS hanya baik untuk disk lambat tradisional ketika Anda memiliki CPU tanpa banyak digunakan, tetapi membutuhkan defragmentasi yang baik setelah setiap penulisan (pada tingkat file), karena setiap blok 64KiB (dikompresi atau tidak) ditulis pada kelipatan posisi 64KiB; satu-satunya cara untuk mengemas fragmen tersebut adalah setelah kompresi (atau menulis pada folder terkompresi) melakukan defragmentasi file tersebut.

PD: Hati-hati kita berbicara tentang Windows pada perangkat keras nyata, bukan di dalam mesin virtual, yang penting adalah siapa yang menulis ke media fisik, yang lain mungkin memiliki lapisan cache yang dapat mengurangi efek dan juga meningkatkan banyak hal.

Tidak ada yang berbicara tentang masalah walikota pada non SSD, ini adalah fragmentasi.

Setiap blok 64KiB ditulis di mana ia akan tanpa kompresi, tetapi itu dapat dikompresi, jadi setidaknya <= 60KiB, maka ia menulis kurang dari 64KiB, blok bit nest akan menuju ke tempat yang seolah-olah yang sebelumnya tidak kompres, jadi banyak celah yang muncul.

Uji dengan file multi-gigabyte dari mesin virtusl dari sistem windows mana pun (mereka cenderung berkurang 50%, tetapi dengan fragmen> 10.000 yang sangat besar).

Dan untuk SSD ada sesuatu yang tidak diceritakan, bagaimana sih caranya menulis? Maksud saya, jika ia menulisnya tidak terkompresi dan kemudian menimpanya dengan versi terkompresi (untuk masing-masing mega blok 64KiB), kehidupan SSD banyak terpotong; tetapi jika ia menulisnya langsung pada bentuk terkompresi, maka SSD live bisa lebih pendek atau lebih pendek .... lebih lama jika Anda menulis 64KiB hanya sekaligus, lebih pendek, lebih pendek jika Anda menulis 64KiB dalam 4KiB, karena akan menulis 64KiB tersebut (dalam bentuk terkompresi) sebanyak 64/4 = 16 kali.

Penalti kinerja disebabkan karena waktu CPU yang dibutuhkan untuk mengompresi / membuka kompresi lebih besar daripada waktu yang diperoleh karena tidak perlu menulis blok 4KiB ... jadi dengan CPU yang sangat cepat dan kompresi disk yang sangat lambat mengurangi waktu untuk menulis dan membaca, tetapi jika SSD sangat cepat dan CPU sangat lambat, itu akan menulis lebih lambat.

Ketika saya berbicara tentang CPU cepat atau lambat yang saya maksud pada saat itu, CPU dapat digunakan oleh 'matematika' atau proses lainnya, jadi selalu berpikir tentang cpu gratis, bukan pada spesifikasi CPU di atas kertas, hal yang sama berlaku untuk disk / SSD, itu bisa sedang digunakan oleh beberapa proses.

Katakanlah Anda memiliki 7Zip yang sedang menulis file besar dari disk lain dengan LZMA2, itu akan menggunakan banyak CPU, jadi jika pada saat yang sama Anda menyalin file terkompresi NTFS, itu tidak memiliki CPU gratis, sehingga akan menjadi lebih lambat daripada tanpa NTFS kompresi, tetapi segera setelah 7Zip menggunakan CPU, CPU tersebut akan dapat mengkompres NTFS lebih cepat, dan pada saat itu kompresi NTFS dapat melakukan banyak hal lebih cepat.

Secara pribadi saya tidak pernah menggunakan kompresi NTFS, saya lebih suka file PISMO me-mount wadah PFO (dengan kompresi, dan juga memungkinkan enkripsi, baik dengan cepat dan transparan untuk aplikasi), ini memberikan rasio kompresi yang lebih baik dan dampak CPU yang lebih sedikit, sementara itu dibaca dan menulis dengan cepat, tidak perlu melakukan dekompresi sebelum digunakan, cukup pasang dan gunakan dalam mode baca dan tulis.

Karena PISMO melakukan kompresi pada RAM sebelum menulis pada disk, itu dapat membuat SSD lebih lama, pengujian kompresi NTFS membuat saya berpikir itu mengirim data ke disk dua kali, pertama tidak terkompresi, dan setelah itu jika dapat mengkompres, ia ditimpa dalam bentuk terkompresi. .

Mengapa kecepatan penulisan terkompresi NTFS pada SSD saya hampir 1/2 dari yang tidak dikompresi dengan file daripada kompres di dekat 1/2 dari ukurannya atau ukuran kompresi yang lebih rendah? Dalam AMD Threadripper 2950 (32 core dan 64 thread) AMD saya dengan ram 128GiB (CPU cepat, CPU sangat cepat) dengan penggunaan kurang dari 1%, jadi ada banyak CPU untuk melakukan kompresi lebih cepat daripada kecepatan maksimum SSD, mungkin karena Kompresi NTFS dimulai setelah 64KiB blok yang dikirim ke disk terkompresi dan kemudian ditimpa dengan versi terkompresi ... oh jika saya melakukannya di mesin virtual yang menjalankan Linux pada host dan Windows pada tamu, maka cache Linux memberi tahu saya bahwa cluster seperti itu ditulis dua kali , dan kecepatannya jauh, jauh lebih cepat (Linux melakukan caching pada NTFS non-kompresi yang dikirim oleh windows guest dan karena setelah itu mereka ditimpa dengan data terkompresi, linux tidak mengirim data yang tidak terkompresi ke disk,

Rekomendasi saya, jangan gunakan kompresi NTFS, kecuali di dalam mesin Virtual tamu yang menjalankan windows jika host adalah Linux, dan tidak pernah jika Anda menggunakan CPU lotor jika CPU Anda tidak cukup cepat.

SSD modern memiliki cache ram internal yang besar, sehingga penulisan + overwtite yang disebabkan oleh kompresi NTFS dapat dikurangi dengan sistem cache internal SSD.

Pengujian saya dilakukan pada SSD "cantik" tanpa RAM internal untuk cache di dalam SSD, ketika saya mengulanginya pada yang dengan cache ram, kecepatan tulis lebih cepat, tetapi tidak seperti yang dipikirkan orang.

Lakukan tes Anda sendiri, dan gunakan ukuran file besar (lebih besar dari total tam yang diinstal untuk menghindari hasil tersembunyi cache).

Ngomong-ngomong, sesuatu yang beberapa orang tidak tahu tentang kompresi NTFS ... file 4KiB atau lebih rendah tidak akan pernah mendapatkan kompres NTFS karena tidak ada cara untuk mengurangi ukurannya setidaknya 4KiB.

Co-pression NTFS mengambil bloack dari 64KiB, kompres mereka dan jika itu dapat mengurangi satu cluster (4KiB) maka itu ditulis terkompresi, 64KiB adalah 16 blok 4KiB (eksekutif).

Jika file 8KiB saat kompresi berakhir, hasil akhirnya lebih dari 4KiB, maka van tidak menyimpan cluster apa pun, jadi ini ditulis tanpa kompresi, ... dan seterusnya ... tekanan harus mendapatkan setidaknya 4KiB.

Ah, dan untuk kompresi NTFS, NTFS harus dengan ukuran cluster 4KiB.

Coba dan lakukan tes: Gunakan 128KiB cluster pada NTFS di SSDAnda akan melihat peningkatan kinerja besar pada kecepatan menulis dan membaca.

Sistem file pada SSD dengan kluster 4KiB kehilangan banyak kecepatannya, pada kebanyakan kasus lebih dari 50% hilang ... lihat benchmark apa pun di luar sana yang menguji dengan ukuran blok yang berbeda, dari 512Bytes hingga 2MiB, sebagian besar SSD menulis dua kali lipat mempercepat ketika pada ukuran cluster 64KiB (atau 128KiB) daripada pada 4KiB.

Ingin sentuhan nyata pada SSD Anda? Jangan gunakan cluster 4KiB pada sistem file, gunakan 128KiB.

Gunakan hanya 4KiB cluster jika lebih dari 99% file Anda kurang dari 128KiB.

Dll, dll, dll ... uji, uji dan uji kasus Anda sendiri.

Catatan: Buat partisi sistem NTFS dengan diskpart dalam mode konsol saat menginstal Windows dengan 128KiB cluster, atau dari Windows lain, tetapi jangan biarkan windows memformat saat di bagian grafis installer (itu akan selalu memformatnya sebagai 4KiB cluster NTFS).

Semua Windows saya sekarang diinstal pada partisi NTFS 128KiB cluster pada> 400GiB SSD (SLC).

Berharap semuanya akan menjadi jelas, M $ tidak mengatakan bagaimana saya menulis NTFS terkompresi, tes saya mengatakan itu menulis dua kali (64KiB terkompresi, kemudian <= 60Ki dikompresi), tidak hanya sekali (waspadalah jika di SSD).

Hati-hati: Windows mencoba untuk kompres NTFS beberapa dir internal, tidak masalah jika Anda mengatakan tidak kompres NTFS, satu-satunya cara untuk benar-benar menghindari seperti jika memiliki ukuran cluster NFTS berbeda dari 4KiB, karena kompresi NTFS hanya bekerja pada 4KiB ukuran kluster partisi NTFS

Saya melihat komentar orang lain, dan saya pikir orang sering lupa skenario paling berguna di mana kompresi file / folder NTFS memiliki keuntungan besar pada SSD: alat pengembangan modern. Matlab yang dilisensikan oleh universitas saya memiliki dalam folder instalasi (hanya untuk pengguna biasa) jumlah data berikut:

28.5 GB Data 30.6 GB Ukuran pada disk Berisi 729.246 file dan 15.000 folder (!!!)

Ini ada di laptop saya dengan SSD 500 GB, di mana partisi windows adalah 200 GB.

Saya tahu Matlab agak ekstrim dalam hal ini, tetapi banyak devtools memiliki sifat yang serupa: satu ton file teks kecil yang sangat dapat dikompresi (header, kode, file XML). Saya mengompresi Matlab sekarang sebelum saya menginstal Intel Quartus FPGA devtool, dan Oktaf sudah dikompresi sebagai berikut:

1,55 GB Ukuran Data pada disk: 839 GB Berisi 34,362 file 1,955 folder

Barang-barang ini ditulis sekali, dan membaca zillions kali selama membangun proyek. Itu masuk akal untuk mengeluarkan beberapa daya CPU untuk dekompresi dan menyimpan mungkin setengah dari ruang SSD berharga Anda.

Anda perlu membandingkan dua kali untuk mengetahui. Terkompresi. Tidak terkompresi. Lupakan keausan pada SSD. Anda memerlukan ssd dan CPU yang cepat sehingga tidak terjadi bottleneck.

SSD 512GB adalah 50 dolar hari ini. Akses disk tercepat bagi saya sejauh ini adalah menggunakan Linux di mana mungkin dan mekanisme antrian disk LIFO. Daripada CFQ.

Windows 10 membuat aktivitas disk tanpa batas dengan ram 12GB yang diinstal pada laptop saya. Linux mint memuat dan hampir tidak ada akses disk terjadi setelahnya. Kecuali jika Anda memulainya. Windows hanya memiliki cara menjaga dirinya sibuk tanpa tugas yang terlihat.