Linux> 2.6.33: can sendfile () be used to implement a faster "cat"?

Question

To combine a large number of large files into an even larger one, we currently use

  cat file1 file2 ... output_file 

but one wonders if this can be done faster than with this old friend.

Reading the sendfile() man page, you can specify the offset in * input_file *, from where to send the rest to * output_file *. But: can I also specify the offset in * output_file *? Or could I just iterate over all the input files, just leaving my output FD open and sendfile () 'ing again into it, effectively concatenating * input_files *? In other words: will the index file in my output FD remain at the end if I don’t close it and request it ()?

Does anyone know of such a cat implementation using sendfile() ?

---

Admittedly, I'm an administrator, not a programmer, so please bring my "real" coding knowledge ...

Answer 1

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

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

On Linux kernels prior to 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 accordingly .

I personally have never seen a cat implementation that relies on sendfile() , perhaps because 2.6.33 is pretty recent, and out_fd can't be fileno(stdout) before. sendfile() also not portable, so this will lead to a cat version that only works on Linux 2.6.33+ (although, I think, it can still be implemented as platform-specific optimization activated at compile time).