SSD의 NTFS 압축-기복

이 항목 에서는 디스크 액세스 성능을 향상시키는 방법으로 HDD의 NTFS 압축에 대해 설명하고 자주 디스크의 성능이 나쁘다는 결론을 내립니다. 그러나 나는 항상 공간을 절약하기위한 방법으로 압축을보고 그 점에서 그 효과를 배웠습니다. 이제 공간이 비싸고 1 클러스터 대신 2 클러스터 읽기 / 쓰기에 대한 성능 저하가 발생하는 SSD가 있습니다.

반면에 SSD는 HDD보다 훨씬 빠르기 때문에 처리량이 많을수록 CPU 사용량이 높아질 것으로 기대합니다. 이것이 문제가 될 수 있습니까? 그 문제에 대한 다른 생각?

나는 공간 절약 효과가 마음에 들지만, 크지는 않지만 거기에 있습니다. 그러나 성능이 문제가되는 경우에는 오히려 끄십시오.

Microsoft 는 이것을 블로그에 얼마 전에 썼습니다 .

NTFS는 데이터 스트림을 CU로 나누어 파일을 압축합니다 (이는 스파 스 파일의 작동 방식과 유사합니다). 스트림 내용이 생성되거나 변경되면 데이터 스트림의 각 CU가 개별적으로 압축됩니다. 압축으로 인해 하나 이상의 클러스터가 줄어들면 압축 된 장치는 압축 된 형식으로 디스크에 기록됩니다. 그런 다음 정렬 목적을 위해 희소 한 VCN 범위가 압축 된 VCN 범위의 끝에 고정됩니다 (아래 예 참조). 데이터가 하나의 클러스터로 크기를 줄일만큼 충분히 압축되지 않으면 전체 CU가 압축되지 않은 형태로 디스크에 기록됩니다.

이 디자인은 파일에서 단일 VCN에 액세스하기 위해 하나의 CU 만 압축 해제하면되므로 임의 액세스가 매우 빠릅니다. 불행히도 많은 CU의 압축 풀기가 순차적 작업 (예 : 백업)을 수행해야하므로 대규모 순차 액세스가 상대적으로 느려집니다.

그리고 KB 기사에서 이것을 씁니다 .

NTFS 파일 시스템 압축은 디스크 공간을 절약 할 수 있지만 데이터 압축은 성능에 부정적인 영향을 줄 수 있습니다. NTFS 압축에는 다음과 같은 성능 특성이 있습니다. 압축 된 NTFS 파일을 다른 폴더로 복사하거나 이동하면 NTFS가 파일의 압축을 풀고 파일을 새 위치로 복사하거나 이동 한 다음 파일을 다시 압축합니다. 이 문제는 파일이 같은 컴퓨터의 폴더간에 복사되거나 이동 된 경우에도 발생합니다. 네트워크를 통해 복사하기 전에 압축 파일도 확장되므로 NTFS 압축으로 네트워크 대역폭을 절약 할 수 없습니다.

NTFS 압축은 프로세서를 많이 사용 하기 때문에 프로세서가 자주 사용되는 서버에서 성능 비용이 더 두드러집니다. 쓰기 트래픽이 많은로드가 많은 서버는 데이터 압축에 적합하지 않습니다. 그러나 읽기 전용, 대부분 읽기 또는 약간로드 된 서버에서는 성능이 크게 저하되지 않을 수 있습니다.

트랜잭션 로깅을 사용하고 지속적으로 데이터베이스 나 로그에 쓰는 프로그램을 실행하는 경우 압축되지 않은 볼륨에 파일을 저장하도록 프로그램을 구성하십시오. 프로그램이 압축 파일의 매핑 된 섹션을 통해 데이터를 수정하면 매핑 된 작성자가 쓸 수있는 것보다 더 빠른 "더티"페이지를 생성 할 수 있습니다. 이 문제로 인해 Microsoft Message Queuing (MSMQ라고도 함)과 같은 프로그램이 NTFS 압축에서 작동하지 않습니다.

사용자 홈 폴더와 로밍 프로필은 많은 읽기 및 쓰기 작업을 사용하므로 사용자 홈 폴더와 로밍 프로필은 부모 폴더 나 볼륨 루트에 NTFS 압축이없는 볼륨에 배치하는 것이 좋습니다.

요약:

읽기 속도가 빠르기 때문에 절대로 변경되지 않는 (읽기만하고 쓰기는하지 않는) 작은 파일 만 압축하지만 쓰기에는 압축 해제가 필요하고 CPU 압축을 필요로하는 새로운 압축이 필요하며 스토리지 유형은 그다지 중요하지 않습니다.

