%20mv%EB%A5%BC%20%EC%82%AC%EC%9A%A9%ED%95%98%EB%A9%B4%20%EC%96%B4%EB%96%A4%20%EC%9C%84%ED%97%98%EC%9D%B4%20%EC%9E%88%EB%82%98%EC%9A%94%3F.png)
저는 대학의 Linux 클러스터 연구 그룹에 액세스할 수 있는 대학원생입니다. 수년에 걸쳐 나는 꽤 많은 디렉토리를 축적했습니다. "폴더"는 Windows/Mac 용어인 것 같은데요? -- 내 홈 디렉토리( ~)에 있습니다. 새 시뮬레이션을 수행할 때 를 사용하여 홈 디렉터리에 새 디렉터리를 만든 mkdir다음 해당 디렉터리에서 시뮬레이션을 실행합니다.
그러나 시간이 지남에 따라 나는 내 홈 디렉토리에 이러한 디렉토리를 많이 축적했습니다. 이제 일부 디렉터리를 하위 디렉터리로 이동하고 싶습니다. 예를 들어, 이라는 새 디렉터리를 만든 다음 simulations1_10, , ... 디렉터리를 해당 디렉터리로 이동하여 simulation1홈 simulation2디렉터리 simulation10의 루트를 보다 체계적으로 구성할 수 있습니다.
이를 위해 다음을 사용할 수 있습니다 cp.
cp -r simulation1/ simulations1_10/
simulation1디렉토리(및 모든 내용)를 디렉토리에 복사 합니다 simulations1_10. 그러면 삭제할 수 있습니다 simulation1.
그런데 내 이적은아니요파일 시스템 경계를 넘는 경우 mv에도 마찬가지입니다 .많은보다 빠른 cp... ( mv물론 삭제 단계도 피할 수 있습니다.) 예를 들면 다음과 같습니다.
mv simulation1/ simulations1_10/
이 트릭은 빠르게 수행됩니다( 와 달리 cp기본적 mv으로 재귀적으로 수행됨). ~에 따르면이 답변도착하다이 문제, mv"각 디렉토리의 inode 데이터베이스만 업데이트"하기 때문에 훨씬 빠릅니다.
내 질문은 그것을 사용하는 데 어떤 위험이 있습니까 mv?
전송이 mv중단되면(정전, 사용자가 Ctrl+ 키 누르기 C등으로 인해) 소스에서 파일이 손상될 수 있다는 위험이 있다고 생각합니다.그리고목적지. 맞습니까?
또한 내가 사용하면mv 많은, "Inode 데이터베이스"가 너무 자주 업데이트되어 디스크 조각화 또는 기타 하드 드라이브/파일 시스템 문제가 발생할 수 있습니까?
답변1
기능 rename(명령의 기초 mv,"mv 유틸리티는 rename() 함수와 동일한 작업을 수행해야 합니다.")는 원자적입니다(POSIX 참조).http://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html, C 표준 참조):
일반 파일의 경우 이 rename() 함수는 ISO C 표준에서 정의된 함수와 동일합니다. 여기에 포함은 디렉터리에 대한 작업을 포함하도록 정의를 확장하고 새 매개 변수가 이미 존재하는 파일에 이름을 지정할 때의 동작을 지정합니다. 사양에서는 함수 작업이 원자적이어야 합니다.
(그러나 다음 경고를 참조하십시오.https://unix.stackexchange.com/a/322074/88983.)
Ctrl-C 등을 통해 작업을 중단해도 파일이 부분적으로 전송되어서는 안 됩니다. 실제로 언급한 대로 단일 파일 시스템은 mv실제로 파일 내용을 복사하지 않고 파일 메타데이터만 복사합니다. 이와 관련하여 일어날 수 있는 최악의 상황은 부분적인 움직임을 보는 것입니다.목차(이렇게 하면 일반 파일이 부분적으로 이동되는 대신 mv a b c dest중단될 수 있으며 예를 들어 a으로 이동 dest하지만 모든 파일과 해당 내용은 올바르게 이동됩니다.)
문제의 inode 측면에 관해서는 이것이 일반적으로 문제가 되지 않는다고 말하고 싶습니다. 몇 개의 디렉터리만 이동하기 위해 inode를 업데이트하는 것은 오버헤드가 낮은 일상적인 작업입니다(동일한 파일 시스템에서 발생하는 파일 내용 쓰기는 더 커야 합니다). 특정 파일 시스템 유형에 따라 잠재적인 성능 영향 또는 조각화 원인).