私が理解したのは、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を使用できますが、2つのオフセットが必要ですsendfile。出力ファイル記述子の現在のオフセット中に、複製オフロード宛先に対して十分に緊密に結合されないことがある。
（汎用copy_file_range実装は、特定のサポートなしでファイルシステムで使用され、次のことを示しますsplice。同じ方法sendfile。sendfile可能なところに使われるといえますがcopy_file_range、まだ実装になったかはわかりません。 )