Claudio가 많은 것들을 자세히 말하면서, 나는 또한 내 자신의 의견을 다시 시작할 것입니다. 나는 그가 말한 것을 시도한 후에도 같은 효과를 보았습니다.

SSD의 경우 NTFS 압축을 사용하지 않아야합니다.

이제 나는 그런 긍정에 대한 동기를 열거 할 것입니다 :

동기 Nº1 : 두 번 쓰기 때문에 SSD musch를 더 빨리 종료합니다. NTFS 압축은 RAM에서 압축을 시작하기 전에 압축되지 않은 데이터를 기록한 다음 압축 된 데이터가 4KiB 이상인 경우에만 다시 기록합니다.

동기 Nº2 : SSD에서 NTFS 4KiB 클러스터를 사용하면 SSD 속도의 50 %가 떨어지고 벤치 마크를 확인하며 128KiB 블록이 4KiB 블록을 사용하는 것보다 SSD가 두 배 더 빠르며 NTFS 압축은 4KiB 클러스터 NTFS 파티션에서만 사용할 수 있습니다.

Motive Nº3 : 플라이 압축 및 / 또는 암호화에서 볼 수있는 컨테이너를 생성 할 수있는 컨테이너 (예 : PISMO File Mount)가 있습니다. 이러한 컨테이너는 RAM에서 압축을 수행하고 다시 쓰기 전에 압축되지 않은 데이터를 디스크로 보내지 않습니다. 압축 형식의 경우 PISMO는 NTFS보다 압축률이 높습니다.

더 많은 동기가 있지만 가장 중요한 동기입니다.

otrer 포인트는 SPEED이며 CPU에서 모든 컴파일이 수행되므로 매우 빠른 CPU가 없으면 (일부 컨테이너에서 멀티 스레드가 사용되는 동안 NTFS에서 모노 스레드가 사용됨) 읽기 / 쓰기 속도가 매우 느림 압축 될 때; 최악의 경우 CPU가 매우 빠를 수 있지만 렌더링, 코드 변환 등과 같은 다른 용도로 사용중인 경우 압축에 CPU가 남아 있지 않으므로 성능이 저하됩니다.

NTFS 컴파일은 CPU를 많이 사용하지 않으면 기존의 느린 디스크에만 적합하지만 각 64KiB 블록 (압축 여부에 관계없이)은 64KiB의 배수 위치에 기록되기 때문에 각 쓰기 후 (파일 수준에서) 우수한 조각 모음이 필요합니다. 이러한 조각을 압축하는 유일한 방법은 압축 후 (또는 압축 된 폴더에 쓰기) 해당 파일의 조각 모음을 수행하는 것입니다.

PD : 가상 머신이 아닌 실제 하드웨어의 Windows에 대해 이야기하고 있습니다. 중요한 것은 물리적 매체에 쓰는 사람입니다. 다른 매체에는 효과를 완화하고 많은 것을 개선 할 수있는 캐시 계층이있을 수 있습니다.

SSD 이외의 시장 문제에 대해서는 아무도 이야기하지 않습니다. 단편화입니다.

각 64KiB 블록은 압축되지 않은 위치에 작성되지만 압축 할 수 있으므로 적어도 <= 60KiB 인 다음 64KiB 미만을 기록하며 비트 네스트 블록은 이전 블록이 아닌 것처럼 이동합니다. 압축하면 많은 간격이 생깁니다.

모든 Windows 시스템의 virtusl 시스템의 멀티 기가 바이트 파일로 테스트하십시오 (50 %로 감소하는 경향이 있지만 거대한 10000 조각).

그리고 SSD의 경우 알려지지 않은 내용이 있습니다. 도대체 어떻게 작성합니까? 압축되지 않은 상태로 쓴 다음 압축 된 버전 (각 64KiB 메가 블록 당)으로 덮어 쓰면 SSD 수명이 크게 단축됩니다. 그러나 압축 된 형식으로 직접 쓰면 SSD live가 짧아 지거나 짧아 질 수 있습니다 .64KiB를 한 번에 한 번만 쓰면 더 길고 짧아집니다 .64KiB를 4KiB로 쓰면 더 짧아집니다. 이러한 64KiB (압축 된 형태)는 64 / 4 = 16 배이다.

