Adding or Removing a Client Host

This section provides instructions for adding and removing client host systems in a shared file system.

How to Add a Client Host to a Shared File System

You can add a client host to a shared file system after you have configured and mounted the file system on all participants.

Become superuser on the metadata server.
Use the samsharefs command to retrieve the current shared file system information and write it to an editable file.
- If the shared file system is mounted, issue the samsharefs command on the current metadata server. For example:
```
# samsharefs sharefs1 > /etc/opt/SUNWsamfs/hosts.sharefs1
```
- If the shared file system is not mounted, issue the samsharefs command with the -R option from the metadata server or from any of the potential metadata servers. For example:
```
# samsharefs -R sharefs1 > /etc/opt/SUNWsamfs/hosts.sharefs1
```
  You can issue the samsharefs command only on the active metadata server or on client hosts configured as potential metadata servers. For more information, see the samsharefs(1M) man page.

Open the shared file system information file.

For example:

# vi /etc/opt/SUNWsamfs/hosts.sharefs1
# File /etc/opt/SUNWsamfs/hosts.sharefs1
# Host    Host IP    Server    Not    Server
# Name    Addresses    Priority    Used    Host
# ----    --------------------------------    --------    ----    -----
titan    172.16.0.129     1    -    server
tethys    172.16.0.130     2    -
mimas    mimas     -    -
dione    dione     -    -

Add a line for the new client host.

The following code example shows the file after addition of the line for a host named helene as the last line.

# File /etc/opt/SUNWsamfs/hosts.sharefs1
# Host    Host IP            Server      Not     Server
# Name    Addresses          Priority    Used    Host
# ----    ---------------    --------    ----    -----
titan     172.16.0.129         1           -     server
tethys    172.16.0.130         2           -
mimas     mimas                -           -
dione     dione                -           -
helene    helene               -           -

Use the samsharefs command to update the current information in the binary file.
The options to use with this command, and the system from which this command is issued, depend on whether the Sun QFS shared file system is mounted, as follows:
- If the file system is mounted, issue the samsharefs -u command from the current metadata server. For example:
```
# samsharefs -u sharefs1
```
- If the file system is not mounted, issue the samsharefs -R -u command from the active metadata server or from any of the potential metadata servers. For example:
```
# samsharefs -R -u sharefs1
```
  The client host helene is now recognized.
As superuser, log in to the client host to be added.
Use the format command to verify the presence of client host disks.
Update the mcf file on the client host.
Before a host system can access or mount a shared file system, it must have that file system defined in its mcf file. The mcf file must be updated to match all client hosts in the shared file system. The file system and disk declaration information must have the same data for the Family Set Name, Equipment Number, and Equipment Type fields as the configuration on the metadata server. The mcf files on the client hosts must also include the shared keyword. The device names, however, can change, since controller assignments will probably differ from host to host.
For information, see Updating the mcf file in a Shared File System Environment.
Notify the sam-fsd daemon of the configuration changes by issuing the samd config command on the metadata server host.
```
# samd config
```
(Optional) Create the local hosts configuration file on the new client host.
You might want to perform this step if your Sun QFS shared host systems have multiple host interfaces. The local hosts configuration file defines the host interfaces that the metadata server and the client hosts can use when accessing the file system. You use this file to specify how file system traffic should flow over public and private networks in your environment.
For information on creating the local hosts file, see Creating the Local Hosts Configuration File.
If you create this file, use the samd config command on the client host to notify the sam-fsd daemon of the configuration changes.
```
# samd config
```
Verify that the sam-sharefsd daemon is running for this file system.
Use the ps and grep commands as shown in the following code example.
```
# ps -ef | grep sam-sharefsd
root 26167 26158  0 18:35:20 ?        0:00 sam-sharefsd sharefs1
root 27808 27018  0 10:48:46 pts/21   0:00 grep sam-sharefsd
```
The code example above shows that the sam-sharefsd daemon is active for the sharefs1 file system.
If the new Sun QFS shared file system does not already have a mount point, create the directory for the mount point.
For example:
```
# mkdir /sharefs1
```
Give the mount point the 755 set of permissions.
For example:
```
# chmod 755 /sharefs1
```
The permissions must be the same on all participant hosts. 755 is suggested as the initial permission set because users must have execute permission on the mount point in order to be able to use the file system after it has been mounted. After you mount the file systems, the root directory's permissions override this setting.
Modify the /etc/vfstab file.
You must have an entry in the /etc/vfstab file for the Sun QFS shared file system. Specify shared in the Mount Parameters field. In addition, do one of the following:
- If you do not want to mount this file system automatically at boot time, type no in the Mt@boot field.
- If you do want the Sun QFS shared file system to automatically mount at boot, do the following:
  1. Type yes in the Mt@boot field.
  2. Add the bg mount option in the Mt params field.
    The bg mount option mounts the file system in the background if the metadata server is not responding.
