Problem with invalid/unstable journal-DB on new Linux Client (6.3.0)?

[Godzilla]

Hello everyone,


I am testing the new 6.3.0 Linux client which has journaling now enabled.
I've did the following.
- Installed and configured it this way:
[JournalSettings]
Errorlog=/logs/mine/myJbberror.log
Journaldir=.tSm_JoUrNaL


[JournalExcludeList]
; Note that this list contains the journal database files.
*.jdb.jbbdb
*.jdbInc.jbbdb


[JournaledFileSystemSettings]
JournaledFileSystems=/ /data /data2 /data3
PreserveDBOnExit=0
DeferFsMonStart=0
DeferRetryInterval=2
logFsErrors=1

then I've started the daemon, checked if it's working:
opt/tivoli/tsm/client/ba/bin/rc.tsmjbb status
Checking tsmjbbd: running

Hooray, so far. After that I did a full incremental backup to bring the journals online,
that went well. With a dsmc query filespace I saw a recent "last incr date".
So far, so good. All my .jdv.jbbd and .jdbInc.jbbd files were recent and okay.

We've put some files into /data on our test machine and started a new incremental backup.
And I saw these messages (just extract from my log)

Querying Journal for '/data3'
Processing 0 Journal entries for '/data3'
Querying Journal for '/'
Processing 118 Journal entries for '/'
ANS1761I Journal for '/data' will be enabled upon successful completion of the backup.
ANS1760I Journal for '/data' enabled for node 'foobar' and server 'badaboom'
ANS1761I Journal for '/data2' will be enabled upon successful completion of the backup.

ANS1898I ***** Processed 2,943,000 files *****

(Especially the thousands of ANS1898I lines were not expected by me... it doesn't make sense in my opinion when using a journal)

Normal File--> 2,096 /data2/.tSm_JoUrNaL/tsm_data2.jdb.jbbdb [Sent]
Normal File--> 2,096 /data2/.tSm_JoUrNaL/tsm_data2.jdbInc.jbbdb [Sent]
Successful incremental backup of '/data2'


Total number of objects inspected: 2,943,028
Total number of objects backed up: 117,790
Total number of objects updated: 0
Total number of objects rebound: 0
Total number of objects deleted: 0
Total number of objects expired: 110
Total number of objects failed: 0
Total number of bytes inspected: 246.41 GB
Total number of bytes transferred: 11.92 GB
Data transfer time: 117.39 sec
Network data transfer rate: 106,521.51 KB/sec
Aggregate data transfer rate: 2,237.43 KB/sec
Objects compressed by: 0%
Total data reduction ratio: 95.17%
Elapsed processing time: 01:33:08


why does the client have to enable the Journal again? I thought that the daemon and Journal already
knows about the new files, cause we already had done a full incremental and the Journals were active.
It worked fine for / and /data3, why not for /data and /data2 ?

It looks for me that he did a full check again and build a new Journal, instead of looking in the Journal-DB.
The daemon was running the whole time.

Is there anything with my tsmjbbd.ini or an error in the client (first Linux client with Journaling...)
or any settings on the TSM-Server?


With regards


Godzilla

[Godzilla]

Hello everyone,

I got a hint from a TSM guru. It seems to be that the client has the same error:
https://www-304.ibm.com/support/docv...id=swg1IC40627
I will open an call.

Godzilla

[Godzilla]

Ok,

I got a response from TSM support, to avoid "damaged" journals put the following lines:
[JournalSettings]
SessionTimeout=216000

in your tsmjbbd.ini.
It worked fine for me Hooray!

On the other hand... it seems to be that I detected a new bug.
If you have a running tsmjbbd in the background, valid journals
and then make a "dsmc incr" and you stop it with a "ctrl-c" the
tsmjbbd also dies. That's bad.
I opened a new call at IBM for that.

Godzilla