하드웨어 리소스로 넘치지 않는 즉각적인 스트림 압축?

200GB의 사용 가능한 디스크 공간, 16GB의 RAM (데스크톱 및 커널이 ~ 1GB를 점유) 및 6GB의 스왑이 있습니다.

240GB 외부 SSD가 있으며 70GB는 ^1을 사용 하고 나머지는 무료로 사용 하므로 디스크에 백업해야합니다.

일반적으로 dd if=/dev/sdb of=Desktop/disk.img디스크를 먼저 압축 한 다음 압축하지만 이미지를 먼저 만드는 것은 옵션이 아닙니다. 압축 단계로 인해 여유 공간이 찌그러 지더라도 디스크 공간이 훨씬 많이 필요하므로 최종 아카이브는 디스크에 쉽게 맞출 수 있습니다.

dd기본적으로 STDOUT에 쓰고 gzipSTDIN에서 읽을 수 있으므로 이론적으로 쓸 수 dd if=/dev/sdb | gzip -9 -는 있지만 gzip바이트를 읽는 데 비해 바이트를 읽는 데 훨씬 오래 걸립니다 dd.

보낸 사람 man pipe:

파이프의 쓰기 엔드에 기록 된 데이터는 파이프의 읽기 엔드에서 읽을 때까지 커널에 의해 버퍼링됩니다.

필자 |는 실제 파이프와 같은 것으로 시각화합니다. 하나는 데이터를 입력하고 다른 하나는 파이프 대기열에서 데이터를 가능한 빨리 가져옵니다.

왼쪽의 프로그램이 파이프의 다른 쪽에서 처리 할 수있는 것보다 더 많은 데이터를 더 빨리 쓰면 어떻게됩니까? 메모리가 많이 걸리거나 스왑 사용이 발생합니까? 아니면 커널이 디스크에 FIFO를 작성하여 디스크를 채우려 고합니까? 아니면 SIGPIPE Broken pipe버퍼가 너무 크면 실패 합니까?

기본적으로 이것은 두 가지 질문으로 요약됩니다.

1. 한 번에 읽는 것보다 더 많은 데이터를 파이프에 입력하면 어떤 영향을 미칩니 까?
2. 압축되지 않은 전체 데이터 스트림을 디스크에 넣지 않고 데이터 스트림을 디스크로 압축하는 안정적인 방법은 무엇입니까?

_{참고 1 : 사용 된 처음 70GB를 정확하게 복사 할 수 없으며 조각화 및 전체 내용을 그대로 유지 해야하는 기타 요소로 인해 작동중인 시스템 또는 파일 시스템을 얻을 것으로 예상됩니다.}

기술적으로 당신은 필요하지 않습니다 dd:

gzip < /dev/drive > drive.img.gz

당신이 사용을 할 경우 dd, 당신은 항상 같은 기본 블록 크기보다 큰 함께 이동해야 dd bs=1M하거나 콜 지옥 고통 ( dd그 이후의 기본 블록 크기는 512 바이트 read()S와 write()이다의 4096당 콜을 MiB너무 많이 오버 헤드).

gzip -9CPU를 거의 사용하지 않고 더 많은 CPU를 사용합니다. 경우 gzip당신을 아래로 둔화되고, 압축 수준을 낮추거나 다른 (빠른) 압축 방법을 사용합니다.

dd이미지 대신 파일 기반 백업을 수행하는 경우 전혀 압축할지 여부를 결정하는 논리가있을 수 있습니다 (다양한 파일 유형에 대해서는 압축 할 필요가 없습니다). dar( tar대안`)은 그렇게 할 수있는 옵션이있는 예입니다.

여유 공간이 ZERO 인 경우 (트림 후 안정적으로 0을 반환 fstrim하고 캐시를 삭제하고 삭제 한 SSD이기 때문에 ) 플래그 dd와 함께 conv=sparse사용하여 제로 영역에 제로 디스크 공간을 사용하는 압축되지 않은 루프 마운트 가능 스파 스 이미지를 만들 수 있습니다. . 스파 스 파일을 지원하는 파일 시스템에서 이미지 파일을 백업해야합니다.

또는 일부 파일 시스템의 경우 사용 된 영역 만 이미징 할 수있는 프로그램이 있습니다.

dd한 번에 한 블록 씩 데이터를 읽고 씁니다. 그래서

valgrind dd if=/dev/zero status=progress of=/dev/null bs=1M

dd약 1MB의 메모리 를 사용 하는 것을 보여줍니다 . 당신은 블록 크기로 놀아서 떨어 뜨릴 수 valgrind있으며, dd속도 에 미치는 영향을 볼 수 있습니다.

에 당신 파이프 때 gzip, dd단순히 일치 둔화 gzip의 속도를. 메모리 사용량이 증가하지 않으며 커널이 디스크에 버퍼를 저장하지도 않습니다 (커널은 스왑을 통한 경우 를 제외하고는이 를 수행하는 방법을 모릅니다 ). 부러진 파이프는 파이프 끝 중 하나가 죽을 때만 발생합니다. 참조 signal(7)및 write(2)자세한 내용은.

그러므로

dd if=... iconv=fullblock bs=1M | gzip -9 > ...

당신이 쫓는 일을하는 안전한 방법입니다.

파이핑 할 때 읽기 프로세스가 계속 진행되지 않으면 쓰기 프로세스가 커널에 의해 차단됩니다. 당신은 이것을 실행하여 이것을 볼 수 있습니다

strace dd if=/dev/zero bs=1M | (sleep 60; cat > /dev/null)

dd1MB 를 읽은 다음 실행 write()하는 동안 1 분 동안 대기 하는 것을 발행 sleep합니다. 파이프의 양쪽이 균형을 잡는 방법입니다. 쓰기 프로세스가 너무 빠르면 커널이 쓰기를 차단하고 읽기 프로세스가 너무 빠르면 읽기를 차단합니다.

성능 이외의 부정적인 영향은 없습니다. 파이프에는 일반적으로 64K 인 버퍼가 있으며 그 후 파이프에 대한 쓰기는 gzip더 많은 데이터를 읽을 때까지 단순히 차단 됩니다.

어떻게 작동하는지에 대한 실제 질문에 대답하기 : "왼쪽의 프로그램이 파이프의 다른 쪽보다 더 많은 데이터를 더 빨리 쓰면 어떻게 처리하겠습니까?"

이런 일은 일어나지 않습니다. 파이프에는 상당히 작고 제한된 크기의 버퍼가 있습니다. 참조 큰 파이프 버퍼 얼마나?

파이프 버퍼가 가득 차면 전송 프로그램이 차단 됩니다. 쓰기 호출을하면 커널은 데이터가 버퍼에 쓰여질 때까지 프로그램에 대한 제어를 반환하지 않습니다. 버퍼를 비울 수있는 읽기 프로그램 CPU 시간을 제공합니다.

파일 만 필요할 수도 있고 tar를 사용하십시오. 원하는 것을 포함하지 않는 블록을 0으로 채울 수 있습니다. 누군가 이미 그것에 대해 물었습니다. 사용하지 않는 공간을 0으로 지우십시오 (ext3, ext4)

그러면 pigz보통보다 빠릅니다 gzip.