|
HP-UX: Dynamically Extend Slash and (or) Stand File Systems
(c) Symmetric Web Sites, Inc. Author: Mark Hopkins Email Date: 10.15.2005
On the HP-UX operating system it is often thought that one must either go through some elaborate
procedure to extend "/" and/or "/stand" file systems, or that it simply cannot be done at all. And
that such an elaborate procedure involves down time and restoring from Ignite-UX which in most cases
requires "after hours" work. In truth, the HP-UX file system is quite flexible,
perhaps due to the underlying and native Veritas "roots". Manipulating any (VXFS) file system under
HP-UX is very easy and can be accomplished dynamically IF the system meets certain prerequisites. This
procedure will examine these requirements and detail the process.
Background The real issue with extending either of these two file systems is that the underlying logical volumes were created with a strict/contiguous extent allocation policy. A logical volume that is created with contiguous block allocation can only be extended if there are more contiguous blocks available. In the case of these two logical volumes the allocation cannot be changed either. So how does one "dynamically" extend either or both of these logical volumes? One way to accomplish this is to move the logical volume somewhere within the volume group where enough total contiguous space exists, and then extend it. Before we can move a logical volume we must certainly break any associated mirrors. This of course creates a single point of failure but only for a short amount of time. Naturally prior to this operation it is highly recommended to take a full image backup of the root volume group with Ignite-UX. The general idea of this solution is to move logical volumes around, extend them and then move them back to form the same logical mirrored environment from which we started. Of course keep in mind that we do not want our users and their applications effected performance-wise at all. Assumptions The assumptions in our case will be that we are starting with a properly mirrored OS; mirrored across two identically sized physical disks, and that all logical volumes are mirrored. We can also assume that this system has been tested successfully booting from the primary boot disk as well as the alternate, but we will take a closer look in the procedure just to make sure. We are also going to assume that we really only want to extend "/". There should hardly ever be a need to extend "/stand". However, if /stand needs extending, this article can be used for instruction. The only difference, since /stand can be unmounted, is that OnLineJFS may be unnecessary. Requirements The requirements for this exercise are really quite basic and most HP "shops" consider them as a "standard", but nonetheless we will list them.
Architecture The following diagram illustrates the method that (by default) the HP-UX installer created file systems. File systems are layed down one after another, contiguously, unless you tell the installer otherwise, which is rarely done. Also depicted is the boot disk configuration used in this article. Notice that the only volume, if all were created strict/contiguous, that could be extended would be lvol8. |
|
|
|
For the remainder of this article, we will refer to the two physical disks as the "primary" and
"alternate" boot disks.
|
|
Procedure Now that we have laid the groundwork, let's get going with the actual steps. Remember that all we are really doing is (1) breaking all mirrors, (2) moving (pvmove) data to a place where it can be extended, (3) moving it back to where we started, and (4) establishing the mirrors.
IMPORTANT!!!!!!! DO NOT PROCEED WITHOUT A FULL OS BACKUP! There are several ways and several products that
can be used to backup your Operating System. We prefer Ignite-UX, but there are others. OS image-level
backups are outside the scope of this article so we will not do one here. You certainly can assume that we
have protected ourselves prior to moving to the next steps of this exercise.
First, let's check things out and make sure (as best we can) that all the prerequisites have been met. Check
to see if the appropriate software has been installed as follows:
|
|
|
|
Next, let's take a look at the booting configuration of the root volume group (vg00). Since we are in a
situation where a reboot is not possible, we are going to assume that whoever set this system up did so
correctly and tested booting from both the primary and alternate boot device. After performing this
procedure the system should be booted again from both devices whenever it can be scheduled. The following
are some commands to execute that will give you a good idea if the system has been configured correctly
but are still no guarentee.
|
|
|
|
So how do we confirm that we have a problem extending the "/" file system? Let's try to extend it "as
is". The following example tells you exactly what the problem is, but of course we already knew this
didn't we?
|
|
|
|
Break all mirrors as shown here.
|
|
|
|
After all mirrors are broken, we expect the alternate boot disk to now be
empty. Verify this fact as shown below.
|
|
|
|
Now we begin the interesting part of this exercise. Recall that we are only interested in extending
"/" or lvol3. Since lvol3 has a strict/contiguous extent allocation policy we must put it somewhere
with available extents immediately following the logical volume itself. This part of the exercise
can probably be done any number of ways. Our way will be to move (pvmove) lvol1, lvol2, and lvol3
to the alternate boot disk, respectively. Logical volume lvol3 must be the last one moved.
|
|
|
|
Now that we have moved lvol3 to a "good place" we can extend it as necessary. We have chosen to extend
it from 250MB to 300MB. Use lvextend and fsadm as shown below. Notice we no longer get the error we
saw earlier, because there ARE now available extents immediately following lvol3.
|
|
|
|
It seems to us that at this point we will simply move (pvmove) the remaining logical volumes
to the alternate boot disk, appending them to the newly extended lvol3. Once there we can simply
(?) mirror back
to the primary boot disk.
|
|
|
|
Now you should verify that the primary boot disk is actually empty as shown below.
|
|
|
|
Now comes the "smoke and mirrors (no pun intented)" part of the procedure. The intent is to
mirror all the logical volumes back to their original state and when completed, have a
perfectly bootable (primary and alternate) system. Of course the only difference that we
want to see is an extended "/" file system. We will not elaborate on the individual
commands used below, but if you are seasoned enough to follow this article that you should
have already had experience with all the commands. If not, look them up prior to their
execution. Below you can see that we remove the primary boot disk from the volume group,
re-initialize it and then bring it back into vg00.
|
|
|
|
Continue preparing the primary boot disk.
|
|
|
|
Now that the primary boot disk as back in vg00 and has been prepared, mirror all logical volumes
from the alternate boot disk to the primary boot disk as shown below.
|
|
|
|
After the mirrors have been successfully created, re-execute the commands from above that check
out the boot configuration of vg00. It should look exactly as it did then.
|
|
|
|
IMPORTANT!!!!!! Now that you have completed this exercise, you will want to schedule
a reboot to test booting from both primary and alternate boot devices. Also it would not
hurt to get another image-level backup at this time since you have now changed the OS.
|
|
Conclusion
Well, there you have it! If you are not familiar with HP-UX disk layouts and the LVM command set, it
might seem a little complicated. But if you are comfortable with the concepts and commands, the only
slow part of this exercise will be waiting on particular commands (pvmove, lvextend) to complete.
|
|
Printing This Article
If you have trouble printing this article, be sure to set your browser Page Properties correctly. Go
to File -> Page Setup and set your left and right margins to .125 inches.
|