C H A P T E R 5

Upgrade and Configuration Tasks

This chapter describes the procedures for upgrading a server to a new release of the Sun StorEdge software. Use these procedures if you are upgrading your Sun StorEdge QFS file system. You must perform all the tasks in this chapter as superuser.

This chapter contains the following sections:

- Preparing for an Upgrade

- Removing Existing Sun StorEdge QFS Software

- Adding the Upgrade Packages

- Upgrading File System Manager

- Restoring the File System

- Upgrading the Solaris OS

##

Preparing for an Upgrade

Follow the instructions in this section to prepare for a Sun StorEdge QFS upgrade.

### Upgrade Considerations

When it comes time to upgrade the host system being used for the file system, consider the following:

- It is wise to move to the new host while the existing host is still in operation. This enables you to install, configure, and test the new hardware platform with your applications.

- Moving to a new host system is equivalent to installing the Sun StorEdge QFS software for the first time. In SAM-QFS environments, you need to reinstall the software and update the configuration files (specifically, the `mcf` file, the `/kernel/drv/st.conf` file, and the `/etc/opt/SUNWsamfs/inquiry.conf` file). In addition, you need to copy your existing `archiver.cmd` and `defaults.conf` files to the new system, configure system logging, and so on.

- Before powering down the old host system, decide whether the backup copies you have on hand are sufficient. You might want new dump files to re-create the file system on the new server. For more information about creating a dump file, see Setting Up Dump Files.

### Preserving Information for an Upgrade

If you are about to add or change disks, controllers, or other equipment in your environment, it can be difficult to correct or regenerate all the file system descriptions in the `mcf` file. The `samfsconfig`(1M) command can help you by generating information about your file system and file system components after you make these changes.

The `samfsconfig`(1M) command examines the devices you specify, determines whether any of them have Sun StorEdge QFS superblocks on them, and writes this information to `stdout`. It uses information from the discovered superblocks and aggregates the devices into a format similar to an `mcf` file. You can save this format and edit it to re-create a damaged, missing, or incorrect `mcf` file.

The command can retrieve the Family Set number of the base device (the file system itself), the file system type (`ma` or `ms`), and whether the file system is a Sun StorEdge QFS shared file system.

Irregularities are flagged with one of the following:

- A pound sign (`#`). This indicates incomplete family set information.

- A greater-than sign (`>`). This indicates that more than one device name refers to a particular file system element.

The following examples show output from the `samfsconfig`(1M) command.

#### Example 1

In this example, the system administrator has put a list of device names into a file. These device names were for devices that were not accounted for in the environment and that the system administrator therefore wanted to examine for Sun StorEdge QFS family sets. The results displayed in CODE EXAMPLE 5-1 show some old fragments of family sets and several complete instances.

