sendfile — transfer data between file descriptors
sendfile() copies data
between one file descriptor and another. Because this copying
is done within the kernel,
sendfile() is more efficient than the
combination of read(2) and write(2), which would
require transferring data to and from user space.
in_fd should be a
file descriptor opened for reading and
out_fd should be a descriptor
opened for writing.
offset is not
NULL, then it points to a variable holding the file offset
start reading data from
sendfile() returns, this variable will be
set to the offset of the byte following the last byte that
was read. If
is not NULL, then
does not modify the file offset of
in_fd; otherwise the file
offset is adjusted to reflect the number of bytes read from
offset is NULL,
then data will be read from
in_fd starting at the file
offset, and the file offset will be updated by the call.
count is the
number of bytes to copy between the file descriptors.
must correspond to a file which supports mmap(2)-like operations
(i.e., it cannot be a socket).
In Linux kernels before 2.6.33,
out_fd must refer to a socket.
Since Linux 2.6.33 it can be any file. If it is a regular
the file offset appropriately.
If the transfer was successful, the number of bytes
returned. Note that a successful call to
sendfile() may write fewer bytes than
requested; the caller should be prepared to retry the call if
there were unsent bytes. See also NOTES.
On error, −1 is returned, and
errno is set appropriately.
Nonblocking I/O has been selected using
O_NONBLOCK and the write would
The input file was not opened for reading or the output file was not opened for writing.
Descriptor is not valid or locked, or an mmap(2)-like
operation is not available for
count is negative.
O_APPEND flag set.
This is not currently supported by
Unspecified error while reading from
Insufficient memory to read from
count is too
large, the operation would result in exceeding the
maximum size of either the input file or the output
not NULL but the input file is not seek(2)-able.
sendfile() first appeared in
Linux 2.2. The include file
> is present since glibc 2.1.
Not specified in POSIX.1-2001, nor in other standards.
Other UNIX systems implement
sendfile() with different semantics and
prototypes. It should not be used in portable programs.
sendfile() will transfer at
most 0x7ffff000 (2,147,479,552) bytes, returning the number
of bytes actually transferred. (This is true on both 32-bit
and 64-bit systems.)
If you plan to use
sendfile() for sending files to a TCP
socket, but need to send some header data in front of the
file contents, you will find it useful to employ the
TCP_CORK option, described in
tcp(7), to minimize the
number of packets and to tune performance.
In Linux 2.4 and earlier,
out_fd could also refer to a
regular file; this possibility went away in the Linux 2.6.x
kernel series, but was restored in Linux 2.6.33.
The original Linux
sendfile() system call was not designed to
handle large file offsets. Consequently, Linux 2.4 added
sendfile64(), with a wider type
argument. The glibc
wrapper function transparently deals with the kernel
to a socket or pipe with zero-copy support, callers must
ensure the transferred portions of the file referred to by
unmodified until the reader on the other end of
out_fd has consumed the
The Linux-specific splice(2) call supports transferring data between arbitrary file descriptors provided one (or both) of them is a pipe.
This page is part of release 4.07 of the Linux
man-pages project. A
description of the project, information about reporting bugs,
and the latest version of this page, can be found at
This man page is Copyright (C) 1998 Pawel Krawczyk.
Permission is granted to distribute possibly modified copies
of this page provided the header is included verbatim,
and in case of nontrivial modification author and date
of the modification is added to the header.
$Id: sendfile.2,v 1.5 1999/05/18 11:54:11 freitag Exp $
2000-11-19 bert hubert <ahuds9a.nl>: in_fd cannot be socket
updated description of in_fd and out_fd for 2.6
Various wording and formatting changes
2005-03-31 Martin Pool <mbpsourcefrog.net> mmap() improvements