Suricata

Rather than aim for reducing fflush calls, we will:
- Eliminate the flush following writes and instead mark the stdio elements as "unbuffered" using the configuration setting from the next item.
- Add a configuration parameter that specifies whether the output is to be "buffered". Currently, Suricata treats all output as unbuffered since every write of log/alert data is followed by a flush call. The configuration value will specify the amount of buffering. The current (default) value is 0 (no buffering); values must be a multiple of the file system block size (usually 4k) with an upper limit determined by the system's stdio implementation, e.g., setvbuf.
- Add a configurable "flush" packet mechanism that will periodically cause output streams to be flushed. When there is buffering, this will mitigate the amount of unbuffered log/alert data. The configuration setting is expressed in seconds specifying the amount of data in "time" that can be buffered and potentially lost if Suricata were to terminate unexpectedly. A value of 0 means do not periodically flush data; any other value (up to a TBD maximum value) specifies how often to flush the output streams.

We hope that this will eliminate a buffer copy present in the existing flows -- Suricata > stdio buffer -> kernel buffer - and replace it with Suricata -> NO stdio buffering -> kernel buffers.

- Related to output stream buffering, we will add a filetype with a name TBD that will act as an application level /dev/null -- all data written to the output is immediately accepted, but never persisted.

At any point here it would make more sense to just the write system call and bypass libc buffering altogether?

I think the current buffered with default libc defined bufsize + fflush should probably remain the default until we've established that unbuffered performs the same or better.

I think fwrite on an unbuffered FILE is probably the same as a write?

https://github.com/OISF/suricata/pull/9729