ADSM-L

Re: [ADSM-L] Journaling database retaining upon reboot?

2008-07-09 13:31:32
Subject: Re: [ADSM-L] Journaling database retaining upon reboot?
From: Alex Paschal <apaschal AT MSIINET DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 9 Jul 2008 12:29:48 -0500
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.

<Prev in Thread] Current Thread [Next in Thread>