The following code example shows the shared and bg entries in the Mt params field.
```
# File /etc/vfstab
# FS name  FS to fsck  Mnt pt   FS type  fsck  Mt@boot  Mt params
#                                        pass
sharefs1   -           /sharefs1 samfs   -     yes      shared,bg
```
Verify that the file system is mounted on the metadata server.
```
# df -k
```
The file system should be included in the displayed list.
From the client host, mount the Sun QFS shared file system.
For example:
```
# mount /sharefs1
```
For more information about mounting Sun QFS shared file systems, see Chapter 12, Mount Options in a Shared File System, or see the mount_samfs(1M) man page.

How to Remove a Client Host From a Shared File System

Become superuser on the metadata server and on all the client hosts.
Note - You can use the samsharefs command to verify that you are logged in to the metadata server or a client host.
Unmount the shared file system on each client host on which the shared file system is mounted.
For example:
```
client# umount sharefs1
```
Unmount the shared file system on the metadata server.
For example:
```
metaserver# umount sharefs1
```
Use the samsharefs command to obtain the current configuration information.
The following example command writes current configuration information to file /etc/opt/SUNWsamfs/hosts.sharefs1.
```
# samsharefs -R sharefs1 > /etc/opt/SUNWsamfs/hosts.sharefs1
```

Open the shared file system information file.

The following code example shows the file before the client host is deleted.

# vi /etc/opt/SUNWsamfs/hosts.sharefs1
# File /etc/opt/SUNWsamfs/hosts.sharefs1
# Host    Host IP         Server      Not     Server
# Name    Addresses       Priority    Used    Host
# ----    ------------    --------    ----    -----
titan     172.16.0.129      1          -      server
tethys    172.16.0.130      2          -
mimas     mimas             -          -
dione     dione             -          -
helene    helene            -          -

In the file, delete the client host or hosts that are no longer to be supported.

The following code example shows the file after the line for helene has been deleted.

# File /etc/opt/SUNWsamfs/hosts.sharefs1
# Host    Host IP          Server      Not     Server
# Name    Addresses        Priority    Used    Host
# ----    --------------   --------    ----    -----
titan     172.16.0.129        1         -    server
tethys    172.16.0.130        2         -
mimas     mimas               -         -
dione     dione               -         -

Use the samsharefs -R -u command to update the current hosts information.
For example:
```
# samsharefs -R -u sharefs1
```
The host helene has been removed.
Use the samsharefs -R command to display the current configuration.
For example:
```
# samsharefs -R sharefs1
```
Mount the shared file system, first on the metadata server and then on each client host in the file system.
For more information, see the mount_samfs(1M) man page.

Updating the `mcf` file in a Shared File System Environment

The samfsconfig command generates configuration information that can help you to identify the devices included in the shared file system. You can then use this information to update the mcf files on each client host.

Issue a separate samfsconfig command on each client host. Note that the controller number might not be the same controller number as on the metadata server because the controller numbers are assigned by each client host.

Note - If you update a metadata server's mcf file after the Sun QFS shared file system is mounted, be sure to update the mcf files on all hosts that can access that shared file system.

Example 5-1 samfsconfig Command Example on tethys

The following example shows the samfsconfig command being used to retrieve device information for family set sharefs1 on client tethys. Because tethys is a potential metadata server, it is connected to the same metadata disks as titan, another metadata server in the shared file system.

tethys# samfsconfig /dev/dsk/*
#
# Family Set &rdquo;sharefs1&rsquo; Created Wed Jun 27 19:33:50 2003
#
sharefs1                         10 ma sharefs1 on shared
/dev/dsk/c2t50020F23000065EEd0s6 11 mm sharefs1 on
/dev/dsk/c7t50020F2300005D22d0s6 12 mr sharefs1 on
/dev/dsk/c7t50020F2300006099d0s6 13 mr sharefs1 on
/dev/dsk/c7t50020F230000651Cd0s6 14 mr sharefs1 on

Copy the last five lines of output from the samfsconfig command into the mcf file on client host tethys. Verify the following:

Each Device State field is set to on.
The shared keyword appears in the Additional Parameters field for the file system name.

The next example shows the resulting mcf file.

Example 5-2 mcf File for sharefs1 Client Host tethys

# Equipment                      Eq  Eq   Family   Dev   Add
# Identifier                     Ord Type Set      State Params
# ----------                     --- ---- ------   ----- ------
sharefs1                         10  ma   sharefs1 on    shared
/dev/dsk/c2t50020F23000065EEd0s6 11  mm   sharefs1 on
/dev/dsk/c7t50020F2300005D22d0s6 12  mr   sharefs1 on
/dev/dsk/c7t50020F2300006099d0s6 13  mr   sharefs1 on
/dev/dsk/c7t50020F230000651Cd0s6 14  mr   sharefs1 on

Example 5-3 samfsconfig Command Example on mimas

The following example shows the samfsconfig command being used to retrieve device information for family set sharefs1 on client host mimas. In this example, mimas can never become a metadata server, and it is not connected to the metadata disks.

mimas# samfsconfig /dev/dsk/*
#
# Family Set "sharefs1" Created Wed Jun 27 19:33:50 2001
#
# Missing slices
# Ordinal 0
# /dev/dsk/c1t50020F2300005D22d0s6   12    mr   sharefs1   on
# /dev/dsk/c1t50020F2300006099d0s6   13    mr   sharefs1   on
# /dev/dsk/c1t50020F230000651Cd0s6   14    mr   sharefs1   on

In the output from the samfsconfig command on mimas, note that Ordinal 0, which is the metadata disk, is not present. For devices that are missing, the samfsconfig process comments out the elements of the file system and omits the file system family set declaration line. Make the following edits to the mcf file:

Create a file system family set declaration line, beginning with sharefs1, in the mcf file for client host mimas. Put the shared keyword in the Additional Parameters field of the file system Family Set declaration line.
Create one or more nodev lines for each missing equipment number entry. For each of these lines, the keyword nodev must appear in the Equipment Identifier field for the inaccessible device.
Ensure that each Device State field is set to on.
Uncomment the device lines.

The following example shows the resulting mcf file for mimas.

Example 5-4 mcf File for Client Host mimas

# The mcf File For mimas
# Equipment                      Eq  Eq   Family   Device Addl
# Identifier                     Ord Type Set      State  Params
------------                     --- ---- ---      -----  ------
sharefs1                         10  ma   sharefs1 on     shared
nodev                            11  mm   sharefs1 on
/dev/dsk/c1t50020F2300005D22d0s6 12  mr   sharefs1 on
/dev/dsk/c1t50020F2300006099d0s6 13  mr   sharefs1 on
/dev/dsk/c1t50020F230000651Cd0s6 14  mr   sharefs1 on

Creating the Local Hosts Configuration File