CODE EXAMPLE 5-1 Example 1 - Output From `samfsconfig` (1M) Command
    mn# samfsconfig -v `cat /tmp/dev_files`
    Device '/dev/dsk/c5t10d0s0' has a SAM-FS superblock.
    Couldn't open '/dev/dsk/c5t10d0s1': I/O error
    Device '/dev/dsk/c5t10d0s3' has a SAM-FS superblock.
    Device '/dev/dsk/c5t10d0s4' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t10d0s5' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t10d0s6' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t10d0s7' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t11d0s0' has a SAM-FS superblock.
    Couldn't open '/dev/dsk/c5t11d0s1': I/O error
    Device '/dev/dsk/c5t11d0s3' has a SAM-FS superblock.
    Device '/dev/dsk/c5t11d0s4' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t11d0s5' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t11d0s6' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t11d0s7' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t12d0s0' has a SAM-FS superblock.
    Couldn't open '/dev/dsk/c5t12d0s1': I/O error
    Device '/dev/dsk/c5t12d0s3' has a SAM-FS superblock.
    Device '/dev/dsk/c5t12d0s4' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t12d0s5' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t12d0s6' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t12d0s7' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t13d0s0' has a SAM-FS superblock.
    Couldn't open '/dev/dsk/c5t13d0s1': I/O error
    Device '/dev/dsk/c5t13d0s3' has a SAM-FS superblock.
    Device '/dev/dsk/c5t13d0s4' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t13d0s5' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t13d0s6' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t13d0s7' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t8d0s0' has a SAM-FS superblock.
    Device '/dev/dsk/c5t8d0s1' has a SAM-FS superblock.
    Device '/dev/dsk/c5t8d0s3' has a SAM-FS superblock.
    Device '/dev/dsk/c5t8d0s4' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t8d0s5' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t8d0s6' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t8d0s7' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t9d0s0' has a SAM-FS superblock.
    Couldn't open '/dev/dsk/c5t9d0s1': I/O error
    Device '/dev/dsk/c5t9d0s3' has a SAM-FS superblock.
    Device '/dev/dsk/c5t9d0s4' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t9d0s5' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t9d0s6' doesn't have a SAM-FS superblock (SBLK).
    Device '/dev/dsk/c5t9d0s7' doesn't have a SAM-FS superblock (SBLK).
    13 SAM-FS devices found.
    #
    # Family Set 'qfs1' Created Mon Jun 25 10:37:52 2004
    #
    # Missing slices
    # Ordinal 0
    # /dev/dsk/c5t8d0s1 10 mm qfs1 -
    #
    # Family Set 'qfs1' Created Wed Jul 11 08:47:38 2004
    #
    qfs1 200 ma qfs1 - shared
    /dev/dsk/c5t8d0s3	201 	 mm 	qfs1  -
    /dev/dsk/c5t9d0s3	202	 mr	qfs1  -
    /dev/dsk/c5t10d0s3	203	 mr	qfs1  -
    /dev/dsk/c5t11d0s3	204	 mr	qfs1  -
    /dev/dsk/c5t12d0s3	205	 mr	qfs1  -
    /dev/dsk/c5t13d0s3	206	 mr	qfs1  -
    #
    # Family Set 'sqfs1' Created Wed Nov  7 16:55:19 2004
    #
    sqfs1 100 ma sqfs1 - shared
    /dev/dsk/c5t8d0s0	101 	 mm 	sqfs1  -
    /dev/dsk/c5t9d0s0	102	 mr	sqfs1  -
    /dev/dsk/c5t10d0s0	103	 g0	sqfs1  -
    /dev/dsk/c5t11d0s0	104	 g0	sqfs1  -
    /dev/dsk/c5t12d0s0	105	 g1	sqfs1  -
    /dev/dsk/c5t13d0s0	106	 g1	sqfs1  -
    #

#### Example 2

In the output shown in CODE EXAMPLE 5-2, the devices flagged with a greater-than sign (>) are duplicated. The `s0` slice starts at the start of disk, as does the whole disk (`s2`) slice. This is the style of output obtained in a Solaris 9 OS.

CODE EXAMPLE 5-2 Example 2 - Output from `samfsconfig` Command
    # samfsconfig /dev/dsk/c3t*
    #
    # Family Set 'shsam1' Created Wed Oct 17 14:57:29 2001
    #
    shsam1 160 ma shsam1 shared
    > /dev/dsk/c3t50020F23000055A8d0s2    161    mm   shsam1  -
    > /dev/dsk/c3t50020F23000055A8d0s0    161    mm   shsam1  -
    /dev/dsk/c3t50020F23000055A8d0s1    162    mr   shsam1  -
    > /dev/dsk/c3t50020F23000078F1d0s0    163    mr   shsam1  -
    > /dev/dsk/c3t50020F23000078F1d0s2    163    mr   shsam1  -
    /dev/dsk/c3t50020F23000078F1d0s1    164    mr   shsam1  -

### Preparing for a Hardware Device Upgrade

This section prepares you for hardware upgrades to devices within your environment.

#### General Prerequisites

Before starting the upgrade process, be sure to do the following:

- Determine whether the hardware addition or change requires a software upgrade from Sun Microsystems.

Examples of changes that do not require a software upgrade include additions to memory and increases in disk cache. Examples of changes that require a software upgrade include changes to the class of your server or significant increases in storage capacity.

- If you are switching from a SPARC to an AMD server platform (or from AMD to SPARC), you must take precautions to prevent loss of data. See Switching Between SPARC and AMD Platforms for details.

- Read the hardware manufacturer's installation instructions carefully. Also read the documentation on adding hardware in your Solaris OS system administrator documentation.

- Check the Equipment Ordinal values in your old and new `mcf` files. For information about the `mcf` file, see the `mcf`(4) man page.

- Decide whether the backup copies you have on hand are sufficient. For information about backing up your data and metadata, see the procedures described in Setting Up Dump Files.

