내가 이해한 바로는 Linux 커널은 전통적으로 새로운 시스템 호출을 추가하는 데 보수적이었습니다.
그러나 존재를 조사해 보니 copy_file_range똑같은 일을 하는 것 같습니다 sendfile. 내가 찾을 수 있는 유일한 차이점은 다음과 같습니다.
- 소켓에서는 전혀 작동하지 않으며 올바른 일반 파일에서만 작동합니다.
- 입력 및 출력 오프셋 설정 가능
그러나 일반 파일의 경우 a는 seek동일한 오프셋 의미 체계를 구현할 수 있으므로 copy_file_range시스템 호출의 기능이 기존 시스템 호출의 엄격한 하위 집합인 경우 시스템 호출의 목적이 무엇인지 혼란스럽습니다. 특히 조회를 별도의 작업으로 수행하는 것은 커널 공간에서 소요되는 시간을 더 이상 연장하지 않도록 자체적으로 매우 현명하게 수행될 수 있기 때문입니다. (일반적으로 운영 체제 설계의 목표는 운영 체제 호출이 차단되지 않고 제어가 사용자 모드로 반환되는 동안 물리적 조회가 완료될 수 있도록 하는 것입니다.)
답변1
copy_file_range장점sendfilesplice복사본이 제거된 경우- 목적은 블록 복사본을 하드웨어에 위임할 수 있는 기능에 대한 액세스를 제공하는 것입니다(예를 들어SAN). 그 직업은아직 진행 중;현재 복제본 오프로드는 파일 시스템 지원에 의존하며, 여기서 복제본은 파일 시스템의 참조로 교체되거나 서버에 위임될 수 있습니다. (바라보다쓰기 시 디렉터리 복사?더 알아보기. )
sendfile다른 측면은 파일을 네트워크에 효율적으로 전송하려는 욕구에서 비롯됩니다. 마찬가지로 splice파일을 파이프에 효율적으로 전송할 수 있습니다. 오래 전에 파일을 다른 파일( 백그라운드에서 사용됨) sendfile로 보내도록 확장되었지만 여전히 최적화된 읽기 및 쓰기라고 가정합니다. 사용자 공간에서 데이터를 읽고 쓰는 대신 프로세스는 커널에 읽기 및 쓰기를 처리하도록 요청할 수 있습니다. splice루프를 작성합니다.
내가 의심하는 존재 copy_file_range는 추가 출력 오프셋 매개변수와 관련이 있습니다. 하드웨어에서 사용할 수 있는 저수준 오프로드 블록 복사 기능을 노출하는 것을 고려하는 경우 이를 파일 설명자 기반 API에 연결하려면 And를 사용할 수 있지만 두 개의 오프셋이 필요합니다 sendfile. 출력 파일 설명자의 현재 오프셋 중 복제 오프로드 대상에 대해 충분히 긴밀하게 결합되지 않을 수 있습니다.
(범용 copy_file_range구현는 특정 지원 없이 파일 시스템에서 사용되며 다음을 나타냅니다 splice.같은 방법sendfile. sendfile가능한 곳에 사용된다고 할 수 있는데 copy_file_range, 아직 구현이 되었는지는 모르겠습니다. )