Bug 445850 - swap size limited to 8GB with --recommended
swap size limited to 8GB with --recommended
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda (Show other bugs)
4.5
All Linux
low Severity medium
: rc
: ---
Assigned To: Martin Sivák
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-09 08:47 EDT by Alexander Todorov
Modified: 2008-06-09 06:09 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-05 10:23:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
log files from install (25.30 KB, application/octet-stream)
2008-05-09 08:48 EDT, Alexander Todorov
no flags Details
The updates image with kickstart.py patched. (1.00 MB, application/octet-stream)
2008-06-05 04:24 EDT, Joel Andres Granados
no flags Details
new updates image with the log messages only (1.00 MB, application/octet-stream)
2008-06-05 04:34 EDT, Joel Andres Granados
no flags Details
updates with the kickstart.py file (1.00 MB, application/octet-stream)
2008-06-05 04:35 EDT, Joel Andres Granados
no flags Details

  None (edit)
Description Alexander Todorov 2008-05-09 08:47:09 EDT
+++ This bug was initially created as a clone of Bug #339001 +++

Description of problem:

According to the documentation for RHEL4, "Swap should equal 2x physical RAM for
up to 2 GB of physical RAM, and then 1x physical RAM for any amount above 2 GB"
(http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/x8664-multi-install-guide/s1-diskpartitioning.html#S2-DISKPARTRECOMMEND)

However, on systems with >2G of RAM, only 2G is allocated when the "recommended"
option is used in kickstart configurations.



Version-Release number of selected component (if applicable):

Tested on, but not limited to RHEL 4.5, anaconda-10.1.1.63-4
I looked at RHEL5 and it has the same problem, but I didn't test it.


How reproducible:

Very consistently, unfortunately.


Steps to Reproduce:

Assuming you have PXE/kickstart environment set up already:
1. Create a kickstart file with the line:
           part swap --recommended --asprimary
   as the partitioning line for swap

2. PXE boot and kickstart a system with more than 2G of memory and sufficient
disk space such that the maximum amount of swap could be allocated (147G of
disk, for instance).
  
Actual results:

2G of swap.

Expected results:

More than 2G of swap (10G in the case of an 8G systems)

Additional info:

We use PXE boots with kickstart; non-interactive; partitioning line as mentioned
above; all systems with >2G of memory (usually 8G); all systems have >100G of
disk space.

The logic for determining swap size maximizes the swap at 2G (probably due to a
legacy filesystem size limit). 

By applying the following patch to the stage2.img in the file
/usr/lib/anaconda/iutil.py, the correct amount of swap is created:

*** iutil.py-   1969-12-31 17:00:00.000000000 -0700
--- iutil.py    1969-12-31 17:00:00.000000000 -0700
***************
*** 256,259 ****
--- 256,264 ----
          maxswap = 192
      else:
+         if mem > 2000:
+             memextra = mem - 2000
+             minswap = 2000
+             maxswap = 4000 + memextra
+         else:
              if mem > 1000:
                  minswap = 1000

Only tested on system with >2G of memory (4G and 8G). And isn't a megabyte 1024,
not 1000? :)

-- Additional comment from dlehman@redhat.com on 2007-11-12 12:56 EST --
Martin, here's another one about swap and autopart.

-- Additional comment from atodorov@redhat.com on 2008-02-06 04:55 EST --
qa_ack'ing, reproducer in comment #0

-- Additional comment from errata-xmlrpc@redhat.com on 2008-04-15 17:24 EST --
Bug report changed from MODIFIED to ON_QA status by the Errata System: 
Advisory RHBA-2008:8333-01: 
http://errata.devel.redhat.com/errata/show/7301


-- Additional comment from atodorov@redhat.com on 2008-04-24 09:40 EST --
Observations from latest 4.7 tree available:
environment: Xen/PV guest, i386, start up memory = maximum memory

mem: 8GB, install: manual, choose auto partition (e.g. lvm) - 10GB (as expected)
mem: 8GB, install: ks.cfg w/ swap --recommended - 8GB swap partition is created

mem: 5GB, install: manual, choose auto partition (e.g. lvm) - 7GB (as expected)
mem: 5GB, install: ks.cfg w/ swap --recommended - 7GB (as expected)

Only for the 8GB case the --recommended is not creating partition with the
expected size. Still investigating this with Martin to figure out what is wrong.

-- Additional comment from atodorov@redhat.com on 2008-04-29 08:03 EST --
moving back to assigned as per comment #4

-- Additional comment from atodorov@redhat.com on 2008-04-30 10:13 EST --
after more investigation I will move this to VERIFIED.
The swap calculation is fixed but there is a limit of 8GB hard coded in anaconda
hence the results in comment #4.

This limit is not documented and bug #437089 is used to track that.

-- Additional comment from dlehman@redhat.com on 2008-04-30 11:57 EST --
I still do not see where a limit of 8GB is enforced. The max size (maxSizeMB) in
fsset.swapFileSystem is 8TB, not 8GB.

