왜 cp --reflink=auto
이것이 기본 동작이 아닌가? 활성화하면 해를 끼칠 수 있습니까?
대화형 셸뿐만 아니라 시스템 전체에서 사용되도록 컴파일 타임에 활성화할 수 있습니까?
답변1
이는 획기적인 변경이므로 coreutils 9.0 이전에는 기본 설정이 아니었습니다. 견고성 때문에 데이터 손상을 방지하기 위해 복제를 원할 수도 있습니다. 또한 성능상의 이유로 CoW 파일에서 대기 시간에 민감한 일부 프로세스를 실행하고 쓰기가 기계 디스크의 다른 부분에 있을 수 있다는 사실로 인해 잠재적으로 지연되는 대신 복사하는 동안 쓰기가 발생하도록 할 수 있습니다. coreutils v8.24 mv로 시작하면 위의 제약 조건이 없으므로 기본적으로 다시 연결됩니다. coreutils 9.0 cp는 기본적으로 다시 연결을 시도하므로 이러한 변경 사항은 부 릴리스에는 적합하지 않습니다.
답변2
rsync
왜 기본값이 아닌지 잘 모르겠습니다. 이를 지원하지 않는 다른 복사 유틸리티( , , , ...)와 동일하게 작동할 수도 있습니다(또는 cpio
허용되지 않는 인터페이스 pax
( tar
예: NFS, 삼바, 퓨즈)를 통해 파일이 복사되는 경우 파일) 시스템 계층...).
나는 몇 년 전에도 같은 상황을 겪었고 GNU cp 코드를 잠깐 살펴보면 여전히 동일하다는 것을 알 수 있습니다. 다른 기본 동작을 얻으려면 코드를 패치해야 했습니다.
--- coreutils-8.21/src/cp.c~ 2013-06-22 21:50:26.265639114 +0100
+++ coreutils-8.21/src/cp.c 2013-06-22 21:51:06.880513924 +0100
@@ -775,7 +775,7 @@ cp_option_init (struct cp_options *x)
x->interactive = I_UNSPECIFIED;
x->move_mode = false;
x->one_file_system = false;
- x->reflink_mode = REFLINK_NEVER;
+ x->reflink_mode = REFLINK_AUTO;
x->preserve_ownership = false;
x->preserve_links = false;
답변3
coreutils 9.0부터 reflink=auto가 기본 동작입니다. 바라보다:
https://lists.gnu.org/archive/html/info-gnu/2021-09/msg00010.html
이는 안정 버전인 coreutils-9.0 출시를 위한 것입니다.
이는 다음과 같은 주요 변경 사항이 포함된 새로운 주요 버전입니다.
- cp는 데이터 처리 방식을 변경합니다.
- CoW는 기본적으로(FICLONE ioctl을 통해) 활성화됩니다.
- 가능한 경우 복사 오프로딩(copy_file_range를 통해)을 사용합니다.
- 구멍 감지는 다르게 수행됩니다(SEEK_HOLE에도 불구하고).
- 이는 mv 및 install에도 적용됩니다.
답변4
큰 문제는 글을 쓰다가 복사할 공간이 부족해질 수 있다는 것입니다.
일반 복사를 사용하면 복사가 완료된 후 파일의 기존 부분에 대한 쓰기 실패에 대해 걱정할 필요가 없습니다. 공간은 완전히 할당되고 파일이 삭제될 때까지 사라지지 않습니다. 그러나 복사본을 다시 연결하면 몇 주 또는 몇 달 후 복사본을 만들 공간이 부족하여 파일의 기존 부분에 대한 쓰기가 실패할 위험이 항상 있습니다.
이러한 작업이 실패하면 시스템이 뒤에서 재링크 복사를 수행했다는 사실을 알게 되면 매우 당황스러울 수 있습니다.