tar -cvf깊이 중첩된 폴더 구조의 쉽게 다운로드 가능한 복사본을 만들기 위해 크기가 937MB인 디렉터리에서 실행하는 경우 다음 출력이 나타나면 디스크가 가득 찰 위험이 있습니까 df -h?
/dev/xvda1 7.9G 3.6G 4.3G 46% /
tmpfs 298M 0 298M 0% /dev/shm
관련 질문:
- Linux(Amazon AMI)는 왜 있고/또는 디스크가 꽉 찼을 경우
tar뒤에서 무엇을 하고 있습니까 ? - 다시 묻지 않고도 어떻게 이 정보를 직접 정확하게 확인할 수 있습니까?
답변1
tar -c data_dir | wc -c
압축 없음
또는
tar -cz data_dir | wc -c
gzip 압축 사용
또는
tar -cj data_dir | wc -c
bzip2 압축 사용
생성될 아카이브의 크기(바이트)는 디스크에 쓰지 않고 인쇄됩니다. 그런 다음 이를 대상 장치에서 사용 가능한 공간의 양과 비교할 수 있습니다.
크기에 대한 잘못된 가정을 방지하기 위해 다음 명령을 사용하여 데이터 디렉터리 자체의 크기를 확인할 수 있습니다.
du -h --max-depth=1 data_dir
이미 답변했듯이 tar는 아카이브의 각 레코드에 헤더를 추가하고 각 레코드의 크기를 512바이트의 배수(기본값)로 반올림합니다. 아카이브의 끝은 0으로 채워진 최소 두 개의 연속 레코드로 표시됩니다. 따라서 압축되지 않은 tar 파일은 항상 파일 자체보다 크며, 파일 수와 512바이트 경계에 대한 정렬에 따라 사용되는 추가 공간이 결정됩니다.
물론, 파일 시스템 자체에서 사용하는 블록 크기는 단일 파일의 내용보다 클 수 있으므로 파일 압축을 풀 때 주의하세요. 파일 시스템은 여유 공간이 있더라도 많은 수의 작은 파일을 수용하지 못할 수 있습니다. 공간이 타르 크기보다 큽니다!
답변2
tar 파일의 크기는 937MB에 각 파일 또는 디렉터리에 필요한 메타데이터 크기(객체당 512바이트)를 더한 것이며 512바이트 경계에 파일을 정렬하기 위해 패딩이 추가됩니다.
매우 대략적인 계산에 따르면 데이터를 다시 복사하면 3.4GB의 여유 공간이 남게 됩니다. 패딩이 없다고 가정하면 3.4GB에는 약 700만 개의 메타데이터 레코드를 저장할 수 있는 공간이 있으며, 파일당 평균 패딩이 256바이트라고 가정하면 그보다 적습니다. 따라서 tar가 필요한 수백만 개의 파일과 디렉터리가 있는 경우 문제가 발생할 수 있습니다.
다음을 통해 문제를 완화할 수 있습니다.
z또는 옵션을 사용한j동적 압축tar- 공간이 부족할 때 파티션에 예약된 공간을 건드리지 않도록
tar일반 사용자로 이 작업을 수행하세요 ./
답변3
나는 이것에 대해 많은 연구를 했습니다. 단어 수를 사용하여 이 파일을 테스트할 수 있지만 du -sb adir.
tar -tvOf afile.tar | wc -c
du각 디렉터리는 4096바이트로, tar디렉터리는 0바이트로 계산됩니다. 각 디렉터리에 4096을 추가해야 합니다.
$(( $(tar -tvOf afile.tar 2>&1 | grep '^d' | wc -l) * 4096)))
그런 다음 모든 문자를 추가해야 합니다. 다음과 같은 내용은 다음과 같습니다.
$(( $(tar -tvOf afile.tar 2>&1 | grep '^d' | wc -l) * 4096 + $(tar -xOf afile.tar | wc -c) ))
터치된 파일(0바이트 파일)이나 1문자 파일을 사용해보지 않아서 이것이 완벽한지는 잘 모르겠습니다. 이렇게 하면 더 가까워질 것입니다.
답변4
-cvf압축이 포함되지 않으므로 ~1GB 폴더에서 이 작업을 수행하면 ~1GB tar 파일이 생성됩니다(Flub의 답변은 tar 파일의 추가 크기에 대한 자세한 내용을 제공하지만 10,000개의 파일이 있는 경우에도 단 5MB). 4GB 이상의 여유 공간이 있으므로 파티션을 채우지 않습니다.
사본을 다운로드하기 쉽습니다.
대부분의 사람들은 다운로드 측면에서 "쉬움"을 "더 작은"과 동의어로 생각하므로 여기서는 약간의 압축을 사용해야 합니다. bzip2현재 tar가 있는 모든 시스템에서 작동할 것이라고 생각하므로 j스위치에 이를 포함시키는 것이 아마도 최선의 선택일 것입니다. z( gzip)는 아마도 더 일반적일 것이고, 더 많은 압박을 가하는 다른 (덜 일반적인) 가능성도 있을 것입니다.
즉, tar작업을 수행하는 동안 일시적으로 추가 디스크 공간을 사용하지만 몇 가지 이유 때문에 기본 스토리지 형태로 테이프 드라이브 시대로 거슬러 올라간다는 점에서 그렇지 않다고 확신합니다. 2 수십 년에 걸쳐 개발되었습니다(그리고 압축이 포함된 경우에도 임시 중간 공간을 사용할 필요가 없다고 확신합니다).