This will never be as efficient as rename as its essential a copy, just done within the context of kernel, rather than multiple read and write system calls from a userland application.
I'm also not sure if logging to a ramdisk and using sendfile makes sense.
In the current model we write chunks of data as we receive them, mean any calls to write() should be short, and the final rename is is practically instant. Of course this has the limitation that tmp dir and the final directory are on the same file system. The Suricata administrator has to go out of their way to make this the case though.
With the tmp directory and final directories on different file systems, we still write out the files in smaller chunks, but the final rename, instead of using rename would use sendfile. While more efficient than the cp
command, all bytes still need to be read and written before this system call will return, which for log files could be quite noticeable. And effectively we've written the whole file twice.
But I do think it would be nice to work, and not fail if the 2 directories are on different file systems. Using rename if possible, using sendfile if not, and perhaps falling back to a traditional copy otherwise.