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" <Eric-van.Loon AT KLM DOT COM> on 21.11.2001 16:53:38
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
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.
**********************************************************************