- In a Sun StorEdge QFS environment, the `qfsdump`(1M) command dumps all data and metadata. For more information about this process, see the `qfsdump`(1M) man page.

- In SAM-QFS environments, the `samfsdump`(1M) command dumps all metadata. You must ensure that all files that need to be archived have an archive copy. Use the `archive_audit`(1) command on each SAM-QFS file system to see which files do not have an archive copy. In the following example, `/sam` is the mount point.

    # archive_audit /sam

- Ensure that the system is quiet, with no users logged in.

- In SAM-QFS environments, ensure that the archiver is in `wait` mode. The archiver must be in `wait` mode, and not running, during an upgrade.

You can idle the archiver in one of the following ways:

- By inserting a `wait` directive into the `/etc/opt/SUNWsamfs/archiver.cmd` file. For more information about the `wait` directive and the `archiver.cmd` file, see the `archiver.cmd`(4) man page.

- By using the `samu`(1M) operator utility.

- By issuing the following command:

    # samcmd aridle

For more information, see the `samcmd`(1M) man page.

#### Switching Between SPARC and AMD Platforms

The following are some important considerations if you are combining or changing between SPARC and x86 hardware platforms:

- Sun StorEdge QFS software is supported only for the Solaris 10 OS on x64 platforms (AMD64 architecture), not for the EM64T architecture. With the exception of the Sun StorEdge QFS shared Linux client, it is also not supported for any 32-bit x86 architectures.

- All functions supported by Sun StorEdge QFS software on the SPARC platform are also supported on the x64 platform except for the following:

- The ADIC/Grau, Fujitsu LMF, IBM 3494, and Sony network attached libraries are not supported on x64 platforms. StorageTek ACSLS-attached automated libraries are supported on x64 platforms.

- Optical (MO and UDO) storage libraries and drives are not supported on x64 platforms.

- SANergy software is not supported on x64 platforms.

- SCSI-attached tape drives are not supported on x64 platforms because of a lack of support in the SCSI HBA 64-bit drivers for large block sizes. Both SCSI-attached libraries and fibre-attached libraries are supported with fibre-attached tape drives.

- EFI labels are required on all disks if your Sun StorEdge QFS shared file system configuration contains both the Solaris 10 OS on x64 platforms and the Solaris 9 or Solaris 10 OS on SPARC platforms. See Configuring EFI Labels for Shared x64 and SPARC Volumes for information on relabeling disks.

- You can add Sun StorEdge QFS shared file system Linux clients to Solaris SPARC configurations that are using SMI VTOC8 disk labels and to Solaris AMD64 configurations that are using SMI VTOC16 disk labels. You can also add Sun StorEdge QFS shared file system Linux clients to these configurations when they are using EFI disk labels, but you may need to rebuild the Linux kernel for this capability. This is dependent on the particular Linux distribution. See the Linux client README file for more details.

- You must exercise caution when accessing the same SAN attached storage from a Solaris environment on both SPARC and x64 platforms. The Solaris OS on x64 platforms cannot interpret the SMI VTOC8 disk label created by the Solaris OS on SPARC platforms, and the Solaris OS on SPARC platforms cannot interpret the SMI VTOC16 disk label created by the Solaris OS on x64. This can make it appear as though a disk is unlabeled, when in fact it is labeled and in use by a platform of a different architecture type. For example, a disk that is labeled with SMI VTOC8 may have mounted partitions in use by Solaris on a SPARC platform, but will appear as unlabeled when viewed with the `format`(1M) partition command by Solaris on an x64 platform. If you make the mistake of running `fdisk`(1M) as prompted by the `format`(1M) command, you will destroy the contents of that disk.

- You cannot change the architecture type of the server responsible for control of the file system metadata operations (that is, the server that was used to create the file system with the `sammkfs`(1M) command). For a Sun StorEdge QFS standalone file system, this means that you cannot mount the file system on a server that has a different architecture type from the one that created it. For a Sun StorEdge QFS shared file system, this means that you cannot change the architecture type of the metadata server or any potential metadata servers. This is because the different architectures use different byte-ordering schemes (endianness). However, you can migrate data from one architecture type to the other by copying the file system to temporary storage using either `qfsdump`(1M) or `samfsdump`(1M), re-creating the file system using `sammkfs`(1M), and then repopulating the file system with `qfsrestore`(1M) or `samfsrestore`(1M).

