* .tar.gz가 여전히 * .tar.xz보다 훨씬 더 일반적인 이유는 무엇입니까?

* .tar.gz가 여전히 * .tar.xz보다 훨씬 더 일반적인 이유는 무엇입니까?

---

GZip으로 압축 된 일부 소스 패키지 또는 바이너리를 볼 때마다 xz보다 gz를 선호하는 이유가 있는지 궁금합니다 (2000 년까지의 시간 여행 제외), LZMA 압축 알고리즘의 절약은 상당하며 압축 해제는 gzip.

---

"최저 공통 분모". 절약 된 추가 공간은 상호 운용성을 잃을 가치가 거의 없습니다. 대부분의 임베디드 Linux 시스템에는 gzip이 있지만 xz는 없습니다. 많은 오래된 시스템도 있습니다. 업계 표준 지원 플래그입니다 GNU 타르 -z을 처리 할 GZIP, 그리고 -j를 통해 프로세스 의 bzip2 , 그러나 오래된 시스템은 지원하지 않습니다 -J에 대한 플래그를 XZ 을 의미하는 2 단계 작업 (비 압축을위한 추가 디스크 공간을 많이 필요로 .tar하지 않는 한을 |tar xf -많은 사람들이 모르는 구문을 사용합니다 .) 또한 tar.gz임베디드 ARM 에서 약 10MB의 전체 파일 시스템을 압축 해제하는 데는 약 2 분이 걸리며 실제로 문제가되지 않습니다. 단서가 xz없지만bzip210-15 분 정도 걸립니다. 대역폭을 절약 할 가치가 없습니다.

---

궁극적 인 대답은 목적에 대한 두 번째 대답과 함께 접근성입니다. XZ가 반드시 Gzip만큼 적합하지 않은 이유 :

• 임베디드 및 레거시 시스템은 XZ와 같은 LZMA / LZMA2 아카이브의 압축을 풀기에 충분한 사용 가능한 메모리가 부족할 가능성이 훨씬 더 높습니다. 예를 들어 XZ가 OpenWrt 라우터 용 패키지에서 400KiB (vs. Gzip)를 줄일 수 있다면 라우터에 16MiB의 RAM이있는 경우 약간의 공간 절약이 얼마나 좋을까요? 매우 오래된 컴퓨터 시스템에서도 비슷한 상황이 나타납니다. 32MB의 RAM이 장착 된 고대 SparcStation LX에서 최신 버전의 Bash를 다운로드하고 컴파일하는 것에 대해 비웃을 수도 있지만 실제로는 발생합니다.

• 이러한 시스템은 일반적으로 프로세서가 느리고 압축 해제 시간이 매우 길어질 수 있습니다. Core i5에서 압축 해제하는 데 3 초가 더 소요되는 시간은 200MHz ARM 코어 또는 50MHz microSPARC에서 매우 길 수 있습니다. Gzip 압축은 XZ 또는 Bzip2와 같은 모든 더 나은 압축 방법과 비교할 때 이러한 프로세서에서 매우 빠릅니다.

• Gzip은 지난 20 년 동안 만들어진 모든 UNIX 계열 시스템 (그리고 거의 모든 비 UNIX 계열 시스템)에서 거의 보편적으로 지원됩니다. XZ 가용성은 훨씬 더 제한적입니다. 압축을 풀 수 없으면 압축은 쓸모가 없습니다.