압축 / 압축 해제에 필요한 CPU 시간이 4KiB 블록을 쓸 필요가없는 시간보다 커지기 때문에 성능이 저하됩니다. 따라서 매우 빠른 CPU와 매우 느린 디스크 압축을 사용하면 쓰기 및 읽기 시간이 단축되지만 SSD가 매우 빠르며 CPU 속도가 매우 느리면 훨씬 느리게 쓰게됩니다.

내가 빠르거나 느린 CPU에 대해 이야기 할 때 나는 그 순간 CPU가 '수학'이나 다른 프로세스에 의해 사용될 수 있으므로 항상 CPU의 사양이 아니라 무료 CPU에 대해 생각하고 디스크 / SSD에 대해서도 마찬가지입니다. 여러 프로세스에서 사용 중입니다.

7Zip이 LZMA2를 사용하여 다른 디스크에서 거대한 파일을 작성한다고 가정하면 많은 CPU를 사용하므로 NTFS 압축 파일을 복사하는 경우 CPU 여유 공간이 없으므로 NTFS가없는 것보다 느리게 진행됩니다 압축은 가능하지만 CPU를 사용하는 7Zip이 종료 되 자마자 이러한 CPU는 NTFS 압축 속도가 빨라지고 NTFS 압축 속도가 빨라집니다.

개인적으로 나는 NTFS 압축을 사용하지 않으며 PISMO 파일 마운트 PFO 컨테이너를 선호합니다 (압축 기능을 사용하고 응용 프로그램에 투명하고 투명하게 암호화 할 수 있음). 사용하기 전에 압축을 풀 필요가 없으며 읽기 및 쓰기 모드로 마운트하여 사용하십시오.

PISMO는 디스크에 쓰기 전에 RAM을 압축하기 때문에 SSD를 더 오래 사용할 수 있습니다. NTFS 압축 테스트를 통해 데이터를 디스크에 두 번 전송 한 다음 압축하지 않은 것으로 생각합니다. .

SSD의 NTFS 압축 쓰기 속도가 파일 크기가 1/2 인 압축 파일보다 1/2 또는 더 작은 압축 크기의 압축되지 않은 파일의 1/2에 가까운 이유는 무엇입니까? 128GiB의 RAM (빠른 CPU, 매우 빠른 CPU)을 사용하는 AMD Threadripper 2950 (32 코어 및 64 스레드)에서 1 % 미만으로 사용하므로 SSD 최대 보안 속도보다 빠르게 압축 할 CPU가 충분합니다. 64KiB 블록이 압축되지 않은 디스크로 전송 된 다음 압축 된 버전으로 덮어 쓴 후 NTFS 압축이 시작됩니다. 오, 호스트에서 Linux를 실행하고 게스트에서 Windows를 실행하는 가상 시스템에서 수행하면 Linux 캐시에서 해당 클러스터가 두 번 작성됩니다 속도가 훨씬 빠릅니다 (리눅스는 Windows 게스트가 보낸 압축되지 않은 NTFS 쓰기를 캐싱하고 압축 된 데이터로 덮어 쓴 후 압축되지 않은 데이터를 디스크로 보내지 않습니다)

내 추천은 호스트가 Linux 인 경우 가상 머신 내부에서 창을 실행하고 CPU가 충분히 빠르지 않은 경우 CPU를 많이 사용하지 않는 경우를 제외하고 NTFS 압축을 사용하지 마십시오.

최신 SSD에는 내부 램 캐시가 크므로 NTFS 내부 압축 시스템으로 인해 NTFS 압축으로 인한 쓰기 / 과량 초과를 완화 할 수 있습니다.

내 테스트는 SSD 내부에 캐시를위한 내부 RAM이없는 "예쁜"SSD에서 수행되었습니다. 램 캐시가있는 캐시에서 반복 할 때 쓰기 속도는 빠르지 만 생각보다 빠릅니다.

자체 테스트를 수행하고 큰 파일 크기를 사용하십시오 (캐시 숨겨진 결과를 피하기 위해 설치된 총 tam보다 큼).

그건 그렇고, 일부 사람들은 NTFS vompression에 대해 알지 못하는 것입니다 .4KiB 이하의 파일은 적어도 4KiB의 크기를 줄일 수있는 방법이 없기 때문에 절대로 NTFS 압축을 얻지 못할 것입니다.

NTFS 압축은 64KiB의 압축을 취하고 압축하며 하나의 클러스터 (4KiB)를 줄일 수 있으면 압축으로 기록되고 64KiB는 4KiB의 16 블록 (연속)입니다.

