Kompresja NTFS na dyskach SSD - wzloty i upadki

W tym temacie omówiono kompresję NTFS na dyskach twardych jako metodę poprawy wydajności dostępu do dysku i stwierdzono, że jest ona słaba częściej niż nie. Ale zawsze postrzegałem kompresję jako sposób na oszczędzanie przestrzeni i nauczyłem się w tym jej skuteczności. A teraz mam dysk SSD, w którym miejsce jest drogie, a spadek wydajności np. Za odczyt / zapis 2 klastrów zamiast 1 jest znacznie niższy.

Z drugiej strony, ponieważ dyski SSD są znacznie szybsze niż dyski HDD, oczekiwałbym, że większa przepustowość spowoduje większe użycie procesora. Czy to może stać się problemem? Wszelkie inne przemyślenia na ten temat?

Podoba mi się efekt oszczędzania miejsca, nie jest ogromny, ale tam jest. Jeśli jednak chodzi o wydajność, wolę ją wyłączyć:

Microsoft napisał to jakiś czas temu na blogu :

NTFS kompresuje pliki dzieląc strumień danych na jednostki CU (jest to podobne do działania plików rzadkich). Po utworzeniu lub zmianie zawartości strumienia każda jednostka CU w strumieniu danych jest indywidualnie kompresowana. Jeśli kompresja spowoduje zmniejszenie o jeden lub więcej klastrów, skompresowana jednostka zostanie zapisana na dysk w skompresowanym formacie. Następnie rzadki zakres VCN jest sczepiony na końcu skompresowanego zakresu VCN w celu wyrównania (jak pokazano w poniższym przykładzie). Jeśli dane nie są wystarczająco kompresowane, aby zmniejszyć rozmiar o jeden klaster, wówczas cała jednostka CU jest zapisywana na dysk w nieskompresowanej formie.

Ta konstrukcja sprawia, że ​​losowy dostęp jest bardzo szybki, ponieważ tylko jedna CU musi zostać zdekompresowana, aby uzyskać dostęp do dowolnego VCN w pliku. Niestety, duży sekwencyjny dostęp będzie stosunkowo wolniejszy, ponieważ dekompresja wielu jednostek CU jest wymagana do wykonywania operacji sekwencyjnych (takich jak tworzenie kopii zapasowych).

I w artykule KB pisze to :

Podczas gdy kompresja systemu plików NTFS może oszczędzać miejsce na dysku, kompresja danych może negatywnie wpłynąć na wydajność. Kompresja NTFS ma następujące parametry wydajnościowe. Podczas kopiowania lub przenoszenia skompresowanego pliku NTFS do innego folderu, NTFS dekompresuje plik, kopiuje lub przenosi plik do nowej lokalizacji, a następnie ponownie kompresuje plik. Takie zachowanie występuje nawet wtedy, gdy plik jest kopiowany lub przenoszony między folderami na tym samym komputerze. Pliki skompresowane są również rozszerzane przed kopiowaniem przez sieć, więc kompresja NTFS nie oszczędza przepustowości sieci.

Ponieważ kompresja NTFS wymaga dużego procesora, koszt wydajności jest bardziej zauważalny na serwerach, które często są związane z procesorem. Silnie obciążone serwery z dużym ruchem zapisu są słabymi kandydatami na kompresję danych. Jednak może nie wystąpić znaczny spadek wydajności w przypadku serwerów tylko do odczytu, głównie do odczytu lub lekko obciążonych.

Jeśli uruchamiasz program, który korzysta z rejestrowania transakcji i stale zapisuje dane w bazie danych lub w dzienniku, skonfiguruj program tak, aby przechowywał swoje pliki na woluminie, który nie jest kompresowany. Jeśli program modyfikuje dane za pomocą mapowanych sekcji w skompresowanym pliku, program może tworzyć „brudne” strony szybciej niż zapisujący je program piszący. Programy takie jak Microsoft Message Queuing (znane również jako MSMQ) nie działają z kompresją NTFS z powodu tego problemu.

Ponieważ foldery domowe użytkowników i profile mobilne korzystają z wielu operacji odczytu i zapisu, Microsoft zaleca umieszczenie folderów domowych użytkowników i profili mobilnych na woluminie, który nie ma kompresji NTFS w folderze nadrzędnym lub katalogu głównym woluminu.

Podsumowanie:

kompresuj tylko małe pliki, które nigdy się nie zmieniają (tylko czyta i nie zapisuje do niego), ponieważ odczyty są szybkie, ale zapisy wymagają dekompresji i nowej kompresji, która pobiera moc procesora, a typ pamięci nie jest tak ważny.

