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: tanenhau AT us.ibm DOT com
tieline: 320.8778, external: 607.754.4213
"Those who refuse to challenge authority are condemned to conform to it"
From: Michael P Hizny <mhizny AT BINGHAMTON DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: 02/27/2017 09:58 AM
Subject: Journal Buffer
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
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
|
