HPUX11 swap/dump filesystem size

[ISS Unix Admin]

Is there any size limitation for this filesystem?

[Rita C Workman]

Here's a pretty good thread on swap size that may help you:

http://my1.itrc.hp.com/cm/QuestionAnswer/1,1150,0x53a08b55dfd6d4118fef0090279cd0f9!1,00.html

/rcw

[ISS Unix Admin]

I am aware of this article- but what I want to know is whether there is physical limitation on the size of this filesystem.

Can I have a 8Gb SWAP/DUMP filesystem (if I really need to) and will the system still boot.

This all stems from an application providers recommendation that a 4Gb+ partition will prevent the system from booting.

I am trying to understand this limitation.

[Curtis Larson]

what version of the OS are you inquiring about?

[ISS Unix Admin]

I am running HPUX11.0

[Curtis Larson]

using primary swap as your dump device?

[ISS Unix Admin]

Yes

[Patrick Wallek]

http://us-support3.external.hp.com/cki/bin/doc.pl/sid=743952df1bbaa27301/screen=ckiDisplayDocument?docId=200000053360028

Excerpt from the above referenced link:

11.0 (Current Supported sizes for both 32 and 64 bit OS)
Maximum File Size : 128 gigabytes
Maximum Filesystem Size : 128 gigabytes
Maximum Raw Partition Size : 128 gigabytes
Maximum Swap Device Size : 128 gigabytes
Maximum Filesystem Swap Size : 128 gigabytes

I know the file size and file system size is incorrect (should be 2 TB, I think). I'm not sure about the Swap Device Size though.

Nonetheless, you should be OK with 8 GB swap, I think.

[Curtis Larson]

from HP's "Managing Systems and Workgroups: ..." manual:


To prevent possible file corruption, a dump logical volume (or a swap logical volume used for dump) must lie within the first two GB on the physical volume. The lvlnboot command will not allow a dump logical volume to be configured that exceeds two GB (but it will allow such a swap logical volume to be so configured).

now just a bit of speculation on my part. Being hp's boot process is pretty much a 32-bit app. I would suspect that the kernel, primary swap and / (/sbin actually) will need to be in the first 4 GB of the physical disk. And hp's default installation is lvol1 is your kernel (/stand), lvol2 primary swap and lvol3 is /. So if your primary swap (along with /stand) is greater then 4 GB the boot process won't find /. So, technically the system will boot (the kernel will be running), but you wont be able to run anything.

Like I said this is speculation on my part, as in I've never tested it, on 11.X. I do know this was true on some 10.X systems. And the above excerpt was straight out of the 11.X manuals.

[Patrick Wallek]

Somethign I just thought about..... It would probably be more efficient if you had 2 4GB swap areas, or maybe even 4 2GB swap areas, with the same priority as the primary swap, spread over 2 or 4 controllers (if possible) rather than having a single 8 GB swap area. If you are doing a lot of swapping I think your performance would be a bit better this way.

[Curtis Larson]

and from the lvlnboot man page:

A dump logical volume, or a swap logical volume used as a dump volume,
must lie within the first 2 GB (< 2 GB) of the physical volume. The
lvlnboot command will not allow a dump logical volume to be configured
that crosses the 2 GB boundary, but it will allow such a swap logical
volume to be configured.

For a system with high-density memory boards installed, lvlnboot will
be able to support dump logical volumes up to 4 GB of the physical
volume.

If the swap device is used as a dump volume by specifying the dump default in the system file (see config(1M)), care should be taken to
ensure that the swap logical volume does not exceed the 2 GB boundary
(or 4 GB for the system as mentioned above).

[Curtis Larson]

A bit more information for the interested:

at 11.x there are both kernel dump devices and runtime dump devices. for kernel dump devices the above 2G limit would apply. The kernel only knows which drive to write and probably writes to the first filesystem up to a 2G maximum. Now runtime dump devices have greater functionality being they presuppose full system capablities, lvm commands, etc. Basically, runtime devices can be any physical device (/dev/dsk/c0t0d0) or logical volume. Of course, this means that the logical volume or device is accessable at dump time.

1) you have to use kernel dump devices to capture a dump of your system that occurs during the earliest stages of the boot process

2)you don't want runtime dump devices to be used for swap as paging will invalidate the dump.

Using a Device for Both Paging and Dumping

It is possible to use a specific device for both paging (swapping) and as a dump device. If system recovery time is critical to you, do not configure the primary paging device as a dump device. From the savecrash(1M) manpage:


By default, when the primary paging device is not used as one of the dump devices or after the crash image on the primary paging device has been saved, savecrash runs in the background. This reduces system boot-up time by allowing the system to be run with only the primary paging device.

Another advantage to keeping your paging and dump devices separate is that paging will not overwrite information stored on a dump device, no matter how long the system has been up, or how much activity has taken place. Therefore you can prevent savecrash processing at boot time (by editing the file /etc/rc.config.d/savecrash). This can save you a lot of time when you are trying to get your system back up in a hurry. After the system is up and running you can run savecrash manually to copy the memory image from the dump area to the HP-UX file system area.

Using a Device for Both Paging and as a Dump Device

It is possible to use a specific device for both paging purposes and as a dump device. But, if crash dump integrity is critical to you, this is not recommended. From the savecrash(1M) manpage:


If savecrash determines that a dump device is already enabled for paging, and that paging activity has already taken place on that device, a warning message will indicate that the dump may be invalid. If a dump device has not already been enabled for paging, savecrash prevents paging from being enabled to the device by creating the file /etc/savecore.LCK. swapon does not enable the device for paging if the device is locked in /etc/savecore.LCK...

So, if possible, avoid using a given device for both paging and dumping: particularly the primary paging device!

Systems configured with small amounts of memory and using only the primary swap device as a dump device are in danger of not being able to preserve the dump (copy it to the HP-UX file system area) before paging activity destroys the data in the dump area. Larger memory systems are less likely to need paging (swap) space during start-up, and are therefore less likely to destroy a memory dump on the primary paging device before it can be copied.

The only limitation I see is the 2 GB value for kernel defined dump devices. I don't think the 4 GB limit on primary swap is a consideration for 11.x systems. But, from the above, you will have to make some decisions on weather to buy additional discs for dump devices or not, depending on how fast you want to recover the system

[Curtis Larson]

on further note,

Dump Order

In some circumstances, such as when you are using the primary paging device along with other devices, as a dump device, you care about what order they are dumped to following a system crash. In this way you can minimize the chances that important dump information will be overwritten by paging activity during the subsequent reboot of your computer.

The rule is simple to remember:

No matter how the list of currently active dump devices is built (from a kernel build, from the /etc/fstab file, from use of the crashconf command, or any combination of these) dump devices are used (dumped to) in the reverse order from which they were defined. In other words, the last dump device in the list is the first one used, and the first device in the list is the last one used.

Therefore, if you have to use a device for both paging and dumping, it is best to put it early in the list of dump devices so that other dump devices are used first.