root disk size does it matter?

[A.K.]

I am going to reinstall HPUX 11.00 on HP 9000 servers (N class).
Also, currently I can not upgrade to HPUX 11i due to application constraints
Would it be better to upgrade the current root hard drive from 2X18GB to 2 X 74GB (I have some spare 74GB disks that are not being used).
These disks will be used only for the OS file system.
What are the pros / cons ?
Thanks,
A.K.

[Steven E. Protter · Accepted solution]

Shalom,

Doesn't really matter.

The performance on the smaller disks might be slightly faster but no real users will notice.

Do whats best for you.

SEP

[Patrick Wallek]

The 74GB disks would give you a bit more breathing room for the operating system. If you start running short of space in /var, /opt and any other file system, you would have more room to expand.

If it were me, I would upgrade to the larger disks.

[James R. Ferguson]

Hi:

I'd choose the 74GB disks for maximum flexability and availablity if you need to replace them.

Be sure to mirror your root (vg00) configuration. Be sure, too, to use *one* physical volume for your vg00. That is, *one* plus *one* for a mirror.

Regards!

...JRF...

[A. Clay Stephenson]

The biggest con is that you are going to sorely tempted to use all that wasted space in vg00 for things that don't belong in vg00; if you resist that temptation then go for it although 18GB should be more than sufficient for vg00 (and I'm assumming its 18GB because I know you are mirroring every LVOL in vg00).

[DCE]

AK,

19 GB is adequate for the root disk. It gives you ample space for all of the VG00 mount points.

That being said, it is always nice to have extra space available. I would go for the 74 GB disks, and keep the space in reserve for VG00.

Dave

[A.K.]

Thanks Guys,
I think the same,I should use the 74GB just because it is good to have some extra space for future expanding of the OS FS, yes I am mirroring everything on VG00, and yes I am aware of the temptation.
However, my supervisor object to the idea and his argument is that if you have a free space at some point some application will occupy space on it due to an emergency or convenient ("The only way to get rid of a temptation is to yield to it." - Oscar Wilde ).
This is why I raised this question here because I need to give a good reason why it is better.
Thanks,
Amir

[Bill Thorsteinson]

If you can avoid the temptation to use the
extra space your will gain on on head seek
time.
Given that avg head seek time tends to be
Half the max seek time on a full disk.
you can reduce head seek time by restricting
used space to 1/4 of disk with a corresponding
decrease in head seek time.
Rotational latency will still average
2 / Disk rpm.

[Steven E. Protter]

I had dual 146 GB disks on my last set of rp5450 servers in the states.

I was liberal with the OS and never had issues three years after systems installation.

I used the spare disk space to provide an unmirrored space for and Ignite server and building and breaking patch sets.

Though it can be argued that that doesn't belong in vg00 the disk admin at my last job wasn't ready to give me that amount of space to play with on the SAN and I wanted it local in case the SAN failed, which it did in March of 2005.

SEP

[A. Clay Stephenson]

I really see no problem if you will leave the free PE's as just that. Don't use them for LVOL's. A rather good argument for using the the larger disks (and your boss may buy this one) is that you can now easily have separate dump and swap areas --- which you should be doing anyway. Dump should never be mirrored and swap should always be mirrored and separating the areas also means that a savecrash is no longer necessary because the dump can stay unmolested right where it is. A sometimes lengthy reboot delay to save and compress the dump image to a filesystem is avoided.

One performance-related aspect is that you are going to be tempted to make (or expand it) /var very large so that the busiest directories /var/tmp, /var/spool, ... now reside on one physical disk when these are typically better implemented as separate filesystems on different disks.