What you describe is a notification buffer overflow. This occurs when the journal daemon cannot keep pace with file system changes.
The Windows specific mechanism for monitoring the file system is supplied with an allocated buffer to place change notifications into. The buffer is allocated at the size specified in the journal daemon configuration. If the journal daemon file system monitor cannot process changes notifications from the buffer as quickly as they are being placed in the buffer by Windows a buffer overflow occurs. Since a buffer overflow indicates that changes have been missed, the journal daemon invalidates the journal and forces a full progressive incremental to successfully complete before the journal can be used for backup again. Typically buffer overflows occur when the file system changes rapidly in a small windows of time, for example when copying or deleting very large directory trees. The system load can also have an impact as a very busy system will cause the journal daemon monitor threads which process the notification buffers to be scheduled less and preempted more. So it really isn't the total number of files which change which cause the overflow, it is the rate and distribution of the changes. For example, 50,000 files might changing over several hours might not cause an overflow to occur while 10,000 files changing in 2 minutes might. Increasing the size of the notification buffers can help but if the file system changes rapidly enough the overflows will occur regardless. Hope this is helpful ... Pete Tanenhaus IBM Spectrum Protect Client Development email: [email protected] tieline: 320.8778, external: 607.754.4213 "Those who refuse to challenge authority are condemned to conform to it" From: Michael P Hizny <[email protected]> To: [email protected] Date: 02/27/2017 09:58 AM Subject: Journal Buffer Sent by: "ADSM: Dist Stor Manager" <[email protected]> Hi, We have set up journaling on a Windows 2012 file server with approximately 5 million files. They files don't change very often and the turnover is small. We are receiving the following error: 02/25/2017 16:52:33 ANS0361I DIAG: ReadFsChangesThread(tid 3264): ReadDirectoryChangesW: Unable to process change notification buffer, the buffer size may be need to be adjusted to avoid this problem in the future. 02/25/2017 16:52:33 ANS0361I DIAG: ReadFsChangesThread(tid 3264): exiting thread. 02/25/2017 16:58:26 ANS0361I DIAG: psFsMonitorThread(tid 3616): Notification buffer overrun for monitored FS 'G:\', journal will be reset. 02/25/2017 16:58:26 ANS0361I DIAG: jnlDbCntrl(): Resetting journal for fs 'G:'. After reading the articles (there are not many) regarding journal buffer over runs, we have changed the parameters as indicated in the IBM article (http://www-01.ibm.com/support/docview.wss?uid=swg21620688) to the following in the jbb.ini file: ; Notification Buffer Size - default 32 Kbytes for files, 16 Kbytes for dirs ; NotifyBufferSize=0x00001000 DirNotifyBufferSize=0x00001000 JournaledFileSystems=G:\ ; The error is still occurring. We use journaling on several other servers without issue. Does anyone have an idea on what adjustments can be made to alleviate this? We are running version 7.1.6.2 of the client. Thanks, Mike
