hosts.fs(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).