-- Additional comment from msivak@redhat.com on 2008-05-02 05:12 EST --
Ups. you are right.. damn math. But even when it is not in the partitioning
limit, the limit is somewhat enforced during autopart.. but i have no idea
where. It works correctly during manual partitioning.

-- Additional comment from atodorov@redhat.com on 2008-05-05 07:25 EST --
wrt to comment #6:

the limit mentioned is the value of self.maxSizeMB in class swapFileSystem in
fsset.py which is actually 8TB not GB. Anyway something is preventing the
creation of swap partition larger than 8GB when using '--recommended'.

Using bug #437089 to document that. The problem reported with this bug was fixed
(i.e. the formula calculating the swap size was fixed to calculate the correct
size).
Comment 1 Alexander Todorov 2008-05-09 08:48:56 EDT
Created attachment 304939 [details]
log files from install

ks.cfg used to install contains:

zerombr
clearpart --all --initlabel

part /boot --fstype ext3 --size=100   --asprimary
part swap --recommended --asprimary
part /	   --fstype ext3 --size=10000 --grow --asprimary
Comment 2 Alexander Todorov 2008-05-09 08:53:12 EDT
while bug #339001 fixes the formula for calculated the recommended swap size
there is something that prevents anaconda from creating swap partitions larger
than 8GB. I've tested with virtual guests with 8 and 10 GB of memory and the
result is almost the same - around 8GB of allocated swap space.

Manual install however is allocating the swap size as expected (i.e. 10GB swap
partition for 8GB memory) - see comments above. The problem is only when using
the --recommended option in kickstart. 

The attached logs in comment #1 are from 8GB system. Also note that the
generated anaconda-ks.cfg files shows correct value for the swap partition (10GB).
Comment 4 David Lehman 2008-05-12 18:24:29 EDT
Have you tried to create a swap partition of 10GB using the installer's manual
partitioning interface? I am starting to wonder if this limitation is being
imposed based on partition type as opposed to filesystem type.

Another interesting test would be to try the following partitioning info via
kickstart (you may need another PV depending on the disk layout, but you get the
main idea):

clearpart --all --initlabel
zerombr
part /boot --fstype ext3 --size=100
part pv.0 --size=0 --grow
volgroup VolGroup00 pv.0
logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow
logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --recommended

Comment 5 Alexander Todorov 2008-05-13 05:58:26 EDT
Dave,
I'm able to create 10GB swap partition when performing the install manually on a
8GB system:
* Default settings (aka lvm layout) yields 10GB swap space
* Manual settings (disk druid) - swap, / (as primary) and /boot. swap is 10GB

The above kickstart code also yields around 22GB (21.96) swap partition on a
20GB system (as expected).

So the problem is only when using kickstart and raw swap partition, not lvm
Comment 6 David Lehman 2008-05-14 12:04:25 EDT
Have you tried the swap partition via kickstart without --asprimary?
Comment 7 David Lehman 2008-05-21 13:15:19 EDT
Martin, since you are at least within an hour or two of Alexander's timezone,
and since you fixed the original swap size bug, it makes sense for you to handle
this one.
Comment 8 David Lehman 2008-05-21 13:16:15 EDT
Whoops, I meant to do this along with the previous comment.
Comment 11 Joel Andres Granados 2008-06-05 04:24:46 EDT
Created attachment 308418 [details]
The updates image with kickstart.py patched.

I found that in the kickstart.py file, unlike other parts of anaconda in 4.7,
the partRequest gets created without specifying the requestSize variable.  This
updates image contains a patch kickstart.py file.  Please test and see if the
bug reproduces with this updates image.  It also containes additional log
information.
Comment 12 Joel Andres Granados 2008-06-05 04:34:20 EDT
Created attachment 308419 [details]
new updates image with the log messages only

This updates image tracks the requestSize variable as well
Comment 13 Joel Andres Granados 2008-06-05 04:35:40 EDT
Created attachment 308420 [details]
updates with the kickstart.py file

This updates images tracks the requestSize and contains a patch for the
kickstart.py file
Comment 14 Joel Andres Granados 2008-06-05 10:15:24 EDT
Found the reasoning for this issue:

background info:
When you use the "--recommended" argument in the kickstart file you are really
setting a startSize and a maxSize (this is done by a function that is equal in
lvm and partitions) and grow is set to True.  After this is done it is up to the
grow function to make the sizes fit the disk or lvm volume group.

There are two grow functions:
The lvm grow function does its job by growing every partition in the proportion
of its current state.

The part grow function AFAIKS grows the partitions in order that it finds them,
so it first grows the "/" partition and then the "/boot" patition.... as it
finds them in the structure that holds that parititions that should be grown. 
It will grow each partition by a half of its possible growth, check for validity
and continue to grow until it finds that the parition is invalid if it continues
to grow.

I think there is a case to be made here in the sense that the lvm grow and part
grow should be similar.  But the last stages of rhel4 is not the place to do it.
 I would put this into the long list of stuff to do for partitioning in fedora.
Comment 15 Alexander Todorov 2008-06-09 06:09:08 EDT
Filed against Fedora 9 as big #450504

Note You need to log in before you can comment on or make changes to this bug.