Wanda,

David's analogy with Oracle redo logs is good. You can also compare to
something "closer" - TSM log. AIX performs I/O writes on transactional
basis. Trying to explain:
We have to write blocks A, B and C to a file.
1. filesystem driver writes "I will write blocks A, B, C with data aa, bb,
cc. period" in the jfs log.
2. data is actually written to disk.
3. driver writes "I've done operation NNN (write A, B, C)" in log.
So in case of failure "jfs log replay" corrects the fault by redoing work
(I think there is not rollback).
if fault occured in step 1, i.e. "I will write blocks A, B, C with data
aa, bb, <BANG!>" the record is ignored. Data write had to happen in step 2
so nothing is changed. Log inconsistency is simply deleted.
if fault occured in step 2 or 3 log replay writes again (same) data to
disk and commits the transaction.

Same happens within TSM database. Keep in mind that this is former IBM ADSM
for example TSM DB table names use same table/column names as DB2 system
catalog tables. So why to reuse DB2 code but not JFS one. And the question
which one is the original and which is the reused code is (for me) like the
question was the egg before the hen or vice versa :-) Probably they
originate from same code used in mainframe's SQL before it became named
DB2. Maybe only a retired IBMer can light this :-)
Back to the question - TSM writes what will happen in the log and just
after that does actual write. This simplifies handling of faulty media,
power down and other disasters.

And one IMPORTANT issue - DB/log mirroring. Or who will guard the guard.
TSM uses up to three mirror copies (AIX LVM have the same
capability/limit). There is a nice sentence - A man having a watch does
know what the time is, a man with two watches never can be sure. So there
is a third copy and in AIX there is "quorum check" also.
Another issue caused by this one - MIRRORWRITE DB/LOG in dsmserv.opt. I
think (actually I guess) I ought to have MIRRORWRITE LOG SEQUENTIAL for
safety and MIRRORWRITE DB PARALLEL for performance. However I did not find
anything on this (but I did not read all TSM docs and redbooks so it can be
hidden somewhere).
BTW: I just checked by test server and the settings there were the opposite
(as from dsmserv.opt.smp example). And if I could capture that silly human
being which installed the server (e-e-e, it has to be me ?! `-) I will
.... :-))


Zlatko Krastev
IT Consultant






"Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU> on 27.11.2001 00:29:10
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: dsmfmt question

That is something I am curious about, not being an AIX expert:

What is being logged to the JFS log that creates overhead in the TSM case?
I thought the JFS log was necessary because of changing files in the JFS
filesystem.
But TSM DB, LOG, and STGPOOL volumes (really files) are pre-formatted;
their
size does not change.
So what is the JFS overhead when TSM is writing into those files?

Thanks!