- The Sun StorEdge Traffic Manager I/O multipathing feature (MPxIO) is disabled by default for the Solaris 9 and 10 OS on the SPARC platform and enabled by default for the Solaris 10 OS on x64. This feature should be configured the same way for all systems in your Sun StorEdge QFS shared file system configuration. It is configured in `/kernel/drv/scsi_vhci.conf` for the Solaris 9 OS and in `/kernel/drv/fp.conf` for the Solaris 10 OS.

- In a Sun StorEdge QFS shared file system environment, a configuration error will be generated if you have potential metadata servers of different architecture types (SPARC and x64) defined in the `/etc/opt/SUNWsamfs/hosts.fs` file.

##### Configuring EFI Labels for Shared x64 and SPARC Volumes

| Caution - Relabeling a disk will destroy the contents of that disk.

Use the Solaris `prtvtoc`(1M) command to determine whether a disk contains SMI or EFI labels. Under the Dimensions section of the output, SMI labels list the number of accessible cylinders, whereas EFI labels list the number of accessible sectors.

To convert disk labels from the default SMI VTOC8 to EFI, copy the file system to temporary storage using `qfsdump`(1M) or `samfsdump`(1M), relabel the disks with EFI labels using the `format -e` command, re-create the file system using `sammkfs`(1M), and repopulate the file system with `qfsrestore`(1M) or `samfsrestore`(1M).

When using the Solaris `format -e` command to create EFI labels, you can select the partition command from the menu to create and modify partitions (slices). When doing this, you must specify a tag id name of `usr`, rather than `stand` or `unassigned`, for EFI labels.

Note that EFI labels reserve the first 34 sectors, which misaligns Sun RAID-5 storage from a performance perspective. Unless you realign the storage, you will incur a RAID-5 read/modify/write performance penalty whenever writing. You can avoid this performance penalty by selecting the proper starting sector for all disk partitions for your particular storage configuration. For example, an 8+P Sun StorEdge T3 array with a 64K block size should have starting sectors that are multiples of 1024 for all disk slices ((8 * 64 * 1024) / 512 = 1024). Similarly, a 5+P Sun StorEdge 3510 FC array with a 128K block size should have starting sectors that are multiples of 1280 for all disk slices ((5 * 128 * 1024) / 512 = 1280).

### Backing Up Existing File Systems

Back up your existing file systems if the following conditions exist:

- You are currently using a version 1 superblock with a Sun StorEdge QFS 4U0 system and you want to reinitialize your file systems with a version 2 superblock. In To Reinitialize and Restore the File System, you reinitialize the file systems and restore your data.

- You suspect that your current `qfsdump`(1M) file is incorrect or outdated.

The following subsections explain the differences between these two superblocks and present the procedure for backing up your file systems:

- Using the Version 1 and Version 2 Superblocks

- To Back Up a File System

CODE EXAMPLE 5-3 shows the `samfsinfo`(1M) command you use to retrieve information about the `qfs2` file system. The second line of output indicates that this file system is using a version 2 superblock.

CODE EXAMPLE 5-3 Using `samfsinfo` (1M)
    # samfsinfo qfs2
    samfsinfo: filesystem qfs2 is mounted.
    name: qfs2       version:     2    shared
    time:     Sun Sep 28 08:20:11 2003
    count:    3
    capacity:      05aa8000          DAU:         64
    space:         0405ba00
    meta capacity: 00b4bd20          meta DAU:    16
    meta space:    00b054c0
    ord  eq   capacity      space   device
    	 0  21   00b4bd20   00b054c0   /dev/md/dsk/d0
    	 1  22   02d54000   01f43d80   /dev/dsk/c9t50020F2300010D6Cd0s6
    	 2  23   02d54000   02117c80   /dev/dsk/c9t50020F2300010570d0s6

#### Using the Version 1 and Version 2 Superblocks

Sun StorEdge QFS 4U1 and later releases support both a version 1 superblock and a version 2 superblock. Only the version 2 superblock supports the following features:

- Access Control Lists (ACLs)

- Sun StorEdge QFS shared file system

- `md` devices in Sun StorEdge QFS or SAM-QFS (`ma`) file systems

- Dual-sized disk allocation units (DAUs) on `mm` devices

