I get it! Thanks David! -----Original Message----- From: David Longo [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 27, 2001 10:44 AM To: [EMAIL PROTECTED] Subject: Re: dsmfmt question
Have worked with AIX for some years. Not a REAL detail person on this but basically my understanding is this: 1. AIX doesn't "know" what your files are used for. 2. As you have created a jfs filesystem, then the I/O has to go through it. This includes any writes to files, regardless of whether file changes in size. I forget the details but the jfs log keeps track of this and is used, for instance in the case of sudden unorderly halt of your system. I have had several instances where the filesystem that had my storage pools failed to mount on system reboot. I had to run AIX command "fsck" on it first which, for one thing "replays the log". (The OS filesystems automatically have fsck run against them on system reboot, but non rootvg filesystems don't). 3. It's the changing data that is kept up with by JFS. (I guess it's roughly like a redo log for Oracle, for a quick analogy). Hope this helps. David B. Longo System Administrator Health First, Inc. 3300 Fiske Blvd. Rockledge, FL 32955-4305 PH 321.434.5536 Pager 321.634.8230 Fax: 321.434.5525 [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 11/26/01 05:29PM >>> 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. ********************************************************************** "MMS <health-first.org>" made the following annotations on 11/27/01 10:54:18 ---------------------------------------------------------------------------- -- This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ============================================================================ ==