Ponieważ Claudio mówi wiele rzeczy w szczegółach, zamierzam wznowić jego opinię, która jest również moja, widziałem te same efekty po wypróbowaniu tego, co mówi.

W przypadku dysków SSD nie można używać kompresji NTFS.

Wymienię teraz kilka motywów takiej afirmacji:

Motyw nr 1: Szybciej zabija piżmo SSD, ponieważ wykonuje dwa zapisy; Kompresja NTFS zawsze zapisuje nieskompresowane dane przed rozpoczęciem kompresji w pamięci RAM, a następnie ponownie zapisuje skompresowane dane tylko wtedy, gdy jest to przyrost co najmniej 4KiB.

Motyw nr 2: Używanie klastra NTFS 4KiB na dysku SSD traci 50% prędkości SSD, sprawdź dowolny test porównawczy i zobaczysz, że bloki 128KiB sprawiają, że SSD jest dwa razy szybszy niż przy użyciu bloków 4KiB, a kompresji NTFS można używać tylko na partycjach NTFS klastra 4KiB.

Motyw nr 3: Istnieją kontenery (takie jak PISMO File Mount), które mogą utworzyć kontener, który jest postrzegany jako kompresja w locie i / lub szyfrowanie, takie kontenery wykonują kompresję w pamięci RAM i nie wysyłają nieskompresowanych danych na dysk przed ponownym zapisaniem w formie skompresowanej również PISMO uzyskuje lepszy współczynnik kompresji niż NTFS.

Motywów jest znacznie więcej, ale są to najważniejsze importerzy.

Punktem otrer jest SPEED, dowolna kompresja jest wykonywana na CPU, więc jeśli nie masz bardzo szybkiego procesora (mono-wątek jest używany dla takich w NTFS, podczas gdy w niektórych kontenerach używany jest wielowątek), zobaczy bardzo powolny odczyt / zapis po ściśnięciu; co najgorsze, możesz mieć bardzo szybką jednostkę centralną, ale jeśli jest używana do innych celów (takich jak renderowanie, transkodowanie itp.), nie ma już jednostki centralnej do kompresji, więc ponownie uzyskasz niską wydajność.

Kompresja NTFS jest dobra tylko dla tradycyjnych wolnych dysków, gdy masz procesor bez większego użycia, ale wymaga dobrej defragmentacji po każdym zapisie (na poziomie pliku), ponieważ każdy blok 64KiB (skompresowany lub nie) jest zapisywany w wielokrotności pozycji 64KiB; jedynym sposobem na spakowanie takich fragmentów jest po kompresji (lub zapis w folderze skompresowanym) defragmentacja takiego pliku.

PD: Uważaj, mówimy o systemie Windows na prawdziwym sprzęcie, a nie na maszynach wirtualnych, ważne jest, kto pisze na nośniku fizycznym, inne mogą mieć warstwy pamięci podręcznej, które mogą złagodzić efekty, a także znacznie poprawić.

Nikt nie mówi o problemie burmistrza na dysku innym niż SSD, jest to fragmentacja.

Każdy blok 64KiB jest zapisywany w miejscu, w którym byłby bez kompresji, ale można go skompresować, więc co najmniej wynosi <= 60KiB, a następnie zapisuje mniej niż 64KiB, blok zagnieżdżenia bitów pójdzie tam, jakby to był poprzedni kompresować, więc wiele luk apèars.

Przetestuj to za pomocą pliku wielobajtowego maszyny virtusl dowolnego systemu Windows (zwykle zmniejsza się o 50%, ale z ogromną> 10000 fragmentów).

A jeśli chodzi o dyski SSD, nie ma o czym mówić, jak do diabła to pisze? Mam na myśli to, że jeśli zapisuje to nieskompresowane, a następnie zastępuje skompresowaną wersją (dla każdego mega bloku 64 KB), żywotność dysku SSD jest znacznie skrócona; ale jeśli zapisuje go bezpośrednio w postaci skompresowanej, wtedy SSD live może być krótszy lub krótszy ... dłużej, jeśli napiszesz tylko 64 KB na raz, krótszy, oh krótszy, jeśli napiszesz 64 KB w 4KiB, ponieważ napisze takie 64KiB (w formie skompresowanej) tyle razy, ile 64/4 = 16 razy.

Utrata wydajności wynika z tego, że czas procesora potrzebny na kompresję / dekompresję jest większy niż czas uzyskany na niepotrzebne zapisywanie bloków 4KiB ... więc bardzo szybki procesor i bardzo wolna kompresja dysku skracają czas na zapis i odczyt, ale jeśli SSD jest bardzo szybki, a procesor dość wolny, będzie pisać znacznie wolniej.