The Sun StorEdge QFS 4U1 and later releases support both the version 1 and version 2 superblocks. You can use the `sammkfs`(1M) command to create a version 2 superblock, but you cannot initialize any file systems with version 1 superblocks. In addition, it is not possible to move files from a file system with a version 2 superblock back to a file system with a version 1 superblock.

After you reinitialize a file system, you can use the `qfsrestore`(1M) command to restore files to the new file system from the dump file created during the backup process.

If you are upgrading from a Sun QFS 4U0 system, note that the Sun StorEdge QFS 4U0 file system allows you to initialize file systems with either a version 1 or a version 2 superblock. If you want to reinitialize any of the file systems that have a version 1 superblock and remake them with a version 2 superblock, back up these file systems now.

Note - Sun StorEdge QFS 4U2 and later releases do not enable you to initialize a file system with a version 1 superblock. These more recent versions enable you to initialize file systems only with the version 2 superblock.

To Back Up a File System

Follow these steps for each Sun StorEdge QFS file system in your environment.

1. Become superuser from a console connection.

If you have not already logged in as `root`, do so now.

2. Use the `boot`(1M) command to boot the system in single-user mode:

    # boot -s

3. Use the `mount`(1M) command to mount the Sun StorEdge QFS file system.

For example:

    # mount /qfs1

4. Use the `qfsdump`(1M) command to back up the file data and metadata of the Sun StorEdge QFS file system.

The `qfsdump`(1M) command dumps file names, inode information, and file data. The destination of the `qfsdump`(1M) output (generally a file) must be as large as or larger than the Sun StorEdge QFS file system that you are backing up. The destination location (disk or tape) must have enough space to hold the amount of file data and metadata that you are dumping. For more information about using the `qfsdump`(1M) command, see Setting Up Dump Files or see the `qfsdump`(1M) man page.

Dump each file system to a location outside of the Sun StorEdge QFS file system. For more information, see the `qfsdump`(1M) man page.

For example, if you have a file system named `qfs1` (mounted at `/qfs1`) that you want to back up, your choices are as follows:

- You can write the `qfsdump`(1M) output to a tape device.

CODE EXAMPLE 5-4 shows how to write to a tape in device `/dev/rmt/1cbn`.

CODE EXAMPLE 5-4 Writing `qfsdump` (1M) Output to a Tape Device
    # cd /qfs1
    # qfsdump -f /dev/rmt/1cbn

- You can write the `qfsdump`(1M) output to a file in a UFS file system.

CODE EXAMPLE 5-5 shows how to write to a file in a UFS file system.

CODE EXAMPLE 5-5 Writing `qfsdump` (1M) Output to a File in the UFS File System
    # cd /qfs1
    # qfsdump -f /save/qfs/qfs1.bak

- You can initialize a new Sun StorEdge QFS file system, using a Sun StorEdge QFS 4U2 or later release, and perform the `qfsrestore`(1M) command directly in that new Sun StorEdge QFS file system.

This alternative is applicable only if you already have the Sun StorEdge QFS software installed and operational as a file system somewhere in your environment. This alternative also assumes that you want to use the features supported by the Sun StorEdge QFS 4U2 or later release and the version 2 superblock.

For example, assume that you want to write the dump file into a second Sun StorEdge QFS file system called `qfs2` (mounted at `/qfs2`) and that you initialized the `qfs2` file system using Sun StorEdge QFS 4U2 or later software. CODE EXAMPLE 5-6 shows how to accomplish this using commands.

CODE EXAMPLE 5-6 Writing `qfsdump` (1M) Output to a Sun StorEdge QFS File System
    # mount /qfs2
    # cd /qfs1
    # qfsdump -f - | (cd /qfs2; qfsrestore -f -)

For more information about backing up your file systems, see Setting Up Dump Files.

### To Unshare File Systems

Perform this task if your Sun StorEdge QFS file systems are NFS shared file systems.

Use the `unshare`(1M) command on the Sun StorEdge QFS file system.

For example, the following command unshares the `qfs1` file system:

    # unshare /qfs1

### Unmounting File Systems

You can unmount a file system using any of the following methods described in this section. After the file system is unmounted, you can proceed to Removing Existing Sun StorEdge QFS Software.

Note - To unmount a Sun StorEdge QFS shared file system, follow the instructions in the Sun StorEdge QFS Configuration and Administration Guide.

To Unmount Using File System Manager