• 압축률이 높을수록 시간이 많이 걸립니다. 압축 시간이 압축 비율보다 더 중요하다면 Gzip이 XZ를 능가합니다. 솔직히, lzop은 Gzip보다 훨씬 빠르며 여전히 압축이 가능하므로 가능한 가장 빠른 압축이 필요하고 Gzip의 편재성이 필요하지 않은 애플리케이션은 대신이를 살펴 봐야합니다. "tar -c * | lzop -1 | socat -u-tcp-connect : 192.168.0.101 : 4444"및 Gzip과 같은 명령을 사용하여 신뢰할 수있는 LAN 연결을 통해 정기적으로 폴더를 셔플하고 Gzip은 훨씬 느린 링크에서 유사하게 사용할 수 있습니다 ( 즉, 인터넷을 통해 SSH 터널을 통해 방금 설명한 것과 동일한 작업을 수행합니다.

이제 반대로 XZ 압축이 매우 우수한 상황이 있습니다.

• 느린 링크를 통해 데이터를 전송합니다. Linux 3.7 커널 소스 코드는 Gzip 형식보다 XZ 형식에서 34MiB 더 작습니다. 초고속 연결이있는 경우 XZ를 선택하면 다운로드 시간을 1 분 절약 할 수 있습니다. 저렴한 DSL 연결이나 3G 셀룰러 연결에서는 다운로드 시간을 1 시간 이상 단축 할 수 있습니다.

• 백업 아카이브 축소. Apache의 httpd-2.4.2 용 소스 코드를 "gzip-9"와 "xz -9e"로 압축하면 Gzip 아카이브 크기의 62.7 % 인 XZ 아카이브가 생성됩니다. 현재 100GiB 상당의 .tar.gz 아카이브로 저장하는 데이터 세트에 동일한 압축성이 존재하는 경우 .tar.xz 아카이브로 변환하면 백업 세트에서 무려 37.3GiB가 줄어 듭니다. 이 전체 백업 데이터 세트를 USB 2.0 하드 드라이브에 복사하는 데 (최대 약 30MiB / 초 전송) Gzip 데이터는 55 분이 걸리지 만 XZ 압축을 사용하면 백업에 20 분이 더 적게 걸립니다. CPU 성능이 충분한 최신 데스크톱 시스템에서 이러한 백업을 사용하고 일회성 압축 속도가 심각한 문제가 아니라고 가정하면 일반적으로 XZ 압축을 사용하는 것이 더 합리적입니다. 추가 데이터를 섞지 않는 이유

• 압축률이 높을 수있는 많은 양의 데이터 배포. 앞서 언급했듯이 Linux 3.7 소스 코드는 .tar.xz의 경우 67MiB이고 .tar.gz의 경우 101MiB입니다. 압축되지 않은 소스 코드는 약 542MiB이며 거의 전적으로 텍스트입니다. 소스 코드 (및 일반적으로 텍스트)는 콘텐츠의 중복성 때문에 일반적으로 압축률이 높지만 훨씬 더 작은 사전에서 작동하는 Gzip과 같은 압축기는 사전 크기를 초과하는 중복성을 활용하지 못합니다.

궁극적으로 압축 된 크기, 압축 / 압축 풀기 속도, 복사 / 전송 속도 (디스크 / 네트워크에서 데이터 읽기), 압축 / 압축 해제 기의 가용성이라는 4 가지 트레이드 오프로 돌아갑니다. 선택은 "이 데이터로 무엇을 할 계획입니까?"라는 질문에 크게 의존합니다.

또한 내가 여기서 반복하는 몇 가지를 배운 이 관련 게시물 을 확인 하십시오.

---

1.1GB Linux 설치 vmdk 이미지에 대한 자체 벤치 마크를 수행했습니다.

rar    =260MB   comp= 85s   decomp= 5s
7z(p7z)=269MB   comp= 98s   decomp=15s
tar.xz =288MB   comp=400s   decomp=30s
tar.bz2=382MB   comp= 91s   decomp=70s
tar.gz =421MB   comp=181s   decomp= 5s

최대 압축 수준, CPU Intel I7 3740QM, 메모리 32GB 1600, 소스 및 대상 RAM 디스크

나는 일반적으로 문서와 같은 일반 파일을 보관하기 위해 rar 또는 7z를 사용합니다.
시스템 파일을 보관하기 위해 .tar.gz 또는 .tar.xz by file-roller 또는 tar와 -z 또는 -J 옵션과 함께 --preserve를 사용하여 기본적으로 tar로 압축하고 권한을 보존합니다 (또는 .tar.7z 또는 .tar.rar 사용 가능)

업데이트 : tar는 ACL이 아닌 일반 권한 만 보존하므로 일반 .7z와 백업 및 복원 권한 및 getfacl 및 sefacl을 통해 수동으로 ACL을 사용할 수 있습니다. 이는 파일 아카이브 또는 시스템 파일 백업 모두에 가장 적합한 옵션으로 보입니다. 권한 및 ACL을 보존하고, 체크섬, 무결성 테스트 및 암호화 기능을 갖추고 있지만 단점은 p7zip을 모든 곳에서 사용할 수 없다는 것입니다.

---

Lzip 압축 유틸리티 작성자 :

Xz는 복잡한 형식을 가지고 있으며 부분적으로는 실행 파일 압축에 특화되어 있으며 독점 ​​형식으로 확장되도록 설계되었습니다. 여기에서 테스트 한 4 개의 압축기 중 xz는 "한 가지 일을 잘하고"라는 유닉스 개념의 유일한 외계인입니다. 데이터 공유에는 적합하지 않으며 장기 보관에는 전혀 적합하지 않습니다.

일반적으로 형식이 복잡할수록 나중에 디코딩 할 가능성이 낮아집니다. 그러나 xz 형식은 악명 높은 전임자 인 lzma-alone과 마찬가지로 특별히 잘못 설계되었습니다. Xz는 gzip의 거의 모든 결함을 복사 한 다음 깨지기 쉬운 가변 길이 정수와 같은 일부를 추가합니다. 하나의 가변 길이 정수의 모든 바이트의 비트 7에서 비트 플립 하나만 있으면 전체 xz 스트림이 카드 집처럼 아래로 떨어집니다. 수명이 짧은 실행 파일을 압축하는 것 이외의 다른 용도로 xz를 사용하는 것은 권장되지 않습니다.

나를 잘못 해석하지 마십시오. 나는 LZMA를 발명 / 발견 한 Igor Pavlov에게 매우 감사하지만, xz는 그의 추종자들이 7zip의 인기를 이용하고 gzip과 bzip2를 부적절하거나 잘못 설계된 형식으로 대체하려는 세 번째 시도입니다. 특히 lzma-alone에 대한 지원이 GNU와 Linux 모두에서 구현 된 것은 부끄러운 일입니다.

http://www.nongnu.org/lzip/lzip_benchmark.html

---

솔직히 저는 교육 자료에서 .xz 형식을 알게되었습니다. 그래서 방금 테스트를 수행하기 위해 git repo를 사용했습니다. git은 git : //git.free-electrons.com/training-materials.git이며 세 개의 교육 슬라이드도 컴파일했습니다. 총 디렉토리 크기는 91M이며 텍스트와 이진 데이터가 혼합되어 있습니다.

여기 내 빠른 결과가 있습니다. 압축 속도가 훨씬 빠르기 때문에 사람들이 여전히 tar.gz를 선호할까요? 개인적으로 압축에서 얻을 수있는 이점이 많지 않은 경우에도 일반 타르를 사용합니다.

[02:49:32]wujj@WuJJ-PC-Linux /tmp $ time tar czf test.tgz training-materials/

real    0m3.371s
user    0m3.208s
sys     0m0.128s
[02:49:46]wujj@WuJJ-PC-Linux /tmp $ time tar cJf test.txz training-materials/

real    0m34.557s
user    0m33.930s
sys     0m0.372s
[02:50:31]wujj@WuJJ-PC-Linux /tmp $ time tar cf test.tar training-materials/

real    0m0.117s
user    0m0.020s
sys     0m0.092s
[02:51:03]wujj@WuJJ-PC-Linux /tmp $ ll test*
-rw-rw-r-- 1 wujj wujj 91944960 2012-07-09 02:51 test.tar
-rw-rw-r-- 1 wujj wujj 69042586 2012-07-09 02:49 test.tgz
-rw-rw-r-- 1 wujj wujj 60609224 2012-07-09 02:50 test.txz
[02:56:03]wujj@WuJJ-PC-Linux /tmp $ time tar xzf test.tgz

real    0m0.719s
user    0m0.536s
sys     0m0.144s
[02:56:24]wujj@WuJJ-PC-Linux /tmp $ time tar xf test.tar

real    0m0.189s
user    0m0.004s
sys     0m0.108s
[02:56:33]wujj@WuJJ-PC-Linux /tmp $ time tar xJf test.txz

real    0m3.116s
user    0m2.612s
sys     0m0.184s

---

같은 이유로 Windows (r)의 사람들은 7zip 대신 zip 파일을 사용하고 일부는 여전히 다른 형식 대신 rar를 사용합니다 ... 또는 mp3는 음악에서 aac + 대신 사용됩니다.

각 형식에는 장점이 있으며 사람들은 컴퓨터를 사용하기 시작할 때 배운 솔루션을 고수하는 데 사용합니다. 이를 이전 버전과의 호환성과 빠른 대역폭 + 하드 드라이브의 GB 또는 TB 공간에 추가하면 더 큰 압축의 이점은 그다지 적합하지 않습니다.

---

gz는 모든 곳에서 지원되며 이식성이 좋습니다.

xz는 더 새롭고 이제 널리 또는 잘 지원됩니다. 압축 옵션이 더 많은 gzip보다 복잡합니다.

This is not the only reason people might not always use xz. xz can take a very long time to compress, not a trivial amount of time so even if it can produce superior results it might not always be chosen. Another weakness is that it can use a lot of memory, especially for compression. The more you want to compress an item by the longer it takes and this is exponential with diminishing returns.

However, at compression level 1 for large binary items in my experience xz can often produce much smaller results in less time than zlib at level 9. This can sometimes be a very significant difference, in the same time as zlib, xz can make a file that is half the size of zlib's file.

bzip2 is in a similar situation, however xz has far superior advantages and a strong window where it performs significantly better all round.

---

Also one important point for gzip is that it's interoperable with rsync/zsync. This could be huge benefit regarding bandwidth in cases. LZMA/bzip2/xz doesn't support rsync and probably won't support it anytime soon.
One of characteristics of LZMA is that it uses quiet large window. To make it rsync/zsync friendly we would probably need to reduce this window which would degrade it's compression performance.

---

Yeah the thought I had is that the original question could be reposed these days as "why is tar.gz more common than tar.lz" (since lz seems to compress slightly better than xz, xz is said to be a poor choice for archiving, though does offer some nice features like random access). I suppose the answer is "momentum" people are used to using it, there's good library support, etc.etc. The introduction of lz may mean that xz will grow less fast now, as well, FWIW...

However, that being said, lz appears to decompress slower than xz, and there are new things on the horizon like Brotli so it's unclear what will happen in terms of popularity...but I have seem a few .lz files in the wild FWIW...

참고URL : https://stackoverflow.com/questions/6493270/why-is-tar-gz-still-much-more-common-than-tar-xz