Linux >2.6.33: could sendfile() be used to implement a faster 'cat'?

Question

Having to concatenate lots of large files into an even larger single one, we currently use

cat file1 file2 ... output_file

but are wondering whether it could be done faster than with that old friend.

Reading the man page of sendfile(), one can specify an offset into *input_file*, from where to send the remainder of it to *output_file*. But: can I also specify an offset into *output_file*? Or could I simply loop over all input files, simply by leaving open my output FD and sendfile()'ing repeatedly into it, effectively concatenating the *input_files*? In other words: would the filepointer into my output FD remain at its end, if I do not close it nor seek() in it?

Does anybody knows of such a cat implementation using sendfile()?

---

Admittedly, I'm an admin, not a programmer, so please bear with my lack of 'real' coding knowledge...

Answer 1

Yes, the file pointer of the output fd will remain at its end (if the file is new or is not bigger than the data you already wrote to it).

The documentation for sendfile() explicitly mentions (emphasis mine):

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 file, then sendfile() changes the file offset appropriately.

I personally never saw an implementation of cat that relies on sendfile(), maybe because 2.6.33 is quite recent, and out_fd could not be fileno(stdout) before. sendfile() is also not portable, so doing that would result in a version of cat that only runs on Linux 2.6.33+ (although I guess it can still be implemented as a platform-dependent optimization activated at compile time).