1. From the Servers page, click the name of the server on which the file system is located.

The File System Summary page is displayed.

2. Select the radio button next to the file system that you want to unmount.

3. From the Operations menu, choose Unmount.

To Unmount Using CLI Commands

Use the `umount`(1M) command to unmount each Sun StorEdge QFS file system.

If necessary, use the `-f` option to the `umount`(1M) command. The `-f` option forces a file system to unmount.

If `umount`(1M) is not successful, it might be because files in the file system are being used or because you have used the `cd` command to change to a directory that is within the file system. In this case, follow these steps:

1. Use the `fuser`(1M) command to determine whether any processes are still busy.

For example, the following command queries the `qfs1` file system:

    # fuser -uc /qfs1

2. If any processes are still busy, use the `kill`(1M) command to terminate them.

3. Use the `umount`(1M) command to unmount each Sun StorEdge QFS file system.

To Unmount by Editing the `/etc/vfstab` File and Rebooting

1. Edit the`/etc/vfstab` file.

For all Sun StorEdge QFS file systems, change the Mount at Boot field from `yes` or `delay` to `no`.

2. Reboot the system.

##

Removing Existing Sun StorEdge QFS Software

Use the `pkgrm`(1M) command to remove the existing software. You must remove the existing Sun StorEdge QFS package before installing the new package.

If you are using any optional Sun StorEdge QFS packages, you should make sure that you remove these packages before removing the main `SUNWqfs` packages. The installation script prompts you to confirm several of the removal steps.

### To Remove Existing Software

1. Use the `pkginfo`(1) command to determine which Sun StorEdge QFS software packages are installed on your system.

For example:

    # pkginfo | grep qfs

2. Use the `pkgrm`(1M) command to remove the existing Sun StorEdge QFS software.

The following example command removes the `SUNWqfsu` and the `SUNWqfsr` packages from a 4U1 release:

    # pkgrm SUNWqfsu SUNWqfsr

Note - The `SUNWqfsr` package must be the last package removed. The 4U1 release does not include any localized software packages.

The following example command removes the `SUNWcqfs`, the `SUNWfqfs`, and the `SUNWjqfs` localized packages from a 4U0 release:

    # pkgrm SUNWcqfs SUNWfqfs SUNWjqfs SUNWqfs

Note - The `SUNWqfs` package must be the last package removed.

##

Adding the Upgrade Packages

The Sun StorEdge QFS software packages use the Sun Solaris packaging utilities for adding and deleting software. The `pkgadd`(1M) command prompts you to confirm various actions necessary to upgrade the Sun StorEdge QFS package.

During the installation, the system detects the presence of conflicting files and prompts you to indicate whether you want to continue with the installation. You can go to another window and copy the files that you want to save to an alternate location.

### To Add the Packages

1. Use the `cd`(1) command to change to the directory where the software package release files reside.

This is one of the following, depending on your release media:

- If you downloaded the release files as described in Obtaining the Release Files, change to the directory to which you downloaded the files.

- If you obtained the release files from a CD-ROM, change to the directory on the CD-ROM that corresponds to your OS version.

2. Use the `pkgadd`(1M) command to upgrade the `SUNWqfsr` and `SUNWqfsu` packages.

For example:

    # pkgadd -d . SUNWqfsr SUNWqfsu

3. Enter `yes` or `y` in response to each of the questions.

During the installation, the system detects the presence of conflicting files and prompts you to indicate whether or not you want to continue with the installation. You can go to another window and copy any files you want to save to an alternate location.

##

Upgrading File System Manager

Perform the task described in this section if you want to be able to use the File System Manager interface.

File System Manager is an online interface that enables you to configure many of the components in a Sun StorEdge QFS environment. You can use this tool to control, monitor, configure, and reconfigure the environment's components.

### To Install the File System Manager Software

1. Log in to the server that you want to use as the management station.

This can be the same server on which you installed the `SUNWqfsr` and `SUNWqfsu` packages.

2. Become superuser.

3. Use the `cd`(1) command to change to the directory where the software package release files reside on your server.

4. Execute the `fsmgr_setup` script to start the installation process.

For example:

    # ./fsmgr_setup

5. Answer the questions as prompted by the `fsmgr_setup` script.

During the installation procedure, you are asked questions about your environment.

The `fsmgr_setup` script automatically installs the following:

