| Sun StorageTek QFS File System Configuration and Administration Guide |    
|
| Sun StorageTek QFS File System Configuration and Administration Guide |
|
| C H A P T E R 4 |
|
Configuring a Sun StorageTek QFS Shared File System |
This chapter describes how to configure and maintain a Sun StorageTek QFS shared file system. This chapter contains the following sections:
When you mount or unmount a Sun StorageTek QFS shared file system, the order in which you mount or unmount the metadata server and the clients 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 file containing mount options and copy it to all of the hosts.
For more information about mounting Sun StorageTek QFS shared file systems, see Mount Options in a Sun StorageTek QFS Shared File System and see the mount_samfs(1M) man page. For more information about mounting and unmounting file systems, see Chapter 3, Performing Operations.
|
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 before 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.
For more information about the mount(1M) command, see the mount(1M) man page.
|
1. Use the umount(1M) command to unmount the file system on every participating client host.
If necessary, use the -f option to the umount(1M) command. The -f option forces a file system to unmount.
|
Note - Forced unmount of a shared client may not complete if the file system is not mounted on the metadata server. |
2. Unmount the file system on the metadata server:
At unmounting time, several conditions can be present in a file system that may require you to issue the umount(1M) command a second time. If the file system still does not unmount, use unshare(1M), fuser(1M), or another command in conjunction with the umount(1M) command. For more information on unmounting procedures, see the umount(1M) man page and the Sun StorageTek QFS Installation and Upgrade Guide.
You can also use the -o await_clients # flag with the umount command. This causes the unmount process to wait a specified number of seconds (#) for clients to unmount. At the end of the waiting period, or as soon as all clients have unmounted, the unmount proceeds. If this argument is specified for a non-shared file system, or if the host is not the metadata server for the shared file system, the option will be ignored.
This flag can also be used in conjunction with the -f option. In this case, the software will wait for the specified time period before forcing the unmount.
To perform initial installation and configuration for a Sun StorageTek QFS shared file system, follow the instructions in the Sun StorageTek QFS Installation and Upgrade Guide. Many examples in this chapter use host names and configuration information that were introduced in that guide.
To convert an unshared Sun StorageTek QFS file system to a Sun StorageTek QFS shared file system, you must perform the conversion first on the metadata server and then on each client. This section describes these procedures.
|
You must have root permission to complete the steps in this procedure.
1. As superuser, log in to the system to be used as the primary metadata server.
2. Back up all site-customized system files and configuration files.
Depending on your software, these files might include mcf, archiver.cmd, defaults.conf, samfs.cmd, or inquiry.conf. Back up these files for all file systems. Also make sure that you have backup copies of files in the /etc/opt/SUNWsamfs directory, and files in the /var/opt/SUNWsamfs directory.
3. Ensure that each file system to be modified is backed up.
File systems should be backed up regularly according to your site's policies. 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. Use the umount(1M) command to unmount the file system.
For instructions, see Unmounting a File System.
5. Use the samfsck(1M) -S -F family-set-name command to convert the file system to a Sun StorageTek QFS shared file system.
For family-set-name, specify the family set name of the file system that you are converting to a new Sun StorageTek QFS shared file system. For example:
6. Edit the /etc/opt/SUNWsamfs/mcf file to add the shared keyword in the file system's Additional Parameters field.
7. Edit the /etc/vfstab file to add the shared keyword in the file system's Mount Parameters field.
# File /etc/vfstab # FS name FS to fsck Mnt pt FS type fsck pass Mt@boot Mt params sharefs1 - /sharefs1 samfs - no shared |
8. Create the /etc/opt/SUNWsamfs/hosts.fsname hosts configuration file.
See the Sun StorageTek QFS Installation and Upgrade Guide for more information about creating the hosts configuration file.
9. Run the samsharefs(1M) -u -R family-set-name command to initialize the file system and the host configuration.
|
Note - This command might issue an error message, which can be ignored. |
10. Run the samd(1M) config command:
This informs the sam-fsd daemon of the configuration changes.
11. Issue the mount(1M) command to mount the file system.
|
1. Use the mkdir(1) command to create the mount point for the file system.
2. (Optional) Create an /etc/opt/SUNWsamfs/hosts.file-system-name.local local hosts configuration file.
You might want to perform this step if your Sun StorageTek 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.
CODE EXAMPLE 4-4 shows a sample local hosts configuration file.
# This is file /etc/opt/SUNWsamfs/hosts.sharefs1.local # Host Name Host Interfaces # --------- --------------- titan 172.16.0.129 tethys 172.16.0.130 |
For more information on creating the local hosts file, see Creating the Local Hosts Configuration File.
3. If you want to move files from an existing Sun StorageTek QFS file system into a new Sun StorageTek QFS shared file system, ensure that each file system to be modified is backed up.
File systems should be backed up regularly according to your site's policies. 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. Use the umount(1M) command to unmount the file system.
For instructions, see Unmounting a File System.
5. Edit the /etc/vfstab file to add the shared keyword in the file system's Mount Parameters field.
# File /etc/vfstab # FS name FS to fsck Mnt pt FS type fsck pass Mt@boot Mt params sharefs1 - /sharefs1 samfs - no shared |
6. Create the /etc/opt/SUNWsamfs/hosts.fsname hosts configuration file.
CODE EXAMPLE 4-5 shows a sample.
For more information about creating the hosts configuration file, see the Sun StorageTek QFS Installation and Upgrade Guide.
To convert a Sun StorageTek QFS shared file system to an unshared Sun StorageTek QFS file system, you must perform the conversion first on each client and then on the metadata server. This section describes these procedures.
|
1. Use the umount(1M) command to unmount the file system.
For instructions, see Unmounting a File System.
2. Delete the file system's entry from the /etc/opt/SUNWsamfs/mcf file.
3. Delete the file system's entry from the /etc/vfstab file.
4. Run the samd(1M) config command:
This informs the sam-fsd daemon of the configuration changes.
5. Delete the mount point for the file system.
|
You must have root permission to complete the steps in this procedure.
1. As superuser, log in to the metadata server system.
2. Back up all site-customized system files and configuration files.
Depending on your software, these files might include mcf(4), 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 and files in the /var/opt/SUNWsamfs directory.
3. If you want to move files from an existing Sun StorageTek QFS shared file system into a new Sun StorageTek QFS file system, ensure that each file system to be modified is backed up.
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.
4. Use the umount(1M) command to unmount the file system.
For instructions, see Unmounting a File System.
5. Run the samfsck(1M) -F -U file-system-name to convert the Sun StorageTek QFS shared file system to an unshared file system.
For file-system-name, specify the name of the Sun StorageTek QFS shared file system that you are converting to a new unshared file system. For example:
6. Edit the /etc/opt/SUNWsamfs/mcf file to remove the shared keyword from the file system's Additional Parameters field.
7. Edit the /etc/vfstab file to remove the shared keyword from the file system's Mount Parameters field.
# File /etc/vfstab # FS name FS to fsck Mnt pt FS type fsck pass Mt@boot Mt params samfs1 - /samfs1 samfs - no |
8. Delete the /etc/opt/SUNWsamfs/hosts.file-system-name configuration file.
9. Run the samd(1M) config command:
This informs the sam-fsd daemon of the configuration changes.
10. Issue the mount(1M) command to mount the file system.
The following subsections provide instructions for adding and removing client host systems in a Sun StorageTek QFS shared file system:
|
You can add a client host to a Sun StorageTek QFS shared file system after you have configured and mounted the file system on all participants. If you are adding a client host that is a node in a Sun Cluster environment, you must add the node to the cluster's existing resource group. For more information, see the Sun Cluster System Administration Guide for Solaris OS.
1. Become superuser on the metadata server.
2. Use the samsharefs(1M) command to retrieve the current Sun StorageTek QFS shared file system information and write it to an editable file.
You can only issue the samsharefs(1M) command 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 StorageTek QFS shared file system information file.
CODE EXAMPLE 4-6 shows this step.
4. Use the editor to add a line for the new client host.
CODE EXAMPLE 4-7 shows the file after addition of 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 with this command, and the system from which this command is issued, depend on whether the Sun StorageTek QFS shared file system is mounted, as follows:
The client host helene is now recognized.
6. As superuser, log in to the client host to be added.
7. Use the format(1M) command to verify the presence of client host disks.
8. 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 Sun StorageTek 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, since controller assignments will probably differ from host to host.
For information on how to edit the mcf file, see Updating the mcf file in a Sun StorageTek QFS Shared Environment.
9. Issue the samd(1M) config command on the metadata server host:
This informs the sam-fsd daemon of the configuration changes.
10. (Optional) Create the local hosts configuration file on the new client host.
You might want to perform this step if your Sun StorageTek 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.
11. Issue the samd(1M) config command on the client host:
This informs the sam-fsd daemon of the configuration changes.
12. Verify that the sam-sharefsd daemon is running for this file system.
To accomplish this, use the ps(1) and grep(1) commands as shown in CODE EXAMPLE 4-8.
# 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 4-8 shows that the sam-sharefsd daemon is active for the sharefs1 file system. If the output returned on your system does not show that the sam-sharefsd daemon is active for your Sun StorageTek QFS shared file system, perform the diagnostic procedures described in Troubleshooting a Failed or Hung sammkfs(1M) or mount(1M) Command in a Shared File System.
13. If the new Sun StorageTek QFS shared file system does not already have a mount point, use the mkdir(1) command to make the directory for the mount point.
14. 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 you mount the file systems, the root directory's permissions override this setting.
15. Modify the /etc/vfstab file.
You must have an entry in the /etc/vfstab file for the Sun StorageTek QFS shared file system. Specify shared in the Mount Parameters field. In addition, do one of the following:
CODE EXAMPLE 4-9 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 |
16. Issue the df(1M) command on the metadata server to verify that the file system is mounted on the metadata server.
The file system should be included in the displayed list.
17. From the client host, issue the mount(1M) command to mount the Sun StorageTek QFS shared file system.
For more information about mounting Sun StorageTek QFS shared file systems, see Mount Options in a Sun StorageTek QFS Shared File System, or see the mount_samfs(1M) man page.
|
1. Become superuser on the metadata server and on all the client hosts.
|
Note - You can use the samsharefs(1M) command to verify that you are, indeed, logged in to the metadata server or a client host. |
2. Use the umount(1M) command to unmount the Sun StorageTek QFS shared file system on each client host on which the Sun StorageTek QFS shared file system is mounted.
3. Use the umount(1M) command to unmount the Sun StorageTek 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 StorageTek 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 StorageTek QFS shared file system information file.
CODE EXAMPLE 4-10 shows the file before the client host is deleted.
7. Use the editor to delete the client host or hosts that are no longer to be supported.
CODE EXAMPLE 4-11 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 StorageTek QFS shared file system, first on the metadata server and then on each client host in the file system.
For information about the mount(1M) command, see the mount_samfs(1M) man page.
The samfsconfig(1M) command generates configuration information that can help you to identify the devices included in the Sun StorageTek QFS shared file system. You can then use this information to update the mcf files on each client host.
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.
|
Note - If you update a metadata server's mcf file after the Sun StorageTek QFS shared file system is mounted, be sure to update the mcf files on all hosts that can access that shared file system. |
Example 1. CODE EXAMPLE 4-12 shows how the samfsconfig(1M) command is 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.
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 4-13 shows the resulting mcf file.
Example 2. CODE EXAMPLE 4-14 shows how the samfsconfig(1M) command is 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.
In the output from the samfsconfig(1M) command on mimas, note that Ordinal 0, which is the metadata disk, is not present. For devices that are missing, the samfsconfig(1M) process 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 4-15 shows the resulting mcf file for mimas.
The local hosts configuration file must reside in the following location:
Comments are permitted in the local hosts configuration file. Comment lines must begin with a pound character (#). Characters to the right of the pound character are ignored.
TABLE 4-1 shows the fields in the local hosts configuration file.
In a Sun StorageTek 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.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 (note that client, as in network client, is used to refer to both client hosts and the metadata server host):
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.
3. Depending on the outcome of the search, one of the following courses of action is taken:
a. 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.
b. 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. If the order of the addresses differs in these files, the client uses the ordering in the hosts.fsname.local file.
Example. CODE EXAMPLE 4-16 shows an example hosts file listing four hosts.
FIGURE 4-1 shows the interfaces to these systems.
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 4-17 shows the information in these files.
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. CODE EXAMPLE 4-18 shows the information in these files.
# This is file /etc/opt/SUNWsamfs/hosts.sharefs1.local # Host Name Host Interfaces # ---------- -------------- titan titan tethys tethys |
The procedures in this section describe how to change the host that is acting as the metadata server in a Sun StorageTek QFS shared file system without using the automatic Membership Services feature of a software package such as Sun Cluster software.
You can change the metadata server system manually under the following circumstances:
For a metadata server change to succeed, the mount options of the existing metadata server and all potential metadata servers must be the same.
Choose one of the following procedures depending on whether the existing metadata server is available at the time the change is being performed:
|
On the existing metadata server, issue the samsharefs(1M) -s command to declare the new metadata server.
|
Note - In Sun SAM-QFS environments, all archiving operations should be stopped on the metadata server before issuing this command. |
|
If the metadata server of a shared file system crashes, it is safe to change the metadata server only after rebooting the metadata server or otherwise ensuring that the server cannot issue any I/O before being rebooted. Do not use any of the following methods to stop the server, because these are likely to corrupt the file system:
Similarly, if the metadata server panics and drops into kernel adb(1), do not change the metadata server and then issue a :c (continue) command on the server. This action causes the old metadata server to push stale buffers out to the now-active file system.
Use the following steps to change the metadata server:
1. Ensure that the existing 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 4-19 shows the key sequence to use from the kadb prompt.
kadb[1]: sync # Forces a dump kadb[1]: $q # Exits the debugger for prom |
CODE EXAMPLE 4-20 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 more 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 ensures that all client leases expire before you issue the samsharefs(1M) command. If you are uncertain as to whether 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 StorageTek QFS Shared File System: the rdlease=n, wrlease=n, and aplease=n Options.
3. (Optional) Unmount the file system.
Perform this step only if you want to perform a file system check.
Use the procedure in To Unmount a Sun StorageTek QFS Shared File System.
4. (Optional) Issue the samfsck(1M) command to perform a file system check.
If the metadata server of a Sun StorageTek QFS shared file system crashes, the server should be rebooted and the file system should be unmounted on all clients before 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.
The procedures in this section describe how to change the host that is acting as the metadata server in a SAM-QFS shared file system without using the automatic Membership Services feature of a software package such as Sun Cluster software.
You can change the metadata server system manually under the following circumstances:
For a metadata server change to succeed, the mount options of the existing metadata server and all potential metadata servers must be the same.
|
Sun StorageTek SAM can only be running on one host at any time. This procedure assumes that both systems are up at the time of the transfer. In this example we are moving Sun StorageTek SAM archiving functions from host A to host B.
Before carrying out this procedure, verify that host B has access to the robot catalog from host A. The archiver.cmd file, mcf file, stager.cmd file, and other configuration files must be identical to those on host A.
1. Idle Sun StorageTek SAM archiving processes on host A by carrying out the following steps:
a. Run samcmd aridle and samcmd stidle to halt archiving and staging on host A.
These commands will allow current archiving and staging to complete, but will not start any new work.
b. Idle all of the tape drives on host A.
This can be done with samcmd eq idle, where eq is the equipment ordinal of the drive. This will put the drives in an "off" state after any current I/O completes.
c. When the archiver and stager are idle and the tape drives are all in the "off" state, run the samd stop command to halt all of the robot and tape-related daemons.
d. If you have a cron job that runs the recycler, remove this entry from the crontab and verify that the recycler is not currently running.
At this point, Sun StorageTek SAM has been halted and file system failover to host B can be performed.
2. Start Sun StorageTek SAM on host B by running samd config on host B.
This causes sam-fsd and its subprocesses (archiver, stager, and so on) to reconfigure and re-read the configuration files. It also causes sam-amld and the tape-library-related daemons to start. At this point all Sun StorageTek QFS shared client applications waiting for stages must reissue the stage requests.
Host B should now be fully functioning as the Sun StorageTek SAM server and metadata server for all Sun StorageTek QFS file systems.
The behavior of the Sun StorageTek 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 StorageTek QFS shared file system mounts on the server, it generates the following message:
Because the metadata server looks up file names on behalf of all clients, performance can be slow with the default size of the Solaris directory name lookup cache (DNLC) on the metadata server. To increase performance when clients are frequently opening a large number of files, you might want to double or even triple the size of this cache from its default.
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.
| Sun StorageTek QFS File System Configuration and Administration Guide | 819-7935-10 |
|
Copyright © 2007, Sun Microsystems, Inc. All Rights Reserved.
To Mount a Shared File System