Kiedy mówię o szybkim lub wolnym procesorze, mam na myśli, że procesor może być używany przez „matematykę” lub inny proces, więc zawsze myśl o wolnym procesorze, a nie specyfikacji procesora na papierze, to samo dotyczy dysku / dysku SSD, może być w użyciu przez wiele procesów.

Załóżmy, że 7Zip zapisuje ogromny plik z innego dysku za pomocą LZMA2, będzie zużywał dużo procesora, więc jeśli jednocześnie kopiujesz plik skompresowany NTFS, nie ma on wolnego procesora, więc pójdzie wolniej niż bez NTFS kompresji, ale jak tylko 7Zip zakończy procesor, taki procesor będzie mógł kompresować NTFS szybciej, a kompresja NTFS może działać szybciej.

Osobiście nigdy nie używam kompresji NTFS, wolę kontenery PFO do montażu plików PISMO (z kompresją, a także umożliwia zapisywanie, zarówno w locie, jak i przezroczyste dla aplikacji), daje znacznie lepszy współczynnik kompresji i mniejszy wpływ procesora, podczas gdy jest to odczyt i pisz w locie, nie trzeba dekompresować przed użyciem, wystarczy zamontować i używać go w trybie odczytu i zapisu.

Ponieważ PISMO wykonuje kompresję w pamięci RAM przed zapisaniem na dysku, może wydłużyć czas działania dysku SSD, moje testy kompresji NTFS każą mi myśleć, że wysyła dane na dysk dwa razy, najpierw nieskompresowane, a następnie, jeśli można je skompresować, jest zastępowane w postaci skompresowanej .

