☰

(cp는 cat AS mv는?) mv 여러 파일은 cat * rm * 대신 하나의 파일로 병합됩니다.

tag-icon • tag-icon cat mv
(cp는 cat AS mv는?) mv 여러 파일은 cat * rm * 대신 하나의 파일로 병합됩니다.

이 질문의 모든 내용에 대해 시스템에 디스크와 파일 시스템이 하나만 있다고 가정합니다. (다른 파티션, 디스크 또는 파일 시스템에는 쓰지 않습니다)

cat저는 매우 큰 .MTS 파일을 하나의 거대한 .MTS 파일로 병합하는 프로젝트를 진행하고 있습니다 . 이를 위해서는 각각의 작은 파일을 읽고 더 큰 새 파일에 쓴 다음 작은 파일을 삭제해야 합니다. 이렇게 큰 파일의 경우 시간이 오래 걸립니다.

내 이해- 파일을 디스크의 다른 위치에 읽고 쓰기 때문에 시간 cp이 더 오래 걸립니다 . 반면에 파일은 복사되거나 이동되지 않습니다. 파일에 대한 참조를 삭제하고 새 위치에 새 참조를 만듭니다. 예를 들어 파일을 디스크에 유지하고 디스크의 파일에 대한 참조를 제거한 다음 디스크의 파일에 대한 새 참조를 추가합니다.mvcpmvmvmv /tmp/foo /tmp/bar/tmp/foo/tmp/bar

질문:

catcp파일을 새 위치에 복사하기 때문입니다 . 완료했을 때 더 작은 파일이 필요하지 않을 정도로 큰 파일을 사용하는 경우 대신 cat사용할 수 있는 비슷한 것이 있습니까 ?mvcp

이론(내가 잘못 말했을 수도 있음)

파일이 여러 드라이브에 분산되어 저장되는 것이 일반화되었습니다. 예를 들어, 2GB 파일에는 드라이브의 다른 부분에 여러 개의 작은 청크가 저장되어 있을 수 있습니다. 이렇게 하면 5K 파일을 삭제할 때 20MB 파일의 일부로 덮어쓸 수 있습니다. 2GB 파일을 그대로 두고 모든 부분을 참조하면 cat foo/* >> bar/bigfile.MTS; rm foo/*짧은 시간 안에 동일한 효과를 얻을 수 있는 것처럼 보입니다.

이 작업을 수행하는 것이 없고 나쁜 생각이라면 누구든지 왜 나에게 예를 줄 수 있습니까? 흩어져 있는 파일 블록으로 디스크를 어지럽히는 것이 좋지 않습니까?

답변1

이와 같은 기존 도구의 가장 큰 장애물은 연결된 각 파일의 크기(마지막 파일 제외)가 블록 크기로 완전히 나누어지지 않는 한(여기서는 올바른 용어가 무엇인지 잘 모르겠습니다) 다음과 같은 결과가 발생한다는 것입니다. 최종 파일의 연결 파일 사이에 정크 데이터의 "간격"이 있습니다.

이는 파일 데이터가 일반적으로 파일 시스템에서 특정 크기의 블록에 저장되기 때문에 32바이트 블록을 사용하여 파일 시스템에 저장된 618바이트 파일은 618/32 = 19.3125 블록, 즉 19개의 전체 블록을 차지하게 되기 때문입니다. 약 1 추가 블록의 /3.

내 장애에 관계없이 이와 같은 두 파일을 결합하고 싶다고 가정하면 "새 파일"이 첫 번째 파일의 청크와 두 번째 파일의 청크를 가리킬 수 있습니다. 그렇죠?

이 간단한 접근 방식을 사용하면 40개의 블록이 있는 파일이 생성됩니다. 여기서 블록 20은 1/3은 합리적이고 2/3은 가비지이며 블록 21은 두 번째 파일의 데이터를 시작합니다.

일부 파일 형식의 경우 파일 헤더에 대해 영리한 계산과 조작을 수행할 수 있습니다. 기본적으로 응용 프로그램에 파일을 사용하여 불필요한 부분을 건너뛰도록 지시할 수 있지만 이는 올바른 계획보다는 반창고에 더 가깝습니다. .

답변2

다음은 stackoverflow의 비슷한 질문입니다.https://stackoverflow.com/questions/5893531/fast-concatenate-multiple-files-on-linux

간단한 대답은 이것입니다 -

모든 파일(마지막 파일 제외)의 크기가 파일 시스템 블록 크기의 배수가 보장되는 경우에만 작동합니다.

파일 시스템은 파일 끝까지 모든 블록을 읽어야 하기 때문입니다.

관련 정보