ArchiveMount에 대한 빠른 대안?


15

현재 ArchiveMount3 백만 개가 넘는 파일이 들어있는 123,000KB 아카이브를 마운트하는 데 사용 하고 있습니다. 지금까지 5 시간 이상 마운트되어 있지만 아직 완료되지 않았습니다.

.tar.gz파일 을 마운트하는 더 좋은 방법이 있습니까? 폴더에 마운트하려고하는데 압축되지 않은 경우 몇 개의 공연이 필요합니다. 쓰기 모드가 필요하지 않으며 읽기 전용이면 충분합니다.


AVFS있습니다 . 그것이 더 잘 수행 될지 모르겠습니다.
Gilles 'SO- 악마 중지

8
파일이 tarball이 아닌 squashfs 모듈로 압축 된 경우 읽기 전용 액세스가 매우 빠릅니다. squashfs 모듈을 (루프) 마운트하면됩니다. squashfs-tools 패키지가 필요합니다.
dru8274

나는 현재 그러한 파일 시스템을 프로그래밍하고 있습니다. 몇 달을 기다리면 거기에 갈 것입니다.
FUZxxl

@FUZxxl 2 년이 지난 지금이 ​​유틸리티를 작성한 적이 있습니까?
cybernard

@cybernard FUSE는 내가이 프로젝트를 포기했을 정도로 나를 좌절시켰다. 나는 문서화되지 않은 똥이 싫어. 나는 이것을 버너에 유지하고 나중에 다시 가져갈 수 있습니다.
FUZxxl

답변:


7

압축 된 스쿼시 이미지를 만들 수도 있습니다

mksquashfs /etc squashfs.img -comp xz
mkdir img
mount -o squashfs,ro squashfs.img img

이렇게하려면 tar.gz archvie를 추출해야합니다.

장점은 이미지가 gz보다 내결함성이 더 우수하다는 것입니다.


6

여기서 문제는 형식에있어 TAR (Tape ARchive) 형식은 무작위 액세스가 아닌 순차적 액세스를 위해 설계되었습니다. gzip은 tar에 대한 좋은 보완책입니다. 스트림 기반 압축 형식이므로 임의 액세스가 아닙니다.

따라서 압축 블록과 직접 상호 작용하지 않는 고급 도구는 무엇이든 읽을 때마다 전체 파일을 구문 분석해야합니다. 먼저 파일 목록을 얻으려면 캐시가 무효화되고 다시 읽습니다. 그런 다음 복사 한 각 파일에 대해 다시 읽을 수 있습니다. 각 파일의 위치와 파일을 얻기 위해 압축 해제해야하는 블록을 기억하는 도구를 만들 수 있지만 그로 인해 어려움을 겪은 사람은 거의 없습니다.

이 작업을 더 빠르게하려면을 수행하고 vim , gedit 등으로tar tzf file.tar.gz > filelist 해당 파일 목록을 열고 필요없는 파일 줄을 제거하고 저장 한 다음로 추출하십시오 .tar xzf file.tar.gz -T filelist -C extracted/

압축 파일에 무작위로 액세스하려면 posix 확장명, rar 또는 dru8274에서 제안한대로, sshshfs 또는 압축이 설정된 ZFS 또는 btrfs가 읽을 때 압축되도록 설정 한 경우 btrfs와 함께 zip을 사용해야합니다.


3
압축 파일에 무작위로 액세스하려면 pixz를 사용할 수도 있습니다.
kubanczyk 2016 년

6

나는 이 문제가 계속 나를 괴롭히기 때문에 "나에게 효과적"인 더 빠른 대안 ratarmount을 썼다 .

다음과 같이 사용할 수 있습니다.

pip3 install --user ratarmount
ratarmount my-huge-tar.tar mount-folder
ls -la mount-folder # will show the contents of the tar top-level

완료되면 FUSE 마운트와 같이 마운트를 해제 할 수 있습니다.