Dlaczego prędkość zapisu skompresowanego NTFS na moim dysku SSD jest bliska 1/2 nieskompresowanego pliku z plikami niż kompresja przy prawie 1/2 jego rozmiaru lub mniejszych skompresowanych rozmiarach? W moim AMD Threadripper 2950 (32 rdzenie i 64 wątki) z 128GiB pamięci RAM (szybki procesor, bardzo szybki procesor) przy zużyciu mniejszym niż 1%, więc jest dużo procesora do wykonania kompresji szybciej niż maksymalna prędkość sekwencyjna SSD, może dlatego, że Kompresja NTFS rozpoczyna się po tym, jak bloki 64KiB są wysyłane na dysk nieskompresowane, a następnie nadpisywane skompresowaną wersją ... och, jeśli zrobię to na maszynie wirtualnej z systemem Linux na hoście i Windows na gościu, to pamięć podręczna Linux poinformuje mnie, że takie klastry są zapisywane dwa razy , a prędkość jest znacznie, dużo większa (Linux buforuje nieskompresowane zapisy NTFS wysyłane przez gościa systemu Windows, a ponieważ są one zastępowane skompresowanymi danymi, Linux nie wysyła nieskompresowanych danych na dysk,

Moja rekomendacja, nie używaj kompresji NTFS, z wyjątkiem gości maszyn wirtualnych, którzy uruchamiają system Windows, jeśli hostem jest Linux, i nigdy, jeśli używasz procesora zbyt często, jeśli procesor nie jest wystarczająco szybki.

Współczesny dysk SSD ma ogromną pamięć podręczną pamięci RAM, dzięki czemu zapis i nadpisywanie spowodowane kompresją NTFS mogą zostać złagodzone przez wewnętrzny system pamięci podręcznej SSD.

Moje testy były wykonywane na „ładnych” dyskach SSD bez wewnętrznej pamięci RAM na pamięć podręczną wewnątrz dysku SSD, gdy powtarzam je na dyskach z pamięcią podręczną pamięci RAM, szybkość zapisu jest szybka, ale nie tak, jak mogłoby się wydawać.

Wykonuj własne testy i używaj ogromnych rozmiarów plików (większych niż całkowita liczba zainstalowanych tam, aby uniknąć ukrytych wyników w pamięci podręcznej).

Nawiasem mówiąc, coś, czego niektórzy nie wiedzą o kompresji NTFS ... jakikolwiek plik 4KiB lub niższy nigdy nie uzyska kompresji NTFS, ponieważ nie ma sposobu, aby zmniejszyć jego rozmiar co najmniej 4KiB.

Kompresja NTFS wymaga bloack 64KiB, kompresuje je, a jeśli może zmniejszyć jeden klaster (4KiB), to jest zapisywany jako skompresowany, 64KiB to 16 bloków 4KiB (kolejne).

Jeśli plik 8KiB po zakończeniu kompresji końcowy wynik jest większy niż 4KiB, nie zapisuje żadnego klastra, więc jest zapisywany bez kompresji, ... i tak dalej ... naciśnięcie musi uzyskać co najmniej 4KiB.

Ach, a do kompresji NTFS, NTFS musi mieć rozmiar klastra 4KiB.

Spróbuj i wykonaj test: Użyj klastra 128 KB na NTFS na SSD. Zauważysz ogromną poprawę wydajności przy zapisywaniu prędkości odczytu.

Systemy plików na dyskach SSD z klastrem 4KiB tracą dużo prędkości, w większości przypadków tracą ponad 50% ... zobacz każdy test porównawczy, który testuje z różnymi rozmiarami bloków, od 512 bajtów do 2 MB, większość SSD pisze podwójnie prędkość w przypadku klastra o wielkości 64 kB (lub 128 kiB) niż w 4KiB.

Chcesz prawdziwej impresji na swoim dysku SSD? Nie używaj klastra 4KiB w systemie plików, użyj 128 kB.

Używaj klastra 4KiB tylko wtedy, gdy więcej niż 99% twoich plików ma mniej niż 128 KB.

Itd, etc, etc ... testuj, testuj i testuj własne przypadki.

Uwaga: Utwórz systemową partycję NTFS z diskpart w trybie konsoli podczas instalowania systemu Windows z klastrem 128 kB lub z innego systemu Windows, ale nie pozwól, aby system Windows sformatował się w części graficznej instalatora (zawsze sformatuje go jako klaster NTFS 4KiB).

Wszystkie moje systemy Windows są teraz zainstalowane na partycji NTFS klastra 128 KB na> SSD 400GiB (SLC).

Mam nadzieję, że wszystko się wyjaśni, M $ nie mówi, jak iy zapisuje skompresowany NTFS, moje testy mówią, że pisze dwa razy (64KiB nieskompresowany, a następnie <= 60KiB skompresowany), a nie tylko jeden raz (uważaj na to, jeśli na SSD).

Uwaga: Windows próbuje skompresować NTFS niektóre katalogi wewnętrzne, bez względu na to, czy powiesz, że nie ma kompresji NTFS, jedynym sposobem, aby naprawdę tego uniknąć, jeśli rozmiar klastra NFTS jest inny niż 4KiB, ponieważ kompresja NTFS działa tylko na partycjach NTFS o rozmiarze klastra 4KiB

Widzę komentarze innych i myślę, że ludzie często zapominają o najbardziej przydatnym scenariuszu, w którym kompresja plików / folderów NTFS ma wielką zaletę na dysku SSD: nowoczesne narzędzia programistyczne. Mój licencjonowany uniwersytet Matlab ma w folderze instalacyjnym (dla zwykłego użytkownika tylko do odczytu) następujące ilości danych:

28,5 GB Dane 30,6 GB Rozmiar na dysku Zawiera 729,246 plików i 15 000 folderów (!!!)

To jest na moim laptopie z dyskiem SSD 500 GB, gdzie partycja systemu Windows ma 200 GB.

Wiem, że Matlab jest pod tym względem nieco ekstremalny, ale wiele devtooli ma podobne właściwości: mnóstwo małych, wysoce kompresowalnych plików tekstowych (nagłówki, kod, pliki XML). Kompresuję Matlaba teraz, zanim zainstaluję devtool Intel Quartus FPGA , a Octave jest już skompresowany w następujący sposób:

1,55 GB Rozmiar danych na dysku: 839 GB Zawiera 34,362 plików 1,955 folderów

Te rzeczy są pisane raz i czytają zilliony razy podczas kompilacji projektu. Rozsądne jest poświęcenie części mocy procesora na jego dekompresję i zaoszczędzenie być może połowy cennego miejsca na dysku SSD.

Musisz wiedzieć dwa razy, żeby wiedzieć. Sprężony. Bez kompresji. Zapomnij o zużyciu dysków SSD. Potrzebujesz szybkiego SSD i procesora, aby nie występowało wąskie gardło.

Dysk SSD o pojemności 512 GB kosztuje obecnie 50 dolców. Najszybszym dostępnym dyskiem dla mnie jest do tej pory korzystanie z Linuksa i mechanizmu kolejki dyskowej LIFO. Zamiast CFQ.

Windows 10 tworzy nieskończoną aktywność dysku z 12 GB RAM zainstalowanym na moim laptopie. Później ładuje się Linux i prawie zero dostępu do dysku. Chyba że to zainicjujesz. Windows ma sposób na zajęcie się bez widocznych zadań.