Thanks to all for the suggestions. I am using OS mirroring because, as I
said originally, this is a data area, not log or database.

The doc ("The Advantages of Using Journal File System Files", page 385,
TSM Administrators Guide V5.1 GC32-0768-00) makes it clear that you can
get into trouble if you use OS mirroring with raw volumes for log or
database. But TSM mirroring is OK for log or database on raw volumes.
Also OS mirroring is OK for log or database on JFS files. But for data
storage pools, where TSM mirroring does not exist, on raw volumes, it is
inconclusive as to whether or not you can have problems. So I'm using
JFS because I want to mirror my disk storage pools.

Using all 2gb dataspaces is not viable for performance, and would be a
nightmare to create and manage on big 36gb and 72gb disk drives.

But my point is, when I use JFS space for any area, it is impossible to
tell it to use all the space, it is impossible to calculate how much to
tell it to use if you want to use all of it, and it behaves VERY
inconsistently depending on something to do with disk size, on top of it
all. It wastes only 70mb on a 36gb drive (which I can certainly live
with), but after telling me how much I can use, it wastes 5gb on a 72gb
drive. Same OS, same Volume Group, same filesystem settings, same
everything except size. I suspect it is failing to take into account the
large Number of Bytes per Inode setting. It has taken me two days of
trial and error to figure out how large to specify it on the 36gb
drives, which should have been a number that was instantly available,
either via the program or via a formula published in the manual.

Other notes: The file system is Large File Enabled, and has Number of
Bytes per Inode set to 131072, and Allocation group Size set to 64mb.
This is AIX V4.3.3 TSM server V5.1.6.5.

dsmfmt is definitely broken.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu