| Sun StorEdge QFS and Sun StorEdge SAM-FS File System Administration Guide |    
|
| Sun StorEdge QFS and Sun StorEdge SAM-FS File System Administration Guide |
|
| C H A P T E R 5 |
|
Sun StorEdge QFS Shared File System |
A Sun StorEdge QFS shared file system is a distributed file system that can be mounted on multiple Solaris operating system (OS) host systems. In a Sun StorEdge QFS shared file system environment, one Solaris OS host acts as the metadata server for the file system, and additional hosts can be configured as clients. You can configure more than one host as a potential metadata server, but only one host can be the metadata server at any one time. There is no limit to the number of Sun StorEdge QFS shared file system mount points.
The advantage of the Sun StorEdge QFS shared file system is that file data passes directly from the Fibre Channel disks to the hosts. Data travels via local path I/O (also known as direct access I/O). This is in contrast to the Network File System (NFS), which transfers data over the network.
This chapter describes how to configure and maintain the Sun StorEdge QFS shared file system. It includes the following sections:
The Sun StorEdge QFS shared file system can be configured in either a Sun StorEdge QFS or a Sun SAM-QFS environment, as follows:
You must specify the archive media in the mcf file or in the diskvols.conf file on each host that can become a metadata server.
In a Sun SAM-QFS environment, the active metadata server is the only host upon which the staging (sam-stagerd) and archiving (sam-archiverd) daemons are active. The metadata server is designated as the server from which all file requests are staged.
This chapter describes how to configure and maintain a Sun StorEdge QFS shared file system. It assumes that you have installed the Sun StorEdge QFS or Sun SAM-QFS software on the host systems according to the instructions in the Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide.
|
Note - The Sun StorEdge QFS shared file system cannot be configured in a Sun StorEdge SAM-FS (an ms file system) environment. |
FIGURE 5-1 illustrates a Sun StorEdge QFS shared file system configuration in a Sun SAM-QFS environment.
[ D ]
FIGURE 5-1 shows four network-attached hosts: titan, tethys, dione, and mimas. The tethys, dione, and mimas hosts are the clients, and titan is the current metadata server. The titan and tethys hosts are potential metadata servers.
The archive media consists of a network-attached library and tape drives that are fibre-attached to titan and tethys. In addition, the archive media catalog resides in a file system that is mounted on the current metadata server, titan.
Metadata travels to and from the clients to the metadata server over the network. The metadata server makes all modifications to the name space, and this keeps the metadata consistent. The metadata server also provides the locking capability, the block allocation, and the block deallocation.
Several metadata disks are connected to titan and tethys, and these disks can only be accessed by the potential metadata servers. If titan were unavailable, the metadata server could failover to tethys, and the library, tape drives, and catalog could be accessed by tethys as part of the Sun StorEdge QFS shared file system. The data disks are connected to all four hosts by a Fibre Channel connection.
The examples in this chapter use the preceding configuration several times to explain aspects of the Sun StorEdge QFS shared file system.
The following sections describle the system requirements that must be met in order for you to install a Sun StorEdge QFS shared file system.
There must be at least one Solaris metadata server. To use this file system effectively in a failover (high availability) environment, there must be at least one other Solaris OS system that can become the metadata server; the other servers are known as potential metadata servers.
The following are configuration recommendations with regard to metadata:
Ensure that your configuration meets the following operating system and hardware requirements:
Ensure that your configuration meets the following Sun StorEdge QFS requirements:
The preceding message is written to the metadata server's /var/adm/messages file.
You must be licensed for the Sun StorEdge QFS shared file system. This license is separate from your Sun StorEdge QFS license. Contact your Sun sales representative for information about obtaining a license for the Sun StorEdge QFS shared file system.
In a Sun SAM-QFS environment, the storage and archive management software must be known to be operational prior to the configuration of the Sun StorEdge QFS shared file system.
If you want to be able to change the metadata server, such as in a Sun SAM-QFS failover environment, the following requirements must be met:
The following sections describe the process for creating a Sun StorEdge QFS shared file system. The procedures in this process assume that you have the Sun StorEdge QFS or Sun SAM-QFS package installed and configured correctly on all Solaris Operating Systems (OSs) that are to be part of the Sun StorEdge QFS shared file system. For information about the installation process, see the Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide.
The configuration process consists of several procedures. The following configuration procedures must be performed in the order in which they appear:
|
Review Configuration Requirements.
|
You can use the following procedure to do the initial configuration work for one metadata server and one or more client hosts in a Sun StorEdge QFS shared file system.
1. As superuser, log in to each Solaris system to be configured as a shared host in the Sun StorEdge QFS shared file system.
You must have root permission to complete the steps in this procedure.
2. Issue the pkginfo(1M) command and examine its output to make sure that a Sun StorEdge QFS or a Sun StorEdge SAM-FS package is installed on each host.
Each shared host must have either the SUNWqfsr/SUNWqfsu packages or the SUNWsamfsr/SUNWsamfsu packages installed upon it.
On a system already running Sun SAM-QFS, CODE EXAMPLE 5-1 shows the needed SUNWsamfsr/SUNWsamfsu packages.
3. Issue the samcmd(1M) l (lowercase L, for license) command and examine its output to determine whether or not the shared file system license is enabled.
CODE EXAMPLE 5-2, which has been edited for inclusion in this manual, shows the shared file system license enabled.
If this license is not enabled, contact your Sun sales representative or your authorized service provider for information on enabling the correct license key.
4. Issue the format(1M) command and examine its output.
Make sure that the metadata disk partitions configured for the Sun StorEdge QFS shared file system mount point are connected to the potential metadata servers. Also make sure that the data disk partitions configured for the Sun StorEdge QFS shared file system are connected to the potential metadata servers and to all the client hosts in this file system.
CODE EXAMPLE 5-3 shows the format(1M) command output for titan. There is one metadata disk on controller 2, and there are three data disks on controller 3.
CODE EXAMPLE 5-4 shows the format(1M) command output for tethys. There is one metadata disk on controller 2, and there are four data disks on controller 7.
Note the following in CODE EXAMPLE 5-4:
CODE EXAMPLE 5-5 shows the format(1M) command's output for mimas. This shows three data disks on controller 1 and no metadata disks.
CODE EXAMPLE 5-4 and CODE EXAMPLE 5-5 show that the data disks on titan's controller 3 are the same disks as mimas' controller 1. You can verify this by looking at the World Wide Name, which is the last component in the device name. For titan's number 3 disk, the World Wide Name is 50020F2300005D22. This is the same name as number 3 on controller 1 on mimas.
5. Verify that all the hosts have the same user and group IDs.
If you are not running the Network Information Name service (NIS), make sure that all /etc/passwd and all /etc/group files are identical. If you are running NIS, the /etc/passwd and /etc/group files should already be identical.
For more information about this, see the nis+(1) man page.
6. Set up the network time daemon command, xntpd(1M), to synchronize the times on all the hosts.
The clocks of the metadata server and all client hosts must be synchronized during Sun StorEdge QFS shared file system operations. For more information, see the xntpd(1M) man page.
|
You configure one metadata server in a single Sun StorEdge QFS shared file system.
1. As superuser, log in to the system to be used as the primary metadata server.
You must have root permission to complete the steps in this procedure.
2. Back up all site-customized system files and configuration files.
Depending on your software, these files can include mcf, archiver.cmd, defaults.conf, samfs.cmd, inquiry.conf, and so on. Back up these files for all file systems. Also make sure that you have backup copies of files in the /etc/opt/SUNWsamfs directory, files in the /var/opt/SUNWsamfs directory, library catalogs, the historian, and any parameter files for network-attached automated libraries.
In Sun SAM-QFS environments, if you do not know the names and locations of your catalog files, examine the mcf file with vi(1) or another viewing command and find the entries for the automated libraries. The path to each library's catalog files is in the Additional Parameters field. If the Additional Parameters field is blank, however, the system uses the default path of /var/opt/SUNWsamfs/catalog/catalog_name. For more information about catalog file locations, see the mcf(4) man page.
3. Ensure that each file system to be modified is backed up. (Optional)
If you are creating a new file system as a Sun StorEdge QFS shared file system, you do not need to complete this step.
If you want to move files from an existing Sun StorEdge QFS or Sun SAM-QFS file system into a new Sun StorEdge QFS shared file system, make sure that your file systems are backed up. The file systems should be backed up regularly according to your site's policies. This is described as the last step in the installation procedure. 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. If, however, you need to back up your file systems to preserve information created since the last dump file was created, do so now. For information about how to create a dump file, see the Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide.
To back up a Sun StorEdge QFS file system, use the qfsdump(1M) command, which dumps both data and metadata. To back up a Sun SAM-QFS file system, use the samfsdump(1M) command. Note that the samfsdump(1M) command issues warnings when creating the dump file if it encounters unarchived files in the file system. If warnings are issued, these files need to be archived before unmounting the file systems.
4. Modify the mcf file on the metadata server to include the Sun StorEdge QFS shared file system.
The only difference between the mcf files of a Sun StorEdge QFS shared file system and an unshared Sun StorEdge QFS file system is the presence of the shared keyword in the Additional Parameters field of the file system name line of a Sun StorEdge QFS shared file system, as follows:
For information about creating an mcf file for a Sun StorEdge QFS or Sun SAM-QFS file system, see Volume Management.
CODE EXAMPLE 5-6 shows an mcf file fragment for titan that defines several disks for use in the Sun StorEdge QFS shared file system. It shows the shared keyword in the Additional Parameters field on the file system name line.
5. Create the hosts file on the metadata server.
Using vi(1) or another editor, create an ASCII hosts file that contains configuration information pertaining to all hosts in the Sun StorEdge QFS shared file system. The ASCII hosts file defines the hosts that can share the Family Set name.
Hosts files must reside in /etc/opt/SUNWsamfs/hosts.fs_name, where fs_name is the Family Set name of the Sun StorEdge QFS shared file system. Comments are permitted in the hosts file. Comment lines must begin with a pound character (#). Characters to the right of the pound character are ignored.
TABLE 5-1 shows the fields in the hosts file.
The system reads and manipulates the hosts file. You can use the samsharefs(1M) command to examine metadata server and client host information about a running system.
Example. CODE EXAMPLE 5-7 is an example hosts file that shows four hosts.
CODE EXAMPLE 5-7 shows a hosts file that contains fields of information and comment lines for the sharefs1 file system. In this example, the Server Priority field contains the number 1 in the Server Priority field to define the primary metadata server as titan. If titan is down, the next metadata server is tethys, and the number 2 in this field indicates this secondary priority. Note that neither dione nor mimas can ever be a metadata server.
6. Issue the samd(1M) config command on the metadata server host.
This command informs the sam-fsd daemon of the configuration changes. For example:
7. Use the sammkfs(1M) command to initialize a new Sun StorEdge QFS shared file system.
This step differs depending on whether you are creating a Sun StorEdge QFS shared file system from an existing file system or whether the Sun StorEdge QFS shared file system is completely new.
a. If you are creating a Sun StorEdge QFS shared file system from an existing file system, use the sammkfs(1M) and samsharefs(1M) commands to initialize the new file system and the hosts file.
Use these commands in the formats shown in CODE EXAMPLE 5-8.
# samfsck -S -F fsname # samsharefs -u -R fsname |
For fsname, specify the Family Set Name of the file system from which you are creating the new Sun StorEdge QFS shared file system.
b. If you are creating a completely new Sun StorEdge QFS shared file system, use the sammkfs(1M) command to initialize the file system.
Enter the sammkfs(1M) command at the system prompt. The -S options specifies that the file system be a Sun StorEdge QFS shared file system. Use this command in the following format:
For more information about the sammkfs(1M) command, see the sammkfs(1M) man page. For example, you can use the following sammkfs(1M) command to initialize a Sun StorEdge QFS shared file system file system and identify it as shared:
If the shared keyword appears in the mcf file, the file system must have been initialized as a shared file system by using the -S option to the sammkfs(1M) command. You cannot mount a file system as shared if it was not initialized as shared.
8. Issue the samd(1M) config command on the metadata server host.
This command informs the sam-fsd daemon of the configuration changes. For example:
9. Use the ps(1) and grep(1) commands to verify that the sam-sharefsd daemon is running for this file system.
CODE EXAMPLE 5-9 shows these commands.
CODE EXAMPLE 5-9 shows that the sam-sharefsd daemon is active for the sharefs1 file system. If this is the case for your system, you can proceed to the next step in this procedure. If, however, the output returned on your system does not show that the sam-sharefsd daemon is active for your Sun StorEdge QFS shared file system, you need to perform some diagnostic procedures. For information about these procedures, see Recovering a Hung mount(1M) Command.
10. Create the mount point for the new Sun StorEdge QFS shared file system. (Optional)
If your mount point already exists, you do not need to complete this step.
If you need to create a mount point, however, use the mkdir(1) command to create the directory for the mount point. For example:
11. Issue the chmod(1M) command to give the mount point the 755 set of permissions.
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 mounting the file systems, the root directory's permissions override this setting.
12. Modify the /etc/vfstab file.
You must have an entry in the /etc/vfstab file for the Sun StorEdge QFS shared file system.
If you want the Sun StorEdge QFS shared file system to automatically mount at boot, modify the /etc/vfstab file and put yes in the mount at boot field. If you put yes, Sun Microsystems recommends also adding the bg mount option in the Mount Parameters field. The bg mount option mounts the file system in the background if the metadata server is not responding.
If you do not want to mount this system automatically at boot time, put no in the mount at boot field. In either case, shared is a required entry in the Mount Parameters field. CODE EXAMPLE 5-10 shows a completed /etc/vfstab file.
# File /etc/vfstab # FS name FS to fsck Mnt pt FS type fsck pass Mt@boot Mt params sharefs1 - /sharefs1 samfs - yes shared,bg |
13. Use the mount(1M) command to mount the Sun StorEdge QFS shared file system on the metadata server.
For failover purposes, the mount options should be the same on the metadata server and all potential metadata servers. For example, you can create a samfs.cmd(4) file containing mount options and copy it to all the hosts.
For more information about mounting Sun StorEdge QFS shared file systems, see Mount Options in a Sun StorEdge QFS Shared File System or see the mount_samfs(1M) man page.
14. Use the cd(1) command to change to the directory that contains the mount point. (Optional)
If you have dumped file data using qfsdump(1M) or samfsdump(1M), use the cd(1) command to change to the mount point for the new Sun StorEdge QFS shared file system. This is the location to which file data will be restored.
15. Use the qfsrestore(1M) or samfsrestore(1M) commands to restore file system data. (Optional)
If you are creating a new file system that is a Sun StorEdge QFS shared file system, you do not need to complete this step.
If you dumped existing file system data into a dump file earlier in this procedure, however, use the qfsrestore(1M) or samfsrestore(1M) commands to restore the data. For more information about restoring file systems, see the Sun QFS, Sun SAM-FS, and Sun SAM-QFS Disaster Recovery Guide.
Example 1. To restore from a Sun StorEdge QFS file system, change to the directory that contains the mount point for the file system and issue the qfsrestore(1M) command. CODE EXAMPLE 5-11 shows restoring the files from the backup file named qfs1.dump:
Example 2. To restore from a Sun SAM-QFS file system, change to the directory that contains the mount point for the file system and issue the samfsrestore(1M) command. CODE EXAMPLE 5-12 shows restoring the metadata from the backup file named samqfs1.dump into the sharefs1 Sun StorEdge QFS shared file system:
# cd /sharefs1 # samfsrestore -T -f /save/samqfs/samqfs1.dump |
|
You can configure multiple client hosts in a Sun StorEdge QFS shared file system.
1. As superuser, log in to one of the client hosts.
2. Use the format(1M) command to verify the presence of client host disks.
For more information about this step, see how the format(1M) command is used in To Configure the Shared Hosts.
3. Update the mcf file on the client host.
Any host system that wants to access or mount a shared file system must have that file system defined in its mcf file.
Use vi(1) or another editor to edit the mcf file on one of the client host systems. The mcf file must be updated on all client hosts to be included in the Sun StorEdge QFS shared file system. The file system and disk declaration information must have the same data for the Family Set name, Equipment Ordinal, and Equipment Type 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 as controller assignments can change from host to host.
The samfsconfig(1M) command generates configuration information that can help you to identify the devices included in the Sun StorEdge QFS shared file system. Enter a separate samfsconfig(1M) 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.
Example 1. CODE EXAMPLE 5-13 shows how the samfsconfig(1M) command is used to retrieve device information for family set sharefs1 on client tethys. Note that tethys is a potential metadata server, so it is connected to the same metadata disks as titan.
Edit the mcf file on client host tethys by copying the last five lines of output from the samfsconfig(1M) command into the mcf file on client host tethys. Verify the following:
CODE EXAMPLE 5-14 shows the resulting mcf file.
In CODE EXAMPLE 5-14, note that the Equipment Ordinal numbers match those of the example mcf file for metadata server titan. These Equipment Ordinal numbers must not already be in use on client host tethys or any other client host.
Example 2. CODE EXAMPLE 5-15 shows how the samfsconfig(1M) command is used to retrieve device information for family set sharefs1 on client host mimas. Note that mimas can never become a metadata server, and it is not connected to the metadata disks.
In the output from the samfsconfig(1M) command on mimas, note that Ordinal 0, which is the metadata disk, is not present. Because devices are missing, the samfsconfig(1M) command comments out the elements of the file system and omits the file system Family Set declaration line. Make the following types of edits to the mcf file:
CODE EXAMPLE 5-16 shows the resulting mcf file for mimas.
4. Issue the samd(1M) config command on the metadata server host.
This informs the sam-fsd daemon of the configuration changes. For example:
5. Create the local hosts configuration file on the client host. (Optional)
You might want to perform this step if your Sun StorEdge QFS shared file system host systems have multiple host interfaces. You can use this file to specify how file system traffic should flow over public and private networks in your environment.
Using vi(1) or another editor, create an ASCII local hosts configuration file that defines the host interfaces that the metadata server and the client hosts can use when accessing the file system. The local hosts configuration file must reside in the following location:
For fsname, specify the Family Set Name of the Sun StorEdge QFS shared file system.
Comments are permitted in the local host configuration file. Comment lines must begin with a pound character (#). Characters to the right of the pound character are ignored.
TABLE 5-3 shows the fields in the local hosts configuration file.
In a Sun StorEdge QFS shared file system, each client host obtains the list of metadata server IP addresses from the metadata server host.
The metadata server and the client hosts use both the /etc/opt/SUNWsamfs/hosts.fs_name 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 (note that client, as in network client, is used to refer to both client hosts and the metadata server host in the following process):
1. 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(1M) command from the metadata server or from a potential metadata server.
2. 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:
a. 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 in connecting.
b. If the hosts.fsname.local file exists, the client performs the following tasks:
i. It 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.
ii. It builds a list of addresses that are present in both places, and then it attempts to connect to each of these addresses, in turn, until it succeeds in connecting to the server. If the order of the addresses differs in these files, the client uses the ordering in the hosts.fsname.local file.
Example. This example expands on the example that was already begun in this chapter. For an overview of this example, see FIGURE 5-1. CODE EXAMPLE 5-7 shows the hosts file for this configuration. FIGURE 5-2 shows the interfaces to these systems.
[ D ]
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. CODE EXAMPLE 5-17 shows the information in these files.
Systems mimas and dione are not on the private network. To guarantee that they connect to titan and tethys through titan's and tethys' public interfaces, and never attempt to connect to titan's or tethys' unreachable private interfaces, the system administrator has created identical copies of /etc/opt/SUNWsamfs/hosts.sharefs1.local on mimas and dione. CODE EXAMPLE 5-18 shows the information in these files.
6. Issue the samd(1M) config command on the client host.
This informs the sam-fsd daemon of the configuration changes. For example:
7. Verify that the sam-sharefsd daemon is running for this file system.
To acomplish this, use the ps(1) and grep(1) commands as shown in CODE EXAMPLE 5-19.
# 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 |
CODE EXAMPLE 5-19 shows that the sam-sharefsd daemon is active for the sharefs1 file system. If this is the case for your system, you can proceed to the next step in this procedure. If, however, the output returned on your system does not show that the sam-sharefsd daemon is active for your Sun StorEdge QFS shared file system, perform the diagnostic procedures described in Recovering a Hung mount(1M) Command.
8. Make the mount point for the new Sun StorEdge QFS shared file system. (Optional)
If your mount point already exists, you do not need to complete this step.
If you need to create a mount point, however, use the mkdir(1) command to make the directory for the mount point. For example:
9. Issue the chmod(1M) command to give the mount point the 755 set of permissions.
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 mounting the file systems, the root directory's permissions override this setting.
10. Modify the /etc/vfstab file.
You must have an entry in the /etc/vfstab file for the Sun StorEdge QFS shared file system. Specify shared in the Mount Parameters field.
If you want the Sun StorEdge QFS shared file system to automatically mount at boot, modify the /etc/vfstab file and put yes in the mount at boot field. If you put yes, Sun Microsystems recommends also adding the bg mount option in the mount parameters field. The bg mount option mounts the file system in the background if the metadata server is not responding.
If you do not want to mount this system automatically at boot time, put no in the mount at boot field. In either case, as CODE EXAMPLE 5-20 shows, shared is a required entry in the mount parameters 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 |
11. Issue the df(1M) command on the metadata server to verify that the file system is mounted on the metadata server.
12. From the client host, issue the mount(1M) command to mount the Sun StorEdge QFS shared file system on the client host.
For failover purposes, the mount options should be the same on the metadata server and all potential metadata servers. For example, you can create a samfs.cmd(4) file containing mount options and copy it to all the hosts.
For more information about mounting Sun StorEdge QFS shared file systems, see Mount Options in a Sun StorEdge QFS Shared File System or see the mount_samfs(1M) man page.
13. Repeat the steps in this procedure for each client host.
|
If your Sun StorEdge QFS shared file system is implemented in a Sun SAM-QFS environment, the file system can access information stored on cartridges in a library. This procedure explains how to ensure that the data on these cartridges is accessible to the metadata server and the client hosts in a Sun StorEdge QFS shared file system.
If your Sun StorEdge QFS shared file system is implemented in a Sun StorEdge QFS environment, you can omit this procedure.
1. Add library and drive devices to the mcf file on the potential metadata servers. (Optional)
In a Sun SAM-QFS environment, you can configure a library and drives in the mcf file for all the potential metadata servers. If you are using disk archiving in this environment, you must configure a diskvols.conf file.
For information about configuring a library or enabling disk archiving, see the Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide.
2. Issue the samd(1M) config command on all the potential metadata servers.
This informs the sam-fsd daemon of the configuration change. For example:
When mounting or unmounting a Sun StorEdge QFS shared file system, the order in which the Solaris OS is mounted or unmounted is important.
For failover purposes, the mount options should be the same on the metadata server and all potential metadata servers. For example, you can create a samfs.cmd(4) file containing mount options and copy it to all the hosts.
For more information about mounting Sun StorEdge QFS shared file systems, see Mount Options in a Sun StorEdge QFS Shared File System or see the mount_samfs(1M) man page. For more information about mounting and unmounting file systems, see File System Operations.
|
The mount(1M) command mounts a Sun StorEdge QFS shared file system in a Solaris OS. For more information about the mount(1M) command, see the mount(1M) man page.
1. Become superuser on the metadata server and on all the client hosts.
2. Use the mount(1M) command to mount the metadata server.
Mount the file system on the metadata server prior to mounting it on any client hosts.
3. Use the mount(1M) command to mount the client hosts.
You can mount the file system on the client hosts in any order.
|
The umount(1M) command unmounts a Sun StorEdge QFS shared file system from a Solaris system. For more information about the umount(1M) command, see the umount(1M) man page.
1. Become superuser on the metadata server and on all the client hosts.
2. Use the umount(1M) command to unmount the client hosts.
The order in which the client hosts are unmounted is not important.
3. Use the umount(1M) command to unmount the metadata server.
Unmount the metadata server only after unmounting all client hosts.
Several conditions can be present in a file system at unmounting time that can interfere with the unmounting process. You might need to issue the umount(1M) command a second time. If the file system still does not unmount, use unshare(1M), fuser(1M), or other commands in conjunction with the umount(1M) command. Unmounting procedures are also described in the Sun StorEdge QFS and Sun StorEdge SAM-FS Software Installation and Configuration Guide.
The following sections describe adding and removing client host systems:
|
You can add a client host to a Sun StorEdge QFS shared file system after you have configured and mounted the file system on all participants.
1. Become superuser on the metadata server.
2. Use the samsharefs(1M) command to retrieve the current Sun StorEdge QFS shared file system information and write it to an editable file.
You can issue the samsharefs(1M) 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.
3. Use vi(1) or another editor to open the Sun StorEdge QFS shared file system information file.
CODE EXAMPLE 5-21 shows this step.
4. Use the editor to add a line for the new client host.
CODE EXAMPLE 5-22 shows the file after adding the line for helene as the last line.
5. Use the samsharefs(1M) command to update the current information in the binary file.
The options to use on this command, and the system from which it is issued, differ depending on whether or not the Sun StorEdge QFS shared file system is mounted, as follows:
The client host helene is now recognized.
6. Follow the steps described in To Configure a Client Host.
Completing the task of adding a client host to a configured and mounted Sun StorEdge QFS shared file system consists of following the steps described previously for configuring a client host.
|
1. Become superuser on the metadata server and on all the client hosts.
|
Tip - You can use the samsharefs(1M) command to verify that you are, indeed, logged into the metadata server or a client host. |
2. Use the umount(1M) command to unmount the Sun StorEdge QFS shared file system on the first client host.
Repeat this step for all client hosts that have the Sun StorEdge QFS shared file system mounted.
3. Use the umount(1M) command to unmount the Sun StorEdge QFS shared file system on the metadata server.
4. If you have not already done so, log in as superuser to the metadata server for the Sun StorEdge QFS shared file system.
5. Use the samsharefs(1M) command to obtain the current configuration information.
The following example command writes current configuration information to file /etc/opt/SUNWsamfs/hosts.sharefs1:
6. Use vi(1) or another editor to open the Sun StorEdge QFS shared file system information file.
CODE EXAMPLE 5-23 shows the file prior to deleting the client host.
7. Use the editor to delete the client host or hosts that are no longer to be supported.
CODE EXAMPLE 5-24 shows the file after the line for helene has been deleted.
8. Use the samsharefs(1M) -R -u command to update the current hosts information.
The host helene has been removed.
9. Use the samsharefs(1M) -R command to display the current configuration.
10. Use the mount(1M) command to mount the Sun StorEdge QFS shared file system on the metadata server.
For information about the mount(1M) command, see the mount_samfs(1M) man page.
11. Use the mount(1M) command to mount the Sun StorEdge QFS shared file system on the client hosts.
For information about the mount(1M) command, see the mount_samfs(1M) man page.
When you perform a manual failover, you change the metadata server. The procedures in the following sections describe how to change the metadata server in a Sun StorEdge QFS shared file system without using the automatic Membership Services feature of a software package such as Sun Cluster.
You can perform a manual failover if the metadata server goes down or becomes unavailable. Such a failover can also be performed if you want to change the metadata server or the potential metadata servers. For failover purposes, the mount options of the metadata server and all potential metadata servers should be the same.
|
Note - Contact the Sun Microsystems Professional Services Group if you need assistance in changing the metadata server in a Sun SAM-QFS environment. |
Choose from one of the following procedures depending on whether the metadata server is available at the time the failover is being performed:
|
This procedure shows how to change the metadata server of a Sun StorEdge QFS shared file system in a Sun StorEdge QFS environment when the metadata server is up.
On the metadata server, issue the samsharefs(1M) -s command to declare the new metadata server.
|
This procedure shows how to change the metadata server of a Sun StorEdge QFS shared file system in a Sun StorEdge QFS environment when the metadata server is down.
1. Ensure that the metadata server cannot restart without being rebooted.
Specifically, ensure that the server is powered down, rebooted, halted, or disconnected from the metadata disks. Your goal is to bring down the old metadata server and flush or destroy all buffers (or otherwise ensure that they cannot be rewritten).
CODE EXAMPLE 5-25 shows the key sequence to use from the kadb prompt.
kadb[1]: :c # Forces a dump kadb[1]: $q # Exits the debugger for prom |
CODE EXAMPLE 5-26 shows the key sequence to use from the PROM prompt.
{0} > sync # Forces the buffers out {0} > boot args # Discards buffers |
For args, specify arguments for the boot(1M) command, such as -r or -v. For information, see the boot(1M) man page.
2. From the new (potential) metadata server, wait for at least the period of the maximum lease time, and then issue the samsharefs(1M) command.
The wait is necessary because you must ensure that all client leases expire before the failover is performed. From the new metadata server, issue a command such as the following:
If you are uncertain as to whether or not the lease time has expired, bring up the samu(1M) N display. For information about samu(1M), see Using the samu(1M) Operator Utility. For information about leases and their durations, see Using Leases in a Sun StorEdge QFS Shared File System: the rdlease=n, wrlease=n, and aplease=n Options.
3. Unmount the file system. (Optional)
Perform this step only if you want to perform a file system check.
Use the procedure in To Unmount a Sun StorEdge QFS Shared File System.
4. Issue the samfsck(1M) command to perform a file system check. (Optional)
Perform this step only if you want to perform a file system check at this time.
If the metadata server of a Sun StorEdge QFS or Sun SAM-QFS shared file system crashes, the server should be rebooted and the file system should be unmounted on all clients before a samfsck(1M) is run. The server and clients preallocate blocks before changing the length of files. The samfsck(1M) command cleans up files that have extra blocks allocated, and these extra blocks might contain data. If such a cleaned-up file is awaiting a size update from the client, the file will be missing those blocks when the client continues. As a result, the file will be missing data, and the missed data will read as zeroes.
In a Sun StorEdge QFS shared file system, a sam-fsd daemon is always active. In addition, one sam-sharefsd daemon is active for each mount point configured in the Sun StorEdge QFS shared file system.
When a sam-fsd daemon recognizes a Sun StorEdge QFS shared file system, it starts a shared file system daemon (sam-sharefsd). TCP sockets are used to communicate between the server and client hosts. All clients that connect to the metadata server are validated against the hosts file.
One Sun StorEdge QFS shared file system daemon is started for each Sun StorEdge QFS shared file system shared mount point on each client host. This daemon establishes a connection to the metadata server. The sam-sharedfsd daemon on the metadata server opens a listener socket on the port named sam-qfs. At Sun StorEdge QFS installation time, the sam-qfs entry is added to /etc/services automatically, and this entry should not be removed. The shared file system port is defined in the /etc/inet/services file. The port number installed in the /etc/inet/services file is 7105. Verify that this port does not conflict with another service.
|
Note - In releases prior to the Sun StorEdge QFS 4.1 release, one port per file system was required. You can remove these entries from your file. |
All metadata operations, block allocation and deallocation, and record locking are performed on the metadata server. The sam-sharefsd daemon does not keep any information. Hence, it can be killed and restarted without causing any consistency problems for the file system.
The Sun StorEdge QFS shared file system can be mounted with several mount options. This chapter describes many options within the context of their roles. Other options, however, are useful only in certain situations. This section describes the mount options that can be used for special purposes.
You can specify most mount options by using the mount(1M) command, by entering them in the /etc/vfstab file, or by entering them in the samfs.cmd(4) file. For example, the following /etc/vfstab file includes mount(1M) options for a Sun StorEdge QFS shared file system:
You can change some mount options dynamically by using the samu(1M) operator utility. For more information about these options, see Using the samu(1M) Operator Utility.
The following sections summarize the mount options available to you in a Sun StorEdge QFS shared file system. For more information about any of these mount options, see the mount_samfs(1M) man page or see the cross-references mentioned in their descriptions.
The bg mount option specifies that if the first mount operation fails, subsequent attempts at mounting should occur in the background. By default, bg is not in effect, and mount attempts continue in the foreground.
The retry mount option specifies the number of times that the system should attempt to mount a file system. The default is 10000.
The shared mount option declares a file system to be a Sun StorEdge QFS shared file system. This option must be specified in the /etc/vfstab file in order for the file system to be mounted as a Sun StorEdge QFS shared file system. The presence of this option in a samfs.cmd(4) file or on the mount(1M) command does not cause an error condition, but it does not mount the file system as a Sun StorEdge QFS shared file system.
For more information about how to use this option, see To Configure the Metadata Server or see To Configure a Client Host.
The -o minallocsz=n and -o maxallocsz=n options to the mount(1M) command specify an amount of space, in kilobytes. This is the minimum block allocation size. If a file is growing, the metadata server allocates blocks when an append lease is granted. You can use the -o minallocsz=n option to specify the initial size of this allocation. The metadata server can increase the size of the block allocation depending on the application's access patterns up to, but not exceeding, the -o maxallocsz=n option's setting.
You can specify these mount(1M) options on the mount(1M) command line, in the /etc/vfstab file, or in the samfs.cmd file.
A lease grants a shared host permission to perform an operation on a file for as long as the lease is valid. The metadata server issues leases to each shared host, including itself. The leases are renewed as necessary to permit continued file operations. The possible file operations are as follows:
A shared host can continue to update leases for as long as necessary. The lease is tranparent to the end user. TABLE 5-4 shows the mount options that enable you to specify the duration of each lease type.
All three leases enable you to specify an n such that 15 
n 600. The default time for each lease is 30 seconds. A file cannot be truncated if a lease is in effect. For more information about setting these leases, see the mount_samfs(1M) man page.
If you change the metadata server because the current metadata server is down, you must add the lease time to the failover time because all leases must expire before an alternate metadata server can assume control.
Setting a short lease time causes more traffic between the client hosts and the metadata server because the lease must be renewed after it has expired.
By default, in a Sun StorEdge QFS shared file system, multiple hosts can read the same file at the same time, and if no host is writing to that file, I/O can be paged on all hosts. Only one host can append or write to a file at any one time.
The mh_write option controls write access to the same file from multiple hosts. If mh_write is specified as a mount option on the metadata server host, the Sun StorEdge QFS shared file system enables simultaneous reads and writes to the same file from multiple hosts. If mh_write is not specified on the metadata server host, only one host can write to a file at any one time.
By default, mh_write is disabled, and only one host has write access to a file at any one time. The length of that time period is determined by the duration of the wrlease mount option. If the Sun StorEdge QFS shared file system is mounted on the metadata server with the mh_write option enabled, simultaneous reads and writes to the same file can occur from multiple hosts.
TABLE 5-5 describes how file access from multiple hosts is affected depending on whether the mh_write option is enabled on the metadata server.
|
Only one append host is allowed. |
The mh_write option does not change locking behavior. File locks behave the same whether mh_write is in effect or not. The mh_write option's effect is as follows:
Sun StorEdge QFS shared file system maintains consistency between hosts. The first time that a host executes a read or write system call, it gets a lease, which allows it to read or write the file for some period of time. The existence of that lease prevents other hosts without mh_write from accessing the file. In particular, the lease can last longer than the duration of the system call that caused its acquisition.
When mh_write is not in effect, the Sun StorEdge QFS shared file system should provide near-POSIX behavior for data reads and writes. For metadata, however, access time changes might not be seen immediately on other hosts. Changes to a file are pushed to disk at the end of a write lease, and when a read lease is acquired, the system invalidates any stale cache pages so that the newly written data can be seen.
When mh_write is in effect, behavior might be less consistent. When there are simultaneous readers and writers, the Sun StorEdge QFS shared file system switches all hosts accessing the file into direct I/O mode. This means that page-aligned I/O should be visible immediately to other hosts. However, non-page-aligned I/O can result in stale data being visible, or even written to the file, because the normal lease mechanism that prevents this has been disabled.
You should specify the mh_write option only when multiple hosts need to write to the same file simultaneously and when applications perform page-aligned I/O. In other cases, there is some risk of data inconsistency because even using flock() (which works with mh_write) to coordinate between hosts does not guarantee consistency.
For more information about mh_write, see the mount_samfs(1M) man page.
The nstreams=n mount option sets the number of concurrent threads for the Sun StorEdge QFS shared file system. By default, nstreams=256. This means, for example, that under default settings, up to 256 operations can be processed simultaneously, and the 257th operation commences only after an operation has finished. You can adjust the nstreams=n mount option based on the Sun StorEdge QFS shared file system's activity. For n, specify a value such that 76 n 1024.
The meta_timeo=n mount option determines how long the system waits between checks on the metadata information. By default, the system refreshes metadata information every 15 seconds. This means, for example, that an ls(1) command entered in a Sun StorEdge QFS shared file system with several newly created files might not return information about all the files until 15 seconds had passed. For n, specify a value such that 0 n 60.
By default, data files in the Sun StorEdge QFS shared file system are allocated using the round-robin file allocation method. To specify that file data be striped across disks, you can specify the stripe mount option on the metadata host and all potential metadata hosts. Note that by default, unshared file systems allocate file data using the striped method.
In a round-robin allocation, files are created in a round-robin fashion on each slice or striped group. This causes the maximum performance for one file to be the speed of a slice or striped group. For more information about file allocation methods, see File System Design.
You can set the sync_meta=n option to sync_meta=1 or sync_meta=0.
By default, sync_meta=1 and a Sun StorEdge QFS shared file system writes file metadata to disk every time the metadata changes. This slows data performance, but it ensures data consistency. This is the setting that must be in effect if failover capability is required.
If you set sync_meta=0, the Sun StorEdge QFS shared file system writes the metadata to a buffer before writing it to disk. This delayed write delivers higher performance, but it decreases data consistency after an unscheduled machine interruption.
The behavior of the Sun StorEdge QFS shared file system is that of an interruptible hard connection. Each client tries repeatedly to communicate with the metadata server, even if the server is unavailable. If the metadata server is not responding, a user can terminate any pending, blocked I/O transmission by pressing Ctrl-C. If the I/O attempt is interrupted, the client persists until the I/O completes.
The system generates the following messages to describe status conditions:
This message is also generated if the client sam-sharefsd daemon is not active or if the server sam-sharefsd daemon is not active. When the server responds, it generates the following message:
If the file system is not mounted on the metadata server, but it is mounted on the client, the system generates the following message:
When the Sun StorEdge QFS shared file system mounts on the server, it generates the following message:
Mandatory locks are not supported. An EACCES error is returned if the mandatory lock is set. Advisory locks are supported. For more information about advisory locks, see the fcntl(2) system call.
Because the metadata server looks up file names on behalf of all clients, performance can improve if you increase the size of the Solaris directory name lookup cache (DNLC) on the metadata server. This can increase performance when clients are frequently opening a large number of files. Doubling or tripling the size of this cache from its default can be appropriate.
This procedure is documented in the Solaris Tunable Parameters Reference Manual. The parameter that controls the size of the directory name lookup cache is ncsize.
The following sections describe what to do when a sammkfs(1M) or mount(1M) command fails or when a mount(1M) command hangs.
The procedures in this section can be performed on client hosts and can also be performed on the server. Commands that can be executed only on the metadata server are preceded with a server# prompt.
If the sammkfs(1M) command returns an error or messages indicating that an unexpected set of devices are to be initialized, you need to perform this procedure. It includes steps for verifying the mcf(4) file and for propagating mcf(4) file changes to the system.
|
|
1. Use the sam-fsd(1M) command to verify the mcf(4) file.
Examine the output from the sam-fsd(1M) command and determine if there are errors that you need to fix.
2. Edit the mcf(4) file to resolve any diagnostic issues. (Optional)
Perform this step if the output from the sam-fsd(1M) command indicates that there are errors in the /etc/opt/SUNWsamfs/mcf file.
3. Issue the sam-fsd(1M) command again to verify the mcf(4) file.
Repeat Step 1, Step 2, and Step 3 of this process until the output from the sam-fsd(1M) command indicates that the mcf(4) file is correct.
4. Issue the samd(1M) config command.
This is needed to propagate mcf(4) file changes by informing the sam-fsd daemon of the configuration change.
A mount(1M) command can fail for several reasons. This section describes some actions you can take to remedy a mount problem. If the mount(1M) command hangs, rather than fails, see Recovering a Hung mount(1M) Command.
Some failed mount(1M) behaviors and their remedies are as follows:
If this procedure does not expose errors, perform To Use the samfsinfo(1M) and samsharefs(1M) Commands, which can help you verify that the file system has been created and that the shared hosts file is correctly initialized.
The following procedure shows you what to verify if the mount(1M) command fails.
1. Ensure that the mount point directory is present.
There are multiple ways to accomplish this. For example, you can issue the ls(1) command in the following format:
For mountpoint, specify the name of the Sun StorEdge QFS shared file system's mount point.
When you examine the ls(1) command's output, make sure that the output shows a directory with access mode 755. In other words, the codes should read drwxr-xr-x. CODE EXAMPLE 5-27 shows example output.
# ls -ld /sharefs1 drwxr-xr-x 2 root sys 512 Mar 19 10:46 /sharefs1 |
If the access is not at this level, enter the following chmod(1) command:
For mountpoint, specify the name of the Sun StorEdge QFS shared file system's mount point.
2. Ensure that there is an entry for the file system in the /etc/vfstab file.
CODE EXAMPLE 5-28 shows an entry for the shared file system named sharefs1.
# File /etc/vfstab # FS name FS to fsck Mnt pt FS type fsck pass Mt@boot Mt params sharefs1 - /sharefs1 samfs - yes shared,bg |
Ensure that the shared flag is present in the Mount Parameters field of the shared file system's entry in the /etc/vfstab file.
3. Ensure that the mount point directory is not shared out for NFS use.
If the mount point is shared, use the unshare(1M) command to unshare it. For example:
For mountpoint, specify the name of the Sun SAM-QFS shared file system's mount point.
This procedure shows how to analyze the output from these commands.
1. Enter the samfsinfo(1M) command on the server.
Use this command in the following format:
For filesystem, specify the name of the Sun StorEdge QFS shared file system as specified in the mcf(4) file. CODE EXAMPLE 5-29 shows the samfsinfo(1M) command and output.
The output from CODE EXAMPLE 5-29 shows a shared keyword in the following line:
Note the list of file system devices, ordinals, and equipment numbers that appear after the following line:
Make sure that these numbers correspond to the devices in the file system's mcf(4) entry.
2. Enter the samsharefs(1M) command on the server.
Use this command in the following format:
For filesystem, specify the name of the Sun StorEdge QFS shared file system as specified in the mcf(4) file. CODE EXAMPLE 5-30 shows the samsharefs(1M) command and output.
The following information pertains to the diagnostic output from the samfsinfo(1M) or samsharefs(1M) commands.
If the samfsinfo(1M) and samsharefs(1M) commands do not expose irregularities, perform To Use the samfsconfig(1M) Command.
On clients with nodev device entries in the mcf file for the file system, the entire file system might not be accessible, and the shared hosts file might not be directly accessible. You can use the samfsconfig(1M) command to determine whether the shared file system's data partitions are accessible.
Issue the samfsconfig(1M) command.
Use this command in the following format:
For list_of_devices, specify the list of devices from the file system entry in the mcf(4) file. Use a space to separate multiple devices in the list.
Example 1. CODE EXAMPLE 5-31 shows the samfsconfig(1M) command issued on a host that does not have a nodev entry in its mcf file. CODE EXAMPLE 5-31 shows the mcf file for the host tethys.
Example 2. CODE EXAMPLE 5-32 shows the samfsconfig(1M) command being used on a host that has a nodev entry in its mcf file.
For examples 1 and 2, verify that the output lists all slices from the file system, other than the metadata (mm) devices, as belonging to the file system. This is the case for example 2.
If the mount(1M) command hangs, follow the procedure in this section. You have a hung mount(1M) command if, for example, the mount(1M) command fails with a connection error or with a Server not responding message that does not resolve itself within 30 seconds.
The most typical remedy for a hung mount(1M) command is presented first. If that does not work, perform the subsequent procedures.
The netstat(1M) command verifies that the sam-sharefsd daemon's network connections are correctly configured.
1. Become superuser on the metadata server.
2. Type the samu(1M) command to invoke the samu(1M) operator utility.
3. Press P to access the Active Services display.
CODE EXAMPLE 5-33 shows a P display.
Active Services samu 4.1.1 09:02:22 Mar 22 2004 Registered services for host 'titan': sharedfs.sharefs1 1 service(s) registered. |
Examine the output. In CODE EXAMPLE 5-33, look for a line that contains sharedfs.filesystem-name. In this example, the line must contain sharedfs.sharefs1.
If no such line appears, you need to verify that both the sam-fsd and sam-sharefsd daemons have started. Perform the following steps:
a. Enable daemon tracing in the defaults.conf file.
For information about how to enable tracing, see defaults.conf(4) or see Step 2 in To Examine the sam-sharefsd Trace Log (Optional).
b. Examine your configuration files, especially /etc/opt/SUNWsamfs/mcf.
c. After you have checked your configuration files and verified that the daemons are active, begin this procedure again.
4. Enter the samsharefs(1M) command to check the hosts file.
CODE EXAMPLE 5-37 shows the samsharefs(1M) command and correct output.
In the output on your system, verify the following:
5. Enter the netstat(1M) command on the server.
CODE EXAMPLE 5-35 shows the netstat(1M) command entered on server titan.
Verify that the output from the netstat(1M) command on the server contains the following:
6. Enter the netstat(1M) command on the client.
CODE EXAMPLE 5-36 shows the netstat(1M) command entered on client dione.
Verify that the output contains the following:
If these lines are present, then the network connection is established.
If an ESTABLISHED connection is not reported, go to Step 7.
7. Perform one or more of the following procedures:
Perform these steps if using the procedure described in To Verify Network Connections did not show an ESTABLISHED connection.
1. Use the samsharefs(1M) command to verify the hosts file on the server.
You can issue the samsharefs(1M) command on alternate server hosts and client hosts that have no nodev devices listed in the host's mcf(4) entry for the file system. For this step, use this command in the following format:
For filesystem, specify the name of the Sun StorEdge QFS shared file system as specified in the mcf(4) file. CODE EXAMPLE 5-37 shows the samsharefs(1M) -R command.
If the steps in this procedure fail, you need this output for use in subsequent procedures.
3. Verify that the output matches expectations.
If the command fails, verify that the file system was created. In this case it is likely that one of the following has occurred:
4. Find the row containing the server's name in the first column.
5. From the client, use the ping(1M) command on each entry from the second column of samsharefs(1M) output to verify that the server can be reached.
Use this command in the following format:
For servername, specify the name of the server as shown in the second column of the samsharefs(1M) command's output.
CODE EXAMPLE 5-38 shows output from ping(1M).
6. From the client, examine the hosts.filesystem.local file. (Optional)
Perform this step if the ping(1M) command revealed unreachable hosts.
If there is more than one entry in the second column of samsharefs(1M) output, and if some of the entries are not reachable, ensure that only the reachable entries for the entries you want the shared file system to use are present. Also ensure that the necessary entries are present in the /etc/opt/SUNWsamfs/hosts.filesystem.local file entry on that host. Ensure that the unreachable hosts are not entered in these places.
If the sam-sharefsd daemon attempts to connect to unreachable server interfaces, there can be substantial delays in its connecting to the server after installation, rebooting, or file system host reconfiguration. This affects metadata server failover operations substantially.
CODE EXAMPLE 5-39 shows the hosts.sharefs1.local file.
7. Enable the correct server interfaces. (Optional)
If the ping(1M) command revealed that there were no reachable server interfaces, then you need to either configure or initialize the server network interfaces for typical operations, or you must use the samsharefs(1M) command to update the interface names in the hosts file so they match the actual names.
Perform these steps if the procedure in To Verify Network Connections did not show an ESTABLISHED connection.
1. Obtain samsharefs(1M) output.
This can be the output generated in To Verify that the Client Can Reach the Server (Optional), or you can generate it again using the initial steps in that procedure.
2. Find the row containing the client's name in the first column.
3. On the client, run the hostname(1M) command and ensure that the output matches the name in the first column of samsharefs(1M) output.
CODE EXAMPLE 5-40 shows the hostname(1M) command and its output.
4. Use the ping(1M) command on the server on each entry from the second column to verify that the client can be reached. (Optional)
Perform this step if the hostname(1M) command output matched the name in the second column of samsharefs(1M) output. CODE EXAMPLE 5-41 shows the ping(1M) command and its output.
It is not necessary that every entry in column two of CODE EXAMPLE 5-39 be reachable, but all interfaces that you wish any potential server to accept connections from must be present in the column. The server rejects connections from interfaces that are not declared in the shared hosts file.
5. Enable the correct client interfaces. (Optional)
If the ping(1M) command revealed that there were no reachable client interfaces, then either you need to configure or initialize the client network interfaces for typical operations, or you must use the samsharefs(1M) command to update the interface names in the hosts file so they match the actual names.
The trace log files keep information generated by the sam-sharefsd(1M) daemons during their operation. The trace log files include information about connections attempted, received, denied, refused, and so on, as well as other operations such as host file changes and metadata server changes.
Tracking problems in log files often involves reconciling the order of operations on different hosts by using the log files. If the hosts' clocks are synchronized, log file interpretation is greatly simplified. One of the steps in To Configure the Shared Hosts directs you to enable the network time daemon, xntpd(1M). This synchronizes the clocks of the metadata server and all client hosts during Sun StorEdge QFS shared file system operations.
The trace logs are particularly useful when setting up an initial configuration. The client logs show outgoing connection attempts. The corresponding messages in the server log files are some of the most useful tools for diagnosing network and configuration problems with the Sun StorEdge QFS shared file system. The log files contain diagnostic information for resolving most common problems.
The following procedures can resolve mount(1M) problems:
If none of the preceding procedures resolved the problem, perform the steps in this section. You can perform these steps on both the server and the client hosts.
1. Verify the presence of file /var/opt/SUNWsamfs/trace/sam-sharefsd.
If this file is not present, or if it shows no recent modifications, proceed to the next step.
If the file is present, use tail(1) or another command to examine the last few lines in the file. If it shows suspicious conditions, use one or more of the other procedures in this section to investigate the problem.
2. Edit file /etc/opt/SUNWsamfs/defaults.conf and add lines to enable sam-sharefsd tracing. (Optional)
Perform this step if Step 1 indicates that file /var/opt/SUNWsamfs/trace/sam-sharefsd does not exist or if the file shows no recent modifications.
a. Copy the example defaults.conf file from /opt/SUNWsamfs/examples/defaults.conf to /etc/opt/SUNWsamfs. (Optional)
Perform this step if a defaults.conf file does not reside in /etc/opt/SUNWsamfs at this time. CODE EXAMPLE 5-42 shows this.
# cd /etc/opt/SUNWsamfs # cp /opt/SUNWsamfs/examples/defaults.conf . |
b. Use vi(1) or another editor to edit file /opt/SUNWsamfs/examples/defaults.conf and add lines to enable tracing.
CODE EXAMPLE 5-43 shows the lines to add to the defaults.conf file.
trace sam-sharefsd = on sam-sharefsd.options = all endtrace |
c. Issue the samd(1M) config command to reconfigure the sam-fsd(1M) daemon and cause it to recognize the new defaults.conf(4) file.
d. Issue the sam-fsd(1M) command to check the configuration files.
CODE EXAMPLE 5-44 shows the output from the sam-fsd(1M) command.
e. Examine the log file in /var/opt/SUNWsamfs/trace/sam-sharefsd to check for errors.
3. Examine the last few dozen lines of the trace file for diagnostic information.
CODE EXAMPLE 5-45 shows a typical sam-sharefsd client log file. In this example, the server is titan, and the client is dione. This file contains normal log entries generated after a package installation, and it finishes with the daemon operating normally on a mounted file system.
| Sun StorEdge QFS and Sun StorEdge SAM-FS File System Administration Guide | 817-4091-10 |
|
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.
To Review the Configuration Requirements
