Re: [PATCH] copy.c: use `sendfile()` for in-kernel file copying on Linux

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Feb 14, 2026, 16:43 UTC
Message-ID: <bf0b3c41-9784-4494-a932-68abfa60cea6@gmail.com>
In-Reply-To: <20260213124656.218396-1-integral@archlinux.org>

On 13/02/2026 12:46, George Hu wrote:

> The `sendfile()` system call copies data between one file descriptor
> and another within the kernel, which is more efficient than the
> combination of `read()` and `write()`.

Does git copy any files big enough that this makes a noticeable difference?

>   int copy_fd(int ifd, int ofd)
>   {
> +#ifdef __linux__

Our normal practice when a function has platform specific implementations is to host those implementations under compat/<platform> (see the implementations of trace2_collect_process_information() for an example)

Show 5 quoted lines

> +	struct stat ifd_st;
> +	size_t ifd_len;
> +	ssize_t ret = 0;
> +
> +	fstat(ifd, &ifd_st);

What happens if fstat() fails?

> +	ifd_len = ifd_st.st_size;
> +
> +	while (ifd_len && (ret = sendfile(ofd, ifd, NULL, ifd_len)) > 0)
> +		ifd_len -= (size_t)ret;

This does not propagate errors to the caller, if sendfile() fails the function returns 0. write_in_full() handles non-blocking writes, we should do the same here if we see EAGAIN. The man page lists various restrictions on the file descriptors passed to sendfile() - I'm not sure that they affect the uses of copy_file() in git but to be safe we should fall back to the read()/write() loop if we see EINVAL.

Thanks

Phillip

Show 13 quoted lines

> +#else
>   	while (1) {
>   		char buffer[8192];
>   		ssize_t len = xread(ifd, buffer, sizeof(buffer));
> @@ -19,6 +34,8 @@ int copy_fd(int ifd, int ofd)
>   		if (write_in_full(ofd, buffer, len) < 0)
>   			return COPY_WRITE_ERROR;
>   	}
> +#endif
> +
>   	return 0;
>   }
>