fusermount -u mount-folder

왜 archivemount보다 빠릅니까?

그것은 무엇을 측정 하느냐에 달려 있습니다.

다음은 간단한 cat <file-in-tar>명령과 간단한 명령에 대한 액세스 시간뿐만 아니라 메모리 설치 공간과 첫 번째 마운트에 필요한 시간의 벤치 마크입니다 find.

ratarmount와 archivemount의 벤치 마크 비교

각 1k 파일을 포함하는 폴더가 생성되었으며 폴더 수는 다양합니다.

왼쪽 아래 그림에는 cat <file>임의로 선택된 10 개의 파일 에 대한 최소 및 최대 측정 시간을 나타내는 오류 막대가 표시 됩니다.

파일 탐색 시간

킬러 비교는 cat <file>완료 하는 데 걸리는 시간 입니다. 어떤 이유로, 이것은 ratarmount에서 일정한 시간을 유지하면서 archivemount에 대한 TAR 파일 크기 (파일 당 약 바이트 x 파일 수)와 선형으로 확장됩니다. 이것은 archivemount가 탐색을 전혀 지원하지 않는 것처럼 보입니다.

압축 된 TAR 파일의 경우 특히 두드러집니다. cat <file>전체 .tar.bz2 파일을 마운트하는 데 두 배 이상 걸립니다! 예를 들어, 10k empty (!) 파일이있는 TAR은 archivemount로 마운트하는 데 2.9 초가 걸리지 만 액세스 한 파일에 따라 cat3ms에서 5s 사이 의 액세스가 필요합니다. 소요 시간은 TAR 내부의 파일 위치에 따라 달라집니다. TAR 끝에있는 파일은 찾는 데 시간이 더 걸립니다. "검색"이 에뮬레이트되고 파일을 읽기 전에 TAR의 모든 내용을 읽음을 나타냅니다.

파일 내용을 얻는 데 전체 TAR을 마운트하는 것 자체가 예상치 못한 것보다 두 배 이상 걸릴 수 있습니다. 최소한 장착과 동일한 시간 내에 완료해야합니다. 한 가지 설명은 파일이 두 번 이상, 심지어는 세 번 모방되어 검색되고 있다는 것입니다.

Ratarmount는 파일 검색에 항상 같은 시간이 걸리므로 파일을 찾는 데 실제로 도움이됩니다. bzip2 압축 TAR의 경우 주소도 색인 파일에 저장된 bzip2 블록을 찾습니다. 이론적으로 파일 수에 따라 확장해야하는 유일한 부분은 색인에서 조회하는 것이며 파일 경로와 이름으로 정렬되므로 O (log (n))으로 확장해야합니다.

메모리 풋 프린트

일반적으로 TAR 내부에 20k 개 이상의 파일이 있으면 인덱스가 생성 될 때 디스크에 기록되므로 시스템에서 약 30MB의 일정한 메모리 풋 프린트를 갖기 때문에 ratarmount의 메모리 풋 프린트가 더 작아집니다.

작은 예외는 gzip 디코더 백엔드이며 어떤 이유로 gzip이 커질수록 더 많은 메모리가 필요합니다. 이 메모리 오버 헤드는 TAR 내부를 찾는 데 필요한 인덱스 일 수 있지만 백엔드를 작성하지 않았으므로 추가 조사가 필요합니다.

반대로 archivemount는 TAR이 마운트되는 한 전체 인덱스 (예 : 2M 파일의 경우 4GB)를 메모리에 완전히 유지합니다.

장착 시간

내가 가장 좋아하는 기능은 ratarmount가 후속 시도에서 눈에 띄게 지연없이 TAR을 마운트 할 수 있다는 것입니다. 파일 이름을 메타 데이터에 매핑하는 인덱스와 TAR 내부의 위치가 TAR 파일 옆에 작성된 인덱스 파일에 기록되기 때문입니다.

