Hi Alex,

Good out-of-the-box thinking, but the drawbacks are probably more severe
than the advantages:

- The TSM journal service (at least on Windows) is not a filter driver.

- Such a solution would cause lots of problems for the OS itself.

- I wouldn't want to be in your shoes if you installed a product that
could cause application failures just to satisfy the journal service. :-)

Best regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 07/09/2008
10:29:48 AM:

> Hi, Andy.
>
> Maybe add an option to the journal service setup that could have the
> filesystem filter driver fail writes to the filesystem if the journal
> service is down?  Of course, this would have the obvious serious
> drawback, but maybe in some horrendously large filecount environments
> users might decide it's worth it to enforce journal db/filesystem
> synchronization.
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Andrew Raibeck
> Sent: Wednesday, July 09, 2008 9:42 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Journaling database retaining upon reboot?
>
> > Sooo...with all of these issues with jbb, are they being worked
> > on/fine-tuned?
>
> Yes and no.
>
> For the case where you use PreserveDbOnExit=1 and the journal service is
>
> shut down for some period of time, the behavior will remain unchanged.
> Use
> at your own risk. If the journal service is down, it cannot effectively
> monitor file system changes so there is no known solution for this.
>
> For the journal corruption issue, we are currently targeting an
> enhancement that allows the journal service to know whether the database
>
> was closed cleanly (by a clean journal service shutdown). Upon restart,
> if
> the journal service does not detect the "I was closed cleanly" flag in
> the
> journal database, it will effectively ignore PreserveDbOnExit=1 and
> reset
> the journal database, as if PreserveDbOnExit=0 was in effect. This would
>
> be in a future release of the product. Note that this does not represent
> a
> formal announcement or commitment, so this is subject to change.
>
> A THEORETICALLY cleaner solution could include implementation of of a
> journal database with transactional capabilities, including rollback,
> more
> thorough structural integrity checking, etc. Even in a rollback
> scenario,
> in-flight file system changes would be lost (like the case where you use
>
> PreserveDbOnExit=1 and journal service is down for some period of time),
>
> leaving a less than perfect solution. But this is all hypothetical, and
> there are no plans in place.
>
> Best regards,
>
> Andy
>
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Product Development
> Level 3 Team Lead
> Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> Internet e-mail: storman AT us.ibm DOT com
>
> IBM Tivoli Storage Manager support web page:
> http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageMan
> ager.html
>
> The only dumb question is the one that goes unasked.
> The command line is your friend.
> "Good enough" is the enemy of excellence.
>
>
> This message (including any attachments) is intended only for
> the use of the individual or entity to which it is addressed and
> may contain information that is non-public, proprietary,
> privileged, confidential, and exempt from disclosure under
> applicable law or may constitute as attorney work product.
> If you are not the intended recipient, you are hereby notified
> that any use, dissemination, distribution, or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, notify us immediately by telephone and
> (i) destroy this message if a facsimile or (ii) delete this message
> immediately if this is an electronic communication.
>
> Thank you.