tar 아카이브 형식이 bzip2를 대체하기 위해 xz 압축으로 전환되는 이유는 무엇이며 gzip은 어떻습니까?

배포 용 인터넷을 통한 아카이브의 경우 일반적으로 다음 사항이 우선 순위입니다.

1. 압축 비율 (즉, 압축기가 데이터를 만드는 크기)
2. 압축 해제 시간 (CPU 요구 사항) ;
3. 압축 해제 메모리 요구 사항
4. 호환성 (압축 해제 프로그램이 얼마나 널리 퍼져 있는지)

압축 메모리 & CPU 요구 사항은 매우 중요합니다. 대용량 고속 머신을 사용할 수 있고 한 번만 수행하면됩니다.

bzip2에 비해 xz는 압축률이 더 높고 압축 해제 시간이 더 짧습니다. 그러나 일반적으로 사용되는 압축 설정에서 ^[1] 의 압축을 푸는 데 더 많은 메모리가 필요하며 덜 널리 퍼집니다. Gzip은 둘 중 하나보다 적은 메모리를 사용합니다.

따라서 gzip 및 xz 형식 아카이브가 모두 게시되어 다음을 선택할 수 있습니다.

• 이있는 컴퓨터에서 압축을 풀어야합니다. 매우 제한된 메모리 (< 32MB) : gzip. 커널 소스에 대해 이야기 할 때 그다지 가능성이 낮습니다.
• 사용 가능한 최소한의 도구를 압축 해제해야합니다. gzip
• 다운로드 시간 및 / 또는 대역폭을 절약하려는 경우 : xz

bzip2를 선택하게 만드는 요소의 실제적인 조합은 없습니다. 따라서 단계적으로 중단되었습니다.

블로그 게시물 에서 압축 비교를 살펴 보았습니다. 나는 결과를 복제하려고 시도하지 않았고 그 중 일부가 변경된 것 같습니다 (대부분 xz가 최신 버전이므로 개선 될 것으로 예상합니다.)

