1. Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING) Click the link to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This message will disappear after you have made at least 12 posts. Thank you for your cooperation.

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

Discussion in 'TSM Client' started by Godzilla, Nov 24, 2011.

  1. Godzilla

    Godzilla New Member

    Joined:
    Jan 13, 2010
    Messages:
    18
    Likes Received:
    0
    Location:
    Aschaffenburg
    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
     
  2.  
  3. Godzilla

    Godzilla New Member

    Joined:
    Jan 13, 2010
    Messages:
    18
    Likes Received:
    0
    Location:
    Aschaffenburg
  4. Godzilla

    Godzilla New Member

    Joined:
    Jan 13, 2010
    Messages:
    18
    Likes Received:
    0
    Location:
    Aschaffenburg
    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
     

Share This Page