The last message posted by me about growing file size was actually caused by heavy spike on incoming end (4x normal traffic). The output bandwidth was limiting the data being sent out and hence the buffer file was growing.
This correctly correlates to the same thing as mentioned and also is reflected in read and write head values. 
Please excuse me for the false alarm here.

However as described in previous emails, the issue is when the flow of logs is normal, we have still observed cases where file size is huge.

I will open a separate thread when I observe this again and this time I will run syslog-ng in debug mode and get the read, write, backlog head values for getting proper guidance.

Thanks
Raghu

On Mon, Jun 15, 2020, 14:18 Fabien Wernli <wernli@in2p3.fr> wrote:
On Mon, Jun 15, 2020 at 10:21:48AM +0200, SZIGETVÁRI János wrote:
> AFAIK, file size truncation only happens when the "read head" of the disk
> queue file catches up to the "write head".

I guess this is much more likely to happen when using reliable(no), as there
is a much smaller volume of messages to be written on disk.

______________________________________________________________________________
Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng
FAQ: http://www.balabit.com/wiki/syslog-ng-faq