(좋은 bzip2 구현이 xz보다 선호 될 수있는 몇 가지 특정 시나리오가 있습니다. bzip2는 xz보다 많은 0과 게놈 DNA 시퀀스가있는 파일을 압축 할 수 있습니다. 이제 xz의 최신 버전에는 데이터를 허용하는 (선택 사항) 블록 모드가 있습니다. 손상 지점 및 병렬 압축 및 [이론상] 압축 해제 후 복구. 이전에는 bzip2에서만 이러한 기능을 제공했습니다. ^[2] 그러나 이들 중 어느 것도 커널 배포와 관련이 없습니다.

1 : 아카이브 크기에서 xz -3는 약 bzip -9입니다. 그러면 xz는 압축 해제에 더 적은 메모리를 사용합니다. 그러나 xz -9 (예 : Linux 커널 타르볼에 사용됨)는 bzip -9보다 훨씬 더 많이 사용합니다 (또한 xz -0 gzip -9 이상 필요).

2 : F21 시스템 전체 변경 : 기본 bzip2 구현으로 lbzip2

댓글

• 다음 주제에 대한 모든 댓글 내결함성 아니면 ' 항상 압축 알고리즘 외부에서 완전히 구현되는 것입니까?
• @illumin É 복원력은 압축 비율을 희생하지 않고는 ' 제공 할 수 없습니다. '는 직교 문제이며 Parchive와 같은 도구가 존재하지만 커널 TCP 배포를위한 '의 오류 처리는 다음과 같은 작업을 수행합니다. 음.
• @illumin É 내결함성 (par2와 유사한 것을 의미한다고 가정)은 일반적으로 ' 인터넷을 통한 아카이브 배포에 대한 우려. 다운로드는 충분히 신뢰할 수있는 것으로 간주됩니다 (손상된 경우 다시 다운로드 할 수 있음). 암호화 해시 및 서명이 자주 사용되며 손상 및 변조를 감지합니다. 압축 비율을 희생하더라도 더 큰 내결함성을 제공하는 압축기가 있습니다. 아무도 HTTP 또는 FTP 다운로드에 대한 절충안을 찾지 못하는 것 같습니다.
• xz는 압축을 풀기 위해 적은 메모리를 사용합니다.
• @Mike이 글을 쓴 이후로 변경 되었습니까? 특히 각주 1은 메모리 사용량을 설명합니다.

우선이 질문은 직접적인 관련이 없습니다. tar로. Tar는 압축되지 않은 아카이브를 생성 한 다음 나중에 압축을 적용합니다.

Gzip은 LZMA2 및 bzip2와 비교할 때 상대적으로 빠른 것으로 알려져 있습니다. 속도가 중요한 경우 gzip (특히 다중 스레드 구현 pigz ) 종종 압축 속도와 압축 비율 사이의 좋은 절충안입니다. 속도가 문제인 경우 대안이 있지만 (예 : LZ4).

그러나 높은 압축률을 원하는 경우 LZMA2는 거의 모든 측면에서 bzip2보다 높습니다. 압축 속도는 종종 느리지 만 훨씬 더 빠르게 압축을 풀고 더 높은 메모리 사용량으로 훨씬 더 나은 압축 비율을 제공합니다.

bzip2 이전 버전과의 호환성을 제외하고 더 이상. 또한 LZMA2는 멀티 스레딩을 염두에두고 설계되었으며 기본적으로 많은 구현에서 멀티 코어 CPU를 사용합니다 (불행히도 Linux의 xz는 아직이를 수행하지 않습니다). 이는 클럭 속도가 더 이상 증가하지 않지만 코어 수가 증가하기 때문에 의미가 있습니다.

다중 스레드 bzip2 구현이 있습니다 (예 : pbzip ), 기본적으로 설치되지 않는 경우가 많습니다. 또한 다중 스레드 bzip2 LZMA2와 달리 파일이 단일 스레드 bzip2를 사용하여 압축 된 경우 압축 해제는 단일 스레드를 사용하는 반면 압축 동안에 만 실제로 효과가 있습니다. 병렬 bzip2 변형은 파일이 병렬 bzip2 버전을 사용하여 압축 된 경우에만 멀티 코어 CPU를 활용할 수 있습니다. 이는 종종 그렇지 않습니다.

댓글

• 일부 tars는 z 옵션을 제공합니다.
• " speed " 답은 혼란 스럽습니다. 압축 속도 또는 압축 해제 속도를 참조해야합니다. pixz, pbzi 모두 p2 또는 pigz는 기본적으로 설치되지만 (또는 -I 플래그없이 tar에서 사용됨), pixz 및 pbzip2는 압축 및 압축 해제 속도를 높이고 pigz는 압축 전용입니다.
• @Tobu xz는 기본적으로 멀티 스레드되므로 향후 pixz 설치가 필요하지 않습니다. 일부 플랫폼에서는 xz 스레딩이 이미 지원됩니다. 반면 bzip2는 멀티 스레딩을 염두에두고 설계되지 않았기 때문에 ' 형식이 멀티 스레드 될 가능성이 거의 없습니다. 또한 pbzip2는 종종 그렇지 않은 pbzip2를 사용하여 파일을 압축 한 경우에만 압축 해제 속도를 높입니다.
• @Marco 저는 lbzip2가 파일이 병렬이 아닌 구현 (예 : stock bzip2)으로 압축 된 경우에도 파일의 병렬 압축 해제를 허용한다고 믿습니다. 이것이 ' pbzip2보다 lbzip2를 사용하는 이유입니다. (귀하의 의견 이후로 '이 (가) 발전했을 가능성이 있습니다.)
• This makes sense since the clock speeds won't increase any more -뭐라고 요? ' 사실이 아닙니다. 이 게시물은 인텔이 3.8GHz에서 i3-4370을 출시 한 2014 년에 작성되었습니다. 2017 년 Intel은 4.7GHz로 i7-8700K를 출시했습니다. 2018 년에는 5GHz에서 i9-9900K를 출시했으며 ' 아마도 2015 년에 & 2016 년에 '도이 목록에서 누락되었습니다.

LZMA2는 블록 압축 시스템이지만 gzip은 아닙니다. 이것은 LZMA2가 멀티 스레딩에 적합하다는 것을 의미합니다. 또한 아카이브에서 손상이 발생하면 일반적으로 LZMA2를 사용하여 후속 블록에서 데이터를 복구 할 수 있지만 gzip으로는이를 수행 할 수 없습니다. 실제로는 손상된 블록에 이어 gzip으로 전체 아카이브를 잃게됩니다. LZMA2 아카이브를 사용하면 손상된 블록의 영향을받은 파일 만 손실됩니다. 이것은 여러 파일이있는 더 큰 아카이브에서 중요 할 수 있습니다.

댓글

• 이것은 실제로 매우 유용하고 중요한 차이점입니다!
• 이러한 주장을 출처로 뒷받침 할 수 있습니까? 나는 아직 XZ 복구 도구를 보지 못했으며 알려진 소스는 그렇지 않으면 다음과 같이 주장합니다. nongnu.org/lzip/xz_inadequate.html

짧은 답변 : xz는 압축비 측면에서 더 효율적입니다. 따라서 디스크 공간을 절약하고 네트워크를 통한 전송을 최적화합니다.
이 빠른 벤치 마크 를 확인하여 실제 테스트를 통해 차이점을 발견 할 수 있습니다.

댓글

• 링크가 끊어졌습니다.
• 새 링크 : catchallenger.first -world.info/wiki/…