- The Tomcat, Java Runtime Environment (JRE), JATO, and Java Web Console packages. If you have existing versions of these software packages that are not compatible with File System Manager, the installation software asks whether you want the appropriate levels to be installed at this time.

- The `SUNWfsmgrr` package.

- The `SUNWfsmgru` package.

After installing the packages, it starts the Tomcat Web Server and enables logging.

6. Log in to the Sun StorEdge QFS server and become superuser.

7. Use the `ps`(1) and `grep`(1) commands to make sure that the `rpcbind` service is running.

    # ps -ef | grep rpcbind

8. Examine the output from the preceding commands.

The output should contain a line similar to the following:

    root   269     1  0   Feb 08 ?        0:06 /usr/sbin/rpcbind

If `rpcbind` does not appear in the output, enter the following command to start the `rcpbind` service:

    # /usr/sbin/rpcbind

9. (Optional) Start the File System Manager (`fsmgmtd`) daemon.

If you did not choose to start the File System Manager daemon automatically during the installation process, do one of the following:

- Enter the following command to start the File System Manager daemon and have it restart automatically every time the daemon process dies. With this configuration, the daemon also automatically restarts at system reboot.

    # /opt/SUNWsamfs/sbin/fsmadm config -a

- Enter the following command if you want the File System Manager daemon to run only once and not automatically restart.

    # /opt/SUNWsamfs/sbin/fsmadm start

For more information, see the `fsmadm`(1M) man page.

10. (Optional) Give additional users access to File System Manager.

If you are upgrading from version 2.0 or earlier, the `samadmin` account from the previous software version will be preserved, but the `samuser` account will be deleted. Logging in with the `samadmin` user name and password will give you full access to all File System Manager features.

By default, the `root` login also has privileges to perform all operations available from the File System Manager software. You can assign other users full access to all File System Manager operations, or access to only a subset of operations.

To give an additional user access to File System Manger, use the `useradd` command. See To Add Users and Assigning Privilege Levels for information about adding users and assigning File System Manager user privilege levels.

For information about using File System Manager see Using the File System Manager Software, or see the File System Manager online help.

##

Restoring the File System

The instructions in this section cover the tasks involved in restoring the Sun StorEdge QFS file system after an upgrade.

### To Verify the `mcf` File

1. Enter the `sam-fsd`(1M) command.

2. Examine the output for errors, as follows:

- If the `mcf` file is free of syntax errors, the `sam-fsd`(1M) output is similar to that shown in CODE EXAMPLE 5-7. It contains information about the file systems and other system information.

CODE EXAMPLE 5-7 `sam-fsd` (1M) Output Showing No Errors
    # sam-fsd
    Trace file controls:
    sam-amld      off
    sam-archiverd off
    sam-catserverd off
    sam-fsd       off
    sam-rftd      off
    sam-recycler  off
    sam-sharefsd  off
    sam-stagerd   off
    sam-serverd   off
    sam-clientd   off
    sam-mgmt      off

- If the `mcf` file contains syntax or other errors, the errors are noted in the output.

If your `mcf` file has errors, refer to Setting Up the Environment Configuration and to the `mcf`(4) man page for information about how to create this file correctly.

Note - If you change the `mcf` file after the Sun StorEdge QFS file system is in use, you must convey the new `mcf` specifications to the Sun StorEdge QFS software. For information about propagating `mcf` file changes to the system, see the Sun StorEdge QFS Configuration and Administration Guide.

### To Modify the `/etc/vfstab` File

Perform this task if you modified the `/etc/vfstab` file in Unmounting File Systems.

Edit this file again, and change the Mount at Boot field for all Sun StorEdge QFS file systems from `no` to `yes` or `delay`.

### To Reinitialize and Restore the File System

In this task, you reinitialize the file systems and restore the saved data in the new file systems. This task completes the process initiated in Backing Up Existing File Systems. To accomplish this, use the `sammkfs`(1M) and `qfsrestore`(1M) commands on each file system.

| Caution - The Sun StorEdge QFS 4U2 and later software does not enable you to initialize a file system with a version 1 superblock. The Sun StorEdge QFS 4U2 file system allows file systems to be initialized only with the version 2 superblock. If you are upgrading from 4U0 using a version 1 superblock, be aware that issuing a 4U2 or later `sammkfs`(1M) command at this point reinitializes your file system with a version 2 superblock.

