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.

==============================================================================

Reply via email to