> a) is it OK that log data is visible only after the (write) delay? For my purposes it is; I know some of the other responses have been that it's not, but perhaps setting up a signal (maybe USR2) for triggering the flush mechanism would help those situations. Of course, people wanting "real-time" data would probably either leave off the configurations (knowing they're doing so at the expense of performance) or change it at runtime and HUP.
> b) does it sound useful to buffer based on allocation unit sizes? I had actually considered suggesting this as a third option (differentiating from other implementations), but abandoned it since I was unsure of the value and felt the implementation may be overly complex. If you implement byte/allocation-aligned flushes, my preference would be to have it in addition to but mutually (configuration) exclusive with record-aligned ones. Partial-sector writes are less of a concern to me in most cases than getting the whole message to disk, but I can again see the usefulness of allocation alignment in a very high-volume environment or one where disk performance is constrained. Regardless, it's a fascinating development and one that will come in very handy. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