마운트에 필요한 시간은 archivemount에서 이상하게 작동합니다. 약 20k 파일부터 시작하여 파일 수에 대해 선형이 아닌 2 차로 확장되기 시작합니다. 이는 약 4M 파일부터 시작하여 작은 TAR 파일의 경우 최대 10 배 느리더라도 ratarmount가 archivemount보다 훨씬 빠르기 시작 함을 의미합니다! 그런 다음 작은 파일의 경우 tar를 처음 마운트하는 데 1 초 또는 0.1 초가 걸리든 상관 없습니다.

bz2 압축 파일의 마운트 시간은 항상 가장 비슷합니다. 이것은 bz2 디코더의 속도에 구속되기 때문에 가능성이 높습니다. Ratarmount는 여기에서 약 2 배 느립니다. 가까운 장래에 bz2 디코더를 병렬화하여 ratarmount를 확실한 승자가 되길 희망합니다. 8 살짜리 시스템에서도 4 배 빠른 속도를 낼 수 있습니다.

메타 데이터를 얻을 시간

findTAR 내부에있는 모든 파일을 간단히 나열 할 때 (각 파일마다 stat를 호출하는 것 같습니다!?), ratarmount는 모든 테스트 된 케이스에 대해 archivemount보다 10 배 느립니다. 나는 앞으로 이것을 개선하기를 희망한다. 그러나 현재 순수한 C 프로그램 대신 Python 및 SQLite를 사용하기 때문에 디자인 문제처럼 보입니다.


OP는 어떻게 문제를 해결하기 위해 이것을 설치 하고 사용 합니까?
Jeff Schaller

github에이 readme.md에서 @JeffSchaller 나는 설치 지침을 추가
mxmlnkn

0

텍스트 편집기로 사용이 제한되므로 모든 사용 사례를 다루지는 않습니다. 그러나 읽기 액세스에만 관심이있는 경우 일부 상황에서 유용 할 수 있습니다. vimtarball에서 실행하면 아카이브의 컨텐츠 계층이 표시됩니다 (디렉토리에서 실행하는 경우 파일 계층을 표시하는 방법과 유사 함). 목록에서 파일 중 하나를 선택하면 선택한 파일이 읽기 전용 버퍼로 열립니다.

다시 말하지만, 반드시 이미지 나 다른 미디어에 액세스 할 수있는 것은 아니지만 내용을 보거나 텍스트 기반 파일에만 액세스하는 것만으로도 도움이됩니다.

참고 : 일부 아카이브 형식에서는 작동하지 않습니다.


vim의 내장 된 아카이브 뷰어는 여전히 전체 파일을 스캔하여 avfs 및 archivemount보다 훨씬 빠른 목록을 검색해야합니다. 수백만 줄의 거대한 목록을 표시하는 것도 끔찍합니다.
把 友情 留 在 无 盐

0

내 접근 방식. 외부 USB 드라이브 또는 충분한 여유 공간이있는 외부 / 보조 HDD 드라이브에 충분한 디스크 여유 공간이 있으면 .tar.gz 파일의 압축을 푸십시오. 주 시스템 디스크에 3 백만 개의 파일이 필요하지 않다고 생각하면 속도가 느려질 수 있습니다. 이 경우 외장 디스크에는 ReiserFS, ext4 (dir_index 옵션 사용), XFS, 아마도 BtrFS와 같은 수많은 파일을 쉽게 처리 할 수있는 파일 시스템이있는 것이 좋습니다. 추출물을 추출하는 데 1-2 시간이 걸릴 수 있지만 그 동안 점심을 먹거나 밤새도록 할 수 있습니다. 당신이 돌아올 때, 추출 된 파일에 액세스하는 것이 수행되어야합니다.


추가 미디어가 필요하지 않으며 루프 장치로 충분합니다.
把 友情 留 在 无 盐
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.