Skip Navigation Links | |
Exit Print View | |
Sun QFS and Sun Storage Archive Manager 5.3 Reference Manual Sun QFS and Sun Storage Archive Manager 5.3 Information Library |
1. User Commands (Man Pages Section 1)
2. Maintenance Commands (Man Pages Section 1M)
3. Library Functions (Man Pages Section 3)
4. Library Functions (Man Pages Section 3X)
5. File Formats (Man Pages Section 4)
NAME hosts.fs - Host information for Sun QFS shared file systems SYNOPSIS /etc/opt/SUNWsamfs/hosts.fs AVAILABILITY SUNWqfs SUNWsamfs DESCRIPTION The /etc/opt/SUNWsamfs/hosts.fs file specifies the hosts and network interfaces used by a Sun QFS shared file system. The fs suffix must be the family set name of the Sun QFS shared file system as specified in the mcf(4) file. The file /etc/opt/SUNWsamfs/hosts.fs is required by sammkfs(1M) at the time a Sun QFS shared file system is created. The sammkfs(1M) command reads /etc/opt/SUNWsamfs/hosts.fs and integrates the information into the file system when initializing the file system. The file system's shared hosts information can be subsequently modified using the samsharefs(1M) command. Another file, hosts.fs.local(4), can also reside on each host system included in the shared file system. Daemons local to each host system use the shared hosts file and the local hosts file, if any, to initialize network connections for the shared file system. Each file system's shared hosts file determines the host configuration for that file system. This includes the following: o The identity of the file system's metadata server. o The host systems (and host IP interfaces) that are allowed to connect to the Sun QFS shared file system's metadata server. o The identities of the potential metadata server hosts. These are systems that can act as the file system's metadata server if the preferred metadata server is unavailable. The hosts.fs file is comprised of lines containing five fields of information. Each line corresponds to one host that is permitted to access the file system. The fields are as follows: Field Number Content 1 The name of the host. The host name field contains the name of a host that is to be permitted access to the shared file system. The value of this field must match the output of the hostname(1) command on that host. 2 The host IP addresses. The host IP address field contains a list of one or more host IP interface addresses or names that the metadata server must be able to resolve to IP addresses. If there are multiple IP interfaces that a host can use to connect to a server, they must be separated by commas. You should avoid using a domain name in this field, because during the reboot process, when sam-fsd is trying to contact the metadata server, naming services are likely not up. This means that the name may not be resolvable if it is not in the /etc/inet/ipnodes or /etc/inet/hosts file; this will cause the mount to fail and could cause the reboot to hang. 3 The server priority of the host. The server priority field is a numeric field. If the field is zero, the host cannot act as the metadata server for the file system. If the field is nonzero, the host can act as the metadata server for the file system. 4 A number that indicates the stager priority. This numeric field is not used by the shared file system software. It is recommended that this field be set to zero. 5 A server field. This optional field must be set for one of the hosts in the hosts.fs file. That host must have a nonzero server priority field. If present, this field must contain the string server. In this file, a pound character (#) indicates a comment. Comments continue from the pound character to the end of the line. All characters to the right of the pound character are ignored. After the file system is initialized using the sammkfs(1M) command, only the metadata server host is permitted to run the samfsck(1M) to repair the file system. The server on which sammkfs(1M) is run is typically declared to be the metadata server. When a client is attempting to connect to the metadata server, the client obtains the list of names and addresses from the second field, which is the host IP address field, of the server's row in the hosts.fs file. It attempts to connect to these names, in the order in which they appear, until it connects successfully. If the client has a local hosts.fs.local(4) file, only the names or addresses that are present in both files are used. The hosts.fs.local(4) file determines the order in which host connections are attempted. When a metadata server receives a connect attempt, it performs address lookups on the values from the second column of the hosts.fs file until it finds one that matches the IP address of the incoming connection. If it fails to find one, it refuses the connection. For file systems that are mounted at boot time, you should add the file system's hosts to the /etc/inet/hosts or /etc/inet/ipnodes files. On clients, the names of the servers should be added; on servers, all of the file system's hosts should be added. EXAMPLES Example 1. The following is a sample hosts.fs configuration file called /etc/opt/SUNWsamfs/hosts.shsam1. # # shsam1 config, titan/tethys servers, mimas/dione clients # # This file goes in titan:/etc/opt/SUNWsamfs/hosts.shsam1, # and is used by 'sammkfs -S shsam1' to initialize the FS # meta data. Subsequent changes to the configuration are # made using samsharefs(1M). # # titan titan 1 0 server tethys tethys 2 0 mimas mimas 0 0 dione dione 0 0 Example 2. This hosts configuration file is more complicated that the one in example 1. It supports a configuration where two potential servers also have a private interconnect between them. # # shsam1 config, titan/tethys servers, mimas/dione clients # # This file goes in titan:/etc/opt/SUNWsamfs/hosts.shsam1, and # is used by mkfs -S to initialize the FS meta data. Subsequent # changes to the configuration are made using samsharefs(1M). # # titan titan-ge,titan.xyzco.com 1 0 server tethys tethys-ge,tethys.xyzco.com 2 0 mimas mimas.xyzco.com 0 0 dione dione.xyzco.com 0 0 To ensure that titan and tethys always connect to each other through their private interfaces, titan-ge and tethys-ge, each must have a hosts.shsam1.local file (see hosts.fs.local(4)). To avoid the inefficiencies of attempting to connect to the unreachable titan-ge and tethys-ge interfaces, mimas and dione should also have their own hosts.shsam1.local files. FILES /opt/SUNWsamfs/examples/hosts.shsam1 Contains an example of a hosts.fs file. /opt/SUNWsamfs/examples/hosts.shsam1.local.server /opt/SUNWsamfs/examples/hosts.shsam1.local.client Contain examples of hosts.fs.local(4) files. SEE ALSO hostname(1). samfsck(1M), samfsconfig(1M), sammkfs(1M), samsharefs(1M), sam-sharefsd(1M). hosts.fs.local(4), mcf(4).