The following has be reported by IBM LTC:  
[BETA] Insufficient space on /usr volume to install all products
Please fill in each of the sections below.

Hardware Environment:

zSeries 9064-116, shark e20

Software Environment:

taroon beta 1 under VM

Steps to Reproduce:
1. put / on one volume 3390-3 volume
2. put /usr on a second 3390-3 volume
3. install EVERYTHING!

Actual Results:

Message: You don't appear to have enough disk space to install the packages
you've selected. You need more space on the following file systems:

/usr 1169M

Expected Results:

Either some notion during the install process how big each package is to pick
and choose by size or some methodology to cut /usr into more reasonable chunks

Additional Information:

The stand disk size, after formatting, of the standard 3390-3 image is about 2.3
GB. The message implies to me that /usr is then greater than 3.4 GB!

Many installations are bound by this "small" disk size alternative because they
are using older hardware or they have an installation standard of a 3390-3 image
on their RVA's or Sharks, or for performance reasons, they do not want too much
data behind a single disk - subchannel - for performance reasons.

The only alternative I can think of in installing a full system is to keep
installing pieces, then moving these pieces to some other dasd using soft links
from /usr. 

/usr seems to be growing in leaps and bounds. If I had 30GB disk, no problem.
But in the zSeries world, 2.3 GB is still the standard.In addition, when you
specify, the install process loops. It only gives you the
option to say ok, which then goes back, reformats the file system, and gives the
same message! It should at least take you back to the point where you specify
the packages and let you deselect some.After install of a much smaller set of
choices, I did a df command

Filesystem      1k-blocks   Used      Available    Use%   Mounted on
/dev/dasda1     2366164     114756     2131212     6%     /
/dev/dasdb1     2366164    1613388      632580    72%     /usr

So it looks like almost everything is dumped into the /usr directory! /opt and
/misc are empty.Jim - if you have a standard 2.3 GB disk, maybe you should not
install
EVERYTHING ?

However, your Comment#1 is a problem and needs to be fixed by Red Hat.In the
zSeries world, IBM set the standard geometry as 3390 when they went from
3390 to RAMACI in the late '80s. At that time, the device size was also 3390-3
(2.7 GB), so that became the defacto standard in the industry. Later devices
(RAMACII-III, RVA, RSA, Shark, and our competitors - EMC, hitachi) have pretty
much kept to this standard because that is what the MVS device driver is set
for. With some of the devices, such as RVA or Shark, you can increase the size
of the volume, most notably to 3390-9 (3 times larger than a 3390-3), but,
unless you have PAV's, you take a performance hit. 

Under linux, the actual amount of data is 4096 byte blocks times 12 blocks per
track or 49152 bytes (48K) per track not the 56K you often hear because of the
ECKD overhead. That makes a 3390-3 of 3339 tracks (15 tracks/cyl) 2347.73 MB. A
3390-9, the next popular size would be 7043.2 GB.

This 48K track is not implemented directly on the track today as with real 3390,
but, since RAMAC I, this is really a virtual mapping to a SCSI device or raid
array. It is a logical, not physical construct. Why not change it? Because the
customers of IBM have stated that they do not want anymore changes to the
logical format. So, this standard, 3390-3, has in some sense solidified in the
industry on zSeries.

There is one device per subchannel. The way you get to a lot of data is that you
have a lot of subchannels/devices. To get to 1.2 TB of data is 512 3390-3 class
devices or 171 3390-9 class devices.

Each subchannel is either ESCON at 10 MB/sec or FICON at 40/MB sec, though ESCON
probably predominates still today. 

Therein lies the problem. Without PAV's, you are confined to one file
transferring data at a time. With PAV's, you can one file per PAV transferring
data at a time.

2.4 GB behind a 10 MB/sec pipe is one thing. 7 GB behind a 10 MB/sec pipe is
quite another. So many people are reluctant to put go with larger volumes.

You will note that the notion of larger volumes on Shark did not really get
interesting until PAV's came around because putting a lot of active data on a
larger volume turns out to be a bottleneck in the hardware architecture. They
are now implementing 32GB devices. But that is not feasible without 1) PAV's and
2) FICON. Otherwise, you spend most of your I/O time queued behind the
subchannel, waiting for it to be free - huge performance bottleneck.

So, people who are not running the latest hardware really cannot do justice to
large volumes and get adequate performance.

And if, as a Linux customer, you have an old device that does not have the
capability of larger volume, you are pretty much stuck.

That is why we do our system volume testing for DB2 on 3390-3 volumes - because
then we know that it will accomodate the vast majority of customers, old and
new. When we try and force a configuration with larger devices, there is a lot
of customer resistance for various reasons.

So RedHat and the other distributors need to take this into account when
implementing these systems in a zSeries environment.

How can we load the a full system on a series of 3390-3 images? Jim - thanks for
your good explanation!

Glen/Greg - Two issues here for Red Hat to consider/fix:

1. How can we install a full system (everything) on a series of standard
   3390-3 volumes (which is about 2.3GB) ?

2. When we specify which packages to install, and if there is not enough
   disk space, the install process loops around.  It should go back and
   allow the user to re-specify which packages to install again.

Thanks.