The local hosts configuration file must reside in the following location:

/etc/opt/SUNWsamfs/hosts._family-set-name_.local

Comment lines must begin with a hash character (#). Characters to the right of the hash character are ignored.

The following table shows the fields in the local hosts configuration file.

Table 5-1 Local Hosts Configuration File Fields

Field

Content

Host Name

This field must contain the alphanumeric name of a metadata server or potential metadata server that is part of the Sun QFS shared file system.

Host Interfaces

This field must contain a comma-separated list of host interface addresses. Use the output from the ifconfig -a command. The individual interfaces can be specified in one of the following ways:

Dotted-decimal IP address form
IP version 6 hexadecimal address form
As a symbolic name that the local domain name service (DNS) can resolve to a particular host interface

Each host uses this field to determine whether it will try to connect to the specified host interface. The system evaluates the addresses from left to right, and the connection is made using the first responding address in the list that is also included in the shared hosts file.

In a shared file system, each client host obtains the list of metadata server IP addresses from the metadata server host.

Note - “Client” as in “network client”, is used to refer to both client hosts and the metadata server host.

The metadata server and the client hosts use both the /etc/opt/SUNWsamfs/hosts.fsname file on the metadata server and the hosts. fsname .local file on each client host (if it exists) to determine the host interface to use when accessing the file system. This process is as follows:

The client obtains the list of metadata server host IP interfaces from the file system's on-disk host file.

To examine this file, issue the samsharefs command from the metadata server or from a potential metadata server.
The client searches its files for a hosts. fsname .local file.

Depending on the outcome of the search, one of the following courses of action is taken:

If a hosts. fsname .local file does not exist, the client attempts to connect, in turn, to each address in the system hosts configuration file until it succeeds.
If the hosts. fsname .local file exists, the client performs the following actions:
1. Compares the list of addresses for the metadata server from both the /etc/opt/SUNWsamfs/hosts.fsname file on the metadata server and the hosts. fsname .local file.
2. Builds a list of addresses that are present in both places, and then attempts to connect to each of these addresses, in turn, until it succeeds. If the order of the addresses differs in these files, the client uses the ordering in the hosts. fsname .local file.

The following example shows a detailed scenario for a shared file system that comprises four hosts.

Example 5-5 Sun QFS Shared File System Hosts File Example

The following example shows a hosts file that lists four hosts.

# File /etc/opt/SUNWsamfs/hosts.sharefs1 
# Host  Host IP           Server     Not    Server 
# Name  Addresses         Priority   Used   Host 
# ----  ----------------- --------   ----   ----- 
titan   172.16.0.129        1         -     server 
tethys  172.16.0.130        2         - 
mimas   mimas               -         - 
dione   dione               -         -

Systems titan and tethys share a private network connection with interfaces 172.16.0.129 and 172.16.0.130. To guarantee that titan and tethys always communicate over their private network connection, the system administrator has created identical copies of /etc/opt/SUNWsamfs/hosts.sharefs1.local on each system.

The following example shows the information in the hosts.sharefs1.local files on titan and tethys.

# This is file /etc/opt/SUNWsamfs/hosts.sharefs1.local 
# Host Name  Host Interfaces 
# --------- --------------- 
titan        172.16.0.129 
tethys       172.16.0.130

Systems mimas and dione are not on the private network. To guarantee that they always connect to titan and tethys through titan's and tethys's public interfaces, the system administrator has created identical copies of /etc/opt/SUNWsamfs/hosts.sharefs1.local on mimas and dione.

The following example shows the information in the hosts.sharefs1.local files on mimas and dione.

# This is file /etc/opt/SUNWsamfs/hosts.sharefs1.local 
# Host Name   Host Interfaces 
# ----------  -------------- 
titan         titan 
tethys        tethys

Skip Navigation Links
Exit Print View
	Sun QFS File System 5.3 Configuration and Administration Guide Sun QFS and Sun Storage Archive Manager 5.3 Information Library