Suggestions on How to Use a 6 Disk Boot Subsystem on Large Servers

[Alzhy]

Due to some misunderstanding on some standard that we are to follow, all our servers (vPars and nPars) were ordered with 6 (that is right SIX) bootdisks of 36 GB each -- 3 on each SCSI bus. The servers (vPars and nPars) that will use them are fairly large (8GB to 32 GB of memory). Any suggestions on how to use them? I am thinking:

disk11 and disk21 - PRI and ALT (mirrors)
disk12 and disk22 - Mirrored Swap?
disk13 and disk23 - 3rd and 4th Mirror Respectively.

- We do not put any highly dynamic filesystems on our system VG aside from the necessary minor software in /opt and 3PGNU tools in /usr/local.

- Any issues with dedicating an entire mirror-pair (36GB) to swap? Any issues with very large swap areas in HP-UX?

- We partition our system disks as follows:

/stand - 512MB
initial swap - 8GB.
/root - 8GB
/opt - 4GB
/tmp - 2GB
/var - 8GB


Thoughts? Suggestions...?

[Steven E. Protter]

Last I checked you could not make swap bigger than 16 GB. Swap should be set based on the amount of memory and the load the system will be under. It must be half of physical memory to handle dumps and is generally st between 1.0 and 2.0 times memory.

A. Clay Stephenson recommends(I obviously agree) a small swap area as primary swap and larger ones, preferably on other disks as secondary. This gives best performance when the system isn't running at a high load factor.

I would take the extra space on those local disks and use it for storing make_net_recovery and DR info, maybe even software depots.

I think root is too big.

I set it to 1 GB and don't keep any files in it other than some useful configuration backups and utilities I like to have in single user mode.

I'll think on it some more and perhaps comment further.

SEP

[John Dvorchak]

Since you have 36 GB disks it seems like a serious waste of disk space to make a 36GB swap unless you find that swap space is being pressured later on. I am questioning the 8 GB for /root. It looks like you are intending to put your application in the /root (I am assuming you mean just / not /root) file system which in my opinion is NEVER a good idea. First of all that is vg00 and if it fills you are in a world of hurt. One GB should be just fine on just about any system. Second, I am sure that you will find the popular consesus is to put the application in it's own vg. Third you could have have trouble with your Ignite tapes if all of that space gets full.

With the above in mind you can extend your primary swap to 15 GB on the first pair of disks and use the second and third pair for your applications.

Having excess disk space available is not a bad thing. One thing I have learned is that if you have free disk space now, you won't later.

[Thierry Poels_1]

just love misunderstandings in the good sense :)

/ should suffice with 1G or even 512MB.
/opt & /var love the specified sizes.
/tmp depends on your situation/company/usage ... but 2GB is a nice minimum.
swap : spread this around the 3 disks with same priority

regards,
Thierry.

[Alzhy]

IT friends intending to reply:

- We do not put any data/homdir/applications(with potential of creating large tmp/logs) on System VG's

- Disk is Cheap

- Why separate / & /usr -- they'll be mostly static anyway. /opt large apps will be on saparate filesystems not on the system VG... We were actually opting for /usr and /opt to be under / and /tmp a link to /var/tmp... so that leaves a very minimal number of filesystems for our system VG.

- Big /var -- why not?

[Sundar_7]

I believe you can have a swap that is bigger than 16 GB. maxswapchunks & swchunk are the two kernel parameters to be tuned. leave swchunk as it is at 2 MB and you can tune maxswapchunks upto 16384 which means you can have 16384 * 2 = 32 GB of swa p space configured in the system.

* Since you have huge memory, your swap space dont have to be as big as 32 GB

* Consider creating a seperate dump volume.

* 8 GB for a root file system is way too large. Allocate some more to /opt & /var.

* Consider seperate file systems /var/adm & /var/adm/crash

* what about /home ?

[Pete Randall]

Nelson,

I'm all for a big /var, though 8GB seems more like HUGE than big. Do you have some particular usage of /var that you're allowing for? We have a special case where we've made /var nearly 12GB but I would think that's pretty unique (actually the need has now disappeared but we continue to do it this way).


Pete

[Thierry Poels_1]

Why separate / - /usr - /opt - /tmp ??

for structure, standards, ease of use, protect other filesystems if one is overflowing, ....
Theoretically you only need 3 LVOLs but I cannot see any reason why one would avoid common standards.

best regards,
Thierry.

[Alzhy]

Why NOT?

If your whole disk - with its mirror(s)of course, is going to be used exclusively for OS and system stuff why separate / /usr and /opt? /var obviously needs to be on its own owing to its nature. /tmp can just be a link to /var/tmp.

/opt and /usr overflowing? -- The more reason you'd want them in / as a single filesystem.

Are there some rules that are broken here if I have a minimalist system partitioning scheme? If I do a maintenance boot -- is it not advantageous to have my /usr and /opt also instantly accessible?

On other UNIX boards -- this is still a raging debate - with the minimalist partitioning approach seems to have the upper hand...

Of course -- this is all per ones preference.. We like it this way as we won;t have to worry about system filesystems filling up...

[Steven E. Protter]

There may be a raging debate on other Unix boards, but HP-UX configuration while flexible does not follow the enormous root fs trend.

Check for Bill Hassel's comments on the subject.

You can do anything you want and it will work, but straying too far from the middle of the road makes it that much tougher to get outside help when you need it.

SEP