hosts.fs - Host information for Sun QFS shared file systems
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
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
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
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
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
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
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
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.
Contains an example of a hosts.fs file.
Contain examples of hosts.fs.local(4)
samfsck(1M), samfsconfig(1M), sammkfs(1M), samsharefs(1M),