swapon error on Creation of New swap Logcal Volume (HP-UX11i v3 MArch 2008)

[WayneHP]

A customer stated they needed to increase the kernel parameter swchunk to 8192 with a total swap size of only 90GB on the system. The man page of swchunk says it can NOW handle 4096TB of swap before increasing from default is needed.

The error about filesystem on the LUN can be ignored. This was indeed a recycled SAN LUN and the swapon -f overcame this issue.

Why is swapon saying to increase swchunk here?

Here is the output.

- pvcreate /dev/rdisk/disk4 <- a 50gb xp24k LUN
- mkdir /dev/vgswap
- mknod /dev/vgswap/group c 64 0x100000
- vgcreate -e 10240 -p 128 -s 32 vgswap /dev/disk/disk4
- lvcreate -l 1599 -r N -C y -n lvswap1 vgswap <- 1599 is total number of PEs on this 50gb LUN
- add "/dev/vgswap/lvswap1 /swap1 swap pri=0 0 0" to /etc/fstab
- swapon -a

This produces the following error:
gvh4121:/# swapon -a
Enabling device paging on /dev/vgswap/lvswap1.
swapon: Device /dev/vgswap/lvswap1 contains a file system.
The system will page in the space after the end of the file system.
Add `end' to the options field in /etc/fstab to turn off this warning.
swapon: The kernel tunable parameter "swchunk" needs to be increased to add
paging on device /dev/vgswap/lvswap1.

AFTER the reboot with the new swchunk size of 8192

swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 8192 0 8192 0% 0 - 1 /dev/vg00/lvol2
dev 51168 0 51168 0% 0 - 0 /dev/vgswap/lvswap1
reserve - 805 -805
memory 30509 3316 27193 11%
total 89869 4121 85748 5% - 0 -

[Don Morris_1 · Accepted solution]

Basic information -- the command is misreporting the error returned. The error is ENOSPC because the file system was on the disk, so the whole disk was not able to be used (the system call returns ENOSPC because it was asked to use the whole disk, but the whole disk isn't available [swapon(2)]). This is interpreted as the whole disk isn't able to be used because of the kernel metadata tunables, hence the message.

You don't need to modify swchunk [you should see the disk fully used regardless after you did the swapon -f].

Extra information -- this has been discovered internally. The number affiliated with it should be QXCR1000798345 -- either keep watch for a swapon(1M) patch which should have this issue, or engage your support contact to determine scheduling/availability of the patch or if you'd like a custom solution first. I don't know the details of who is working on it, so I can't commit to any such information.

[WayneHP]

Thank you Don!!!!!

[WayneHP]

Read Don's reply