압축이 종료 될 때 8KiB의 파일이 최종 결과가 4KiB를 초과하면 클러스터를 저장하지 않으므로 압축되지 않은 상태로 작성됩니다. 등 ... 노출은 4KiB 이상이어야합니다.

아, 그리고 NTFS 압축의 경우 NTFS 크기는 4KiB이어야합니다.

시험해보기 : SSD의 NTFS에서 128KiB 클러스터를 사용하면 읽기 속도를 크게 향상시킬 수 있습니다.

4KiB 클러스터가 장착 된 SSD의 파일 시스템은 대부분 50 % 이상 손실되는 속도를 잃고 있습니다. 512Bytes에서 2MiB까지 다양한 블록 크기로 테스트하는 벤치 마크를 확인하십시오. 64KiB (또는 128KiB) 클러스터 크기에서 4KiB보다 속도가 빠릅니다.

SSD를 실제로 사용하고 싶으십니까? 파일 시스템에서 4KiB 클러스터를 사용하지 말고 128KiB를 사용하십시오.

파일의 99 % 이상이 128KiB 미만인 경우에만 4KiB 클러스터를 사용하십시오.

기타 등등 .. 자신의 사례를 테스트, 테스트 및 테스트하십시오.

참고 : 128KiB 클러스터가있는 Windows 또는 다른 Windows에서 Windows를 설치하는 동안 콘솔 모드에서 diskpart를 사용하여 시스템 NTFS 파티션을 작성하지만 설치 프로그램 그래픽 파트 (Windows는 항상 4KiB 클러스터 NTFS로 형식화 함)에 Windows를 포맷하지 마십시오.

내 모든 Windows는 이제 400GiB SSD (SLC)의 128KiB 클러스터 NTFS 파티션에 설치됩니다.

M $는 iy가 NTFS 압축을 어떻게 쓰는지 말하지 않기를 바라며, 테스트 결과, 한 번이 아니라 두 번 (64KiB 비 압축, <= 60KiB 완료) (SSD의 경우주의해야 함)라고 알려줍니다.

주의 : NTFS 압축은 4KiB와 다른 NFTS 클러스터 크기를 가진 경우 NTFS 압축이 4KiB 클러스터 크기 NTFS 파티션에서만 작동하므로 Windows는 일부 내부 디렉토리를 NTFS로 압축하려고 시도합니다.

다른 사람들의 의견을보고, 사람들이 종종 NTFS 파일 / 폴더 압축이 SSD에서 큰 이점을 갖는 가장 유용한 시나리오 인 현대 개발 도구를 잊어 버린 것 같습니다. 내 대학 라이선스 matlab에는 다음과 같은 데이터 양 폴더의 (일반 사용자가 읽기 전용) 설치에 있습니다 :

28.5 GB 데이터 30.6 GB 디스크 크기 729.246 파일과 15.000 폴더 (!!!)

이것은 500GB SSD가 장착 된 랩톱에 있으며 Windows 파티션은 200GB입니다.

Matlab이 이와 관련하여 약간 극단적 인 것을 알고 있지만 많은 devtools는 비슷한 특성을 가지고 있습니다. 작고 압축률이 높은 텍스트 파일 (헤더, 코드, XML 파일). Intel Quartus FPGA devtool을 설치하기 전에 Matlab을 압축 하고 있으며 Octave 는 이미 다음과 같이 압축되어 있습니다.

디스크의 1.55GB 데이터 크기 : 839GB 34.362 파일 포함 1.955 폴더

이 내용은 한 번 작성되며 프로젝트 빌드 중 수십억 번 읽습니다. 압축을 풀고 귀중한 SSD 공간의 절반을 절약하기 위해 약간의 CPU 전력 을 소비 하는 것이 완벽 합니다.

알기 위해서는 벤치 마크를 두 번해야합니다. 압축. 비 압축. SSD의 마모를 잊어 버리십시오. 병목 현상이 발생하지 않도록 빠른 ssd 및 CPU가 필요합니다.

512GB의 SSD는 요즘 50 달러입니다. 지금까지 가장 빠른 디스크 액세스는 가능한 Linux 및 LIFO 디스크 큐 메커니즘을 사용하는 것입니다. CFQ보다는.

Windows 10은 랩톱에 12GB 램이 설치되어 무한한 디스크 활동을 만듭니다. Linux 민트가로드되고 거의 0에 가까운 디스크 액세스가 발생합니다. 시작하지 않으면 Windows는 눈에 띄는 작업없이 바쁘게 지낼 수 있습니다.