1. Issue the `samfsinfo`(1M) command and examine the output.

The output tells you the DAU size that was specified with the `sammkfs`(1M) command when the file system was created. You will use this DAU size again in Step 2.

2. Use the `sammkfs`(1M) command to initialize a new Sun StorEdge QFS file system.

The following example command reinitializes a file system named `qfs1` with a DAU size of 512 kilobytes:

    # sammkfs -a 512 qfs1

For more information about the options to the `sammkfs`(1M) command, see the `sammkfs`(1M) man page.

3. Use the `qfsrestore`(1M) command to restore the dumped data in the new file system.

For example, suppose you had a file system named `qfs1` (mounted at `/qfs1`) that you wanted to restore from files dumped to `qfs1.bak`, which existed outside of the Sun StorEdge QFS file system. In this case, you would issue the following commands:

    # cd /qfs1
    # qfsrestore -f /save/qfs/qfs1.bak

### To Check the File System

Perform this task if you did not reinitialize and restore the file system as just described.

Use the `samfsck`(1M) command to check each existing file system for inconsistencies.

For more information, see the `samfsck`(1M) man page.

### Mounting the File System

You can mount the Sun StorEdge QFS file system using File System Manager or the CLI.

To Mount the File System Using File System Manager

1. From the Servers page, click the name of the server on which the file system is located.

The File System Summary page is displayed.

2. Select the radio button next to the file system that you want to mount.

3. From the Operations menu, choose Mount.

To Mount the File System Using the CLI

Issue the `mount`(1M) command.

In the following example, `qfs1` is the name of the file system to be mounted:

    # mount qfs1

### Recompiling API-Dependent Applications

File headers, the calling sequence, and other elements of the Sun StorEdge QFS application programming interface (API) can change from release to release. If you are running applications that use the API, you should recompile them all at this time.

| Caution - Failure to recompile API-dependent applications at this point can cause your applications to generate unexpected results.

##

Upgrading the Solaris OS

The following section describes how to upgrade the Solaris OS when running the Sun StorEdge QFS software.

### To Upgrade the Solaris OS in a Sun StorEdge QFS Environment

Many of the steps involved in upgrading your Solaris OS level are identical to the steps involved in upgrading your Sun StorEdge QFS environment. Some of the steps in this procedure reference procedures in the previous sections.

1. Obtain the Sun StorEdge QFS and Solaris OS software upgrades.

Sun StorEdge QFS software supports various levels of the Solaris OS. You should not reinstall your old Sun StorEdge QFS software on your newly upgraded Solaris OS unless you are sure they are compatible.

Contact your application service provider or Sun Microsystems to obtain new copies of the software.

2. Back up all site-customized system files and configuration files.

These files include `mcf`, `defaults.conf`, `samfs.cmd`, the shared hosts files, and so on. Back up these files for all file systems in your Sun StorEdge QFS environment. Also make sure that you have backup copies of files in the `/etc/opt/SUNWsamfs` directory.

3. Ensure that each affected file system is backed up.

The file systems should be backed up regularly according to your site's policies and as described in Backing Up Data. If you are comfortable with the backup files that already exist for your file systems, there is no need to back them up again now.

4. Unmount the file systems.

For instructions, see Unmounting File Systems.

5. Remove the existing Sun StorEdge QFS software.

You must remove the existing Sun StorEdge QFS package before installing either the new package or the new operating system level. For instructions, see Removing Existing Sun StorEdge QFS Software.

6. Upgrade the Solaris OS.

Install the new Solaris OS revision using the corresponding Sun Solaris upgrade procedures.

7. Add the upgrade packages that you obtained in Step 1.

The Sun StorEdge QFS software package uses the Solaris OS packaging utilities for adding and deleting software. You must be logged in as superuser to make changes to software packages. The `pkgadd`(1M) command prompts you to confirm various actions necessary to upgrade the Sun StorEdge QFS package. For instructions, see Adding the Upgrade Packages.

8. (Optional) Update the `mcf` file.

If device names have changed, it might be necessary to update the `mcf` file to match the new device names. Verify the new device names, and then follow the procedure in Restoring the File System.

9. If your `/etc/vfstab` file does not have `yes` in the `Mount at Boot` field, mount the file systems.

Use the procedure described in Mounting the File System.

Copyright © 2006, Sun Microsystems, Inc. All Rights Reserved.