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" <[EMAIL PROTECTED]> on 27.11.2001 00:29:10 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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! -----Original Message----- From: Zlatko Krastev/ACIT [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 22, 2001 12:26 PM To: [EMAIL PROTECTED] Subject: Re: dsmfmt question May I try to contribute to this discussion. - Raw logical volumes ought to be faster than a single large file because there is no JFS overhead. What if the disk keeping the jfslog volume is very busy. And there were many threads on this list regarding TSM log pinnouts, overflows, etc. Have in mind that JFS is using very similar methology (but you cannot issue Q LOG). - There is no need to calculate exactly how large the file has to be. And there is no need to use dsmfmt. "DEF VOL <stgpool> /dev/r<lv_name>" and the server will recognise the size automagically. - With JFS you waste space on superblock, i-nodes and jfslog volume. Raw volumes are raw - everything is up to you (and TSM) except LVM header (512 bytes). And if you are greedy you can use even the first block. LVM will complain on some operations but will not overwrite it. - You do not have control over file(s) placement within the filesystem (and disk). You can control intra-policy of each logical volume and place most used closer to disk middle and rarely used on the ends. You can control which logical volume to be spread across the disks and which not to be stripped. This can improve performance. - There is no need to care about filesystem mount/unmount, mount order, fsck, etc. - Using specific volume type (I use 'mklv -t tsm_db', tsm_log and tsm_vol) you can designate logical volume usage. And even after the disk is attached to another system you can easily recognise each volume usage (when LV name on imported VG conflicts with existing varied on LV name AIX assigns lvXX to it). I though several times why not to use /dev/rhdiskXX but I see to many obstacles and nearly not benefit - the disk device name will change on any devices reorganisation, i.e. SCSI disk goes in another hot-swap bay and gets another ID, alternate path with different adapter gets new device name - disk is not signed and someone can overwrite its data assigning it to a volume group. - Attachment to other system gives no information what was the previous usage of the disk. - Performance benefit from removal of LVM overhead is not so significant to pay all problems considered above. Zlatko Krastev IT Consultant "Loon, E.J. van - SPLXM" <[EMAIL PROTECTED]> on 21.11.2001 16:53:38 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: dsmfmt question Hi *SM-ers! I will replace my 9 Gb. SSA disks in the very near future. The new disks (36 Gb. 10.000 rpm) will have to be added to the diskpool one by one. I remember from the last time that it was quite difficult to allocate a disk file which fills the disk completely. If you have, for instance, a 9 Gb. disk, you cannot create a 9 Gb. file by issuing a DSMFMT -G -DATA filename 9. This results in an error indicating the there isn't enough space available. Apparently the dsmfmt utility needs a little bit overhead space. Does anybody know how to calculate the maximum space one can specify to fill the disk to it's maximum? Thanks in advance for any reply!!! Kindest regards, Eric van Loon KLM Royal Dutch Airlines ********************************************************************** This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **********************************************************************
