Source File
copy_file_range_linux.go
Belonging Package
internal/poll
// Copyright 2020 The Go Authors. All rights reserved.// Use of this source code is governed by a BSD-style// license that can be found in the LICENSE file.package pollimport ()var (kernelVersion53Once sync.OncekernelVersion53 bool)const maxCopyFileRangeRound = 1 << 30// CopyFileRange copies at most remain bytes of data from src to dst, using// the copy_file_range system call. dst and src must refer to regular files.func (, *FD, int64) ( int64, bool, error) {kernelVersion53Once.Do(func() {, := unix.KernelVersion()// copy_file_range(2) is broken in various ways on kernels older than 5.3,// see issue #42400 and// https://man7.org/linux/man-pages/man2/copy_file_range.2.html#VERSIONSif > 5 || ( == 5 && >= 3) {kernelVersion53 = true}})if !kernelVersion53 {return 0, false, nil}for > 0 {:=if > maxCopyFileRangeRound {= maxCopyFileRangeRound}, := copyFileRange(, , int())switch {case syscall.ENOSYS:// copy_file_range(2) was introduced in Linux 4.5.// Go supports Linux >= 2.6.33, so the system call// may not be present.//// If we see ENOSYS, we have certainly not transferred// any data, so we can tell the caller that we// couldn't handle the transfer and let them fall// back to more generic code.return 0, false, nilcase syscall.EXDEV, syscall.EINVAL, syscall.EIO, syscall.EOPNOTSUPP, syscall.EPERM:// Prior to Linux 5.3, it was not possible to// copy_file_range across file systems. Similarly to// the ENOSYS case above, if we see EXDEV, we have// not transferred any data, and we can let the caller// fall back to generic code.//// As for EINVAL, that is what we see if, for example,// dst or src refer to a pipe rather than a regular// file. This is another case where no data has been// transferred, so we consider it unhandled.//// If src and dst are on CIFS, we can see EIO.// See issue #42334.//// If the file is on NFS, we can see EOPNOTSUPP.// See issue #40731.//// If the process is running inside a Docker container,// we might see EPERM instead of ENOSYS. See issue// #40893. Since EPERM might also be a legitimate error,// don't mark copy_file_range(2) as unsupported.return 0, false, nilcase nil:if == 0 {// If we did not read any bytes at all,// then this file may be in a file system// where copy_file_range silently fails.// https://lore.kernel.org/linux-fsdevel/20210126233840.GG4626@dread.disaster.area/T/#m05753578c7f7882f6e9ffe01f981bc223edef2b0if == 0 {return 0, false, nil}// Otherwise src is at EOF, which means// we are done.return , true, nil}-=+=default:return , true,}}return , true, nil}// copyFileRange performs one round of copy_file_range(2).func (, *FD, int) ( int64, error) {// The signature of copy_file_range(2) is://// ssize_t copy_file_range(int fd_in, loff_t *off_in,// int fd_out, loff_t *off_out,// size_t len, unsigned int flags);//// Note that in the call to unix.CopyFileRange below, we use nil// values for off_in and off_out. For the system call, this means// "use and update the file offsets". That is why we must acquire// locks for both file descriptors (and why this whole machinery is// in the internal/poll package to begin with).if := .writeLock(); != nil {return 0,}defer .writeUnlock()if := .readLock(); != nil {return 0,}defer .readUnlock()var intfor {, = unix.CopyFileRange(.Sysfd, nil, .Sysfd, nil, , 0)if != syscall.EINTR {break}}return int64(),}
![]() |
The pages are generated with Golds v0.6.7. (GOOS=linux GOARCH=amd64) Golds is a Go 101 project developed by Tapir Liu. PR and bug reports are welcome and can be submitted to the issue list. Please follow @Go100and1 (reachable from the left QR code) to get the latest news of Golds. |