많은 파일과 폴더가 포함된 크고 무거운 폴더 트리가 있습니다. 압축하여 저장 용량을 줄이고 싶습니다. 이 트리는 자주 사용되지는 않지만 나중에 트리를 탐색하고 여기에서 특정 파일 한두 개를 추출해야 할 것 같습니다.
따라서 전체 트리가 포함된 거대한 압축 tar 파일을 갖고 싶지 않습니다. 그러면 나중에 탐색하기가 매우 어려워지고 파일을 추출하려면 모든 항목의 압축을 풀어야 하기 때문입니다. 맞습니까? 또한 tar 파일이 준비되고 원본 트리를 삭제할 수 있을 때까지 두 배의 공간이 필요합니다.
그래서 bz2나 xz 같은 것을 사용하고 각 파일을 개별적으로 압축하고 싶습니다. 하지만, 하위 폴더에 작고 비슷한 파일이 많다면, 각 파일을 압축하는 것은 모든 파일을 하나의 tar 파일로 모아서 압축하는 것만큼 효과적이지 않을 것 같은데... 그렇죠? (압축할 정보가 더 있으면 압축기가 더 많은 중복성을 찾을 수 있다고 가정합니다.)
그래서 내가 무엇을해야하니?
최적의 압축을 위해 파일을 모으는 아이디어는 나중에 정보를 쉽게 탐색하고 추출하기 위해 별도로 저장한다는 아이디어와 반대됩니다. 중간점을 선택하는 도구나 권장 방법이 있나요? 예를 들어, 모든 최종 폴더(트리의 각 분기 끝에 있는 폴더)를 검색하고 먼저 해당 내용을 tar로 압축한 다음 압축한 다음 위의 깊이까지 계속해서 반복해야 합니까?
편집: 테스트 케이스
단일 파일에 사용되는 압축 과 모든 파일에 사용되는 압축을 xz비교했습니다 7z. 테스트 케이스는 58000.66M의 폴더 트리로 구성되어 있으며, 그 안에 1250397개의 파일이 4290개의 디렉터리로 분류되어 있습니다. 모든 것을 압축한 후:
find . -type f -print0 | xargs -0 xz
나는 14576.68M을 얻습니다. 그러나 전체 트리를 압축하면 7z거의 5GB가 적은 9622.74M을 얻게 됩니다.
답변1
...파일을 추출하려면 모든 항목의 압축을 풀어야 합니다...그렇죠?
tar를 피하는 경우에는 그렇지 않습니다. 파일 이름을 검색하고 아카이브에서 개별 파일을 추출하는 것은 쉽습니다(.zip, .7z의 경우 빠름). 예;
> du -h a.*
223M a
115M a.tar.gz
75M a.7z
> 7z l a.7z | wc -l
2253
> ( time 7z l a.7z >/dev/null ) 2>&1 | grep user
user 0m0.014s
> ( time tar -ztf a.tar.gz >/dev/null ) 2>&1 | grep user
user 0m2.055s
...각 파일을 압축하는 것은 모든 파일을 하나의 tar 파일로 통합한 다음 압축하는 것만큼 효과적이지 않습니다. 맞죠?
옳은.
첫 번째 의견은 7z는 멀티스레드이고 인덱스화되어 있지만 tar.xz는 그렇지 않기 때문에 성능에 큰 차이가 있다는 것입니다.
하지만 실제로는 압축을 위해 파일 시스템이나 장치 매퍼만 사용합니다.
vdo create --name=vdo_volume --device=/dev/vda
압축 파일 시스템; https://en.m.wikipedia.org/wiki/Category:압축 파일 시스템 예를 들어
mount -t btrfs -o compress=lzo /dev/sdb /media/my_compressed_files
이 두 작업은 모두 루프백 장치에서 수행될 수 있으므로 파일 내의 전체 파일 시스템처럼 작동합니다.
데이터 검색 속도는 빠르지만 쓰기 성능이 형편없는 퓨즈-7z-ng와 같은 일부 아카이브 퓨즈 드라이버도 있습니다.
fuse-7z-ng files.7z /media/my_compressed_files
답변2
tar이 옵션을 사용하면 -tvfgzip, bzip2 또는 xz와 같은 다른 라이브러리와 결합하여 tar로 생성된 모든 아카이브의 내용을 나열할 수 있습니다.
tar -tf file.tar
tar -ztf file.tar.gz
tar -jtf file.tar.bz2
tar -Jtf file.tar.xz
콘텐츠를 나열하면 아카이브에서 추출하려는 파일을 구체적으로 식별한 다음 특정 경로를 사용하여 파일을 추출할 수 있습니다.
당신의 경로가 이라고 가정합니다 home/user/old/photos/beach2012/bigbeachball.jpg.
tar -xf file.tar home/user/old/photos/beach2012/bigbeachball.jpg
tar -zxf file.tar.gz home/user/old/photos/beach2012/bigbeachball.jpg
tar -jxf file.tar.bz2 home/user/old/photos/beach2012/bigbeachball.jpg
tar -Jxf file.tar.xz home/user/old/photos/beach2012/bigbeachball.jpg
아카이브가 많이 변경되지 않는 경우(예: 파일을 자주 추가하거나 제거하지 않는 경우) 언제든지 콘텐츠를 텍스트 파일로 추출할 수 있습니다. grep으로 검색할 수 있는 텍스트 파일에 내용을 배치하면 검색할 때마다 아카이브를 처리하는 것보다 파일을 더 쉽게 찾을 수 있습니다.
답변3
나는 이것에 매우 관심이 있었고 다음과 같이 내가 조사한 몇 가지 옵션이 있습니다.
호박 파일 시스템
스쿼시데이터를 보관하고 압축할 수 있지만 나중에 압축되지 않은 것처럼 탐색할 수 있도록 파일 시스템으로 마운트할 수 있습니다.
mksquashfs some/directory dir.squashfs
mkdir mnt
sudo mount -t squashfs dir.squashfs mnt
이는 루트로만 실행할 수 있으며 Linux에서만 실행할 수 있습니다. 하지만퓨즈를 짜내다FUSE 지원 시스템에서 루트가 아닌 사용자로 이 작업을 수행할 수 있습니다.
픽셀
누군가가 이미 언급했어요픽셀- 하지만 단지 xz를 병렬화한 것은 아닙니다. 또한파일 인덱스아카이브를 압축하여 소규모 작업을 보다 효율적으로 만듭니다. 예를 들어:
# Listing files, and extracting a single file, using normal tar + xz
# So slow, not practical for interactive use.
$ time tar -tf 8gigs.tpxz > /dev/null
371.99s user 5.45s system 99% cpu 6:21.00 total
$ time tar -xf 8gigs.tpxz dir/somefile.txt
375.04s user 5.45s system 99% cpu 6:21.00 total
# Using pixz instead it's much faster!
$ time pixz -l < 8gigs.tpxz > /dev/null
0.01s user 0.01s system 38% cpu 0.035 total
$ time pixz -x dir/somefile.txt < 8gigs.tpxz | tar x
0.33s user 0.02s system 97% cpu 0.359 total
부인 성명
나는 pixz와 squashfuse를 썼습니다. 나에게도 당신과 같은 문제가 있었기 때문입니다.