hosts.fs - Host information for StorageTek QFS shared file systems
∕etc∕opt∕SUNWsamfs∕hosts.fs
SUNWqfs
SUNWsamfs
The ∕etc∕opt∕SUNWsamfs∕hosts.fs file specifies the hosts
and network interfaces used by a StorageTek QFS shared file system.
The fs suffix must be the family set name of the
StorageTek 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 StorageTek 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:
The identity of the file system's metadata server.
The host systems (and host IP interfaces) that are allowed to connect to the StorageTek QFS shared file system's metadata server.
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 1: host name
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.
Field 2: 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.
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.
Field 3: host server priority
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.Field 4: stager priority
This numeric field is not used by the shared file system software. It is recommended that this field be set to zero.Field 5: server
This optional field must be set for one of the hosts in thehosts.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.
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.
∕opt∕SUNWsamfs∕examples∕hosts.shsam1Contains an example of a hosts.fs file.
∕opt∕SUNWsamfs∕examples∕hosts.shsam1.local.server | ∕opt∕SUNWsamfs∕examples∕hosts.shsam1.local.clientContain examples of hosts.fs.local (4) files.
hostname (1).
samfsck (1m),
samfsconfig (1m),
sammkfs (1m),
samsharefs (1m),
sam-sharefsd (1m).
