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/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] 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" <[email protected]> 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:[EMAIL PROTECTED] On Behalf Of > Andrew Raibeck > Sent: Wednesday, July 09, 2008 9:42 AM > To: [email protected] > 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/[EMAIL PROTECTED] > Internet e-mail: [EMAIL PROTECTED] > > 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.
