Browse Prior Art Database

Method to Manage Network Machine Start-Ups

IP.com Disclosure Number: IPCOM000034199D
Original Publication Date: 1989-Jan-01
Included in the Prior Art Database: 2005-Jan-27
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Johnson, DW: AUTHOR [+3]

Abstract

This article describes a way of attaching a node to one or more remote nodes without requiring that the nodes be powered up in any specific time sequence. The specific implementation discussed is that of the Distributed Services product which runs under the AIX* operating system for the IBM RT PC. Remote mounts are used to allow one machine to gain access to the directories of another machine. Frequently a node will need access to a fairly static set of remote directories. It is typical to put entries in /etc/rc to cause the necessary mounts to be issued at start-up time. The desired function is: 1. at start-up time all of the necessary mounts are issued 2. when a program wants to open a remote file (perhaps much later in the day), it simply issues an open with the necessary path.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 57% of the total text.

Page 1 of 2

Method to Manage Network Machine Start-Ups

This article describes a way of attaching a node to one or more remote nodes without requiring that the nodes be powered up in any specific time sequence. The specific implementation discussed is that of the Distributed Services product which runs under the AIX* operating system for the IBM RT PC. Remote mounts are used to allow one machine to gain access to the directories of another machine. Frequently a node will need access to a fairly static set of remote directories. It is typical to put entries in /etc/rc to cause the necessary mounts to be issued at start-up time. The desired function is: 1. at start-up time all of the necessary mounts are issued 2. when a program wants to open a remote file (perhaps much later in the day), it simply issues an open with the

necessary path. The mount command is issued by a system utility, not an administrator, and there may be a time gap between the issuing of a mount command and the use of the remote file. If the remote machine is not already powered up when the local machine starts up; the following occurs. 1. The local machine starts up; the remote machine is off. 2. /etc/rc issues the remote mounts, which fail. 3. The remote machine powers up. 4. A user tries (perhaps much later in the day) to access a remote file. 5. The open fails; since the remote machine is up (and has been up for a while), the user does not immediately

understand why the open failed. 6. The remote mounts will have to be issued again, probably by someone with system group authority. This implicit requirement on the time sequence of machine start ups in the network is an unacceptable restriction on usability. Distributed services of the AIX operating system contains some features which allow the system administrator to use other system features (namely cron(1) and at (1)) to solve this start-up problem. These features are described below: 1. When the mount(1) command is issued with the "all"

argument, it returns an exit code of 0 if all of

the mounts in /etc/filesystems with mount=true

have been successfully issued, non-zero if they

have not. (Mount(1) uses mntctl(2) to see what

mounts are already in place and reissues vmount(2)

calls only for those which are required by

/etc/filesystems and which are not already in

place.)

2. A new attribute is added to /etc/filesystems and a

new flag is added to mount(1). The attribute is

"type" which is expected to have filename syntax,

and can be assigned any value. For example:

type = important_mnts

type = dept_A

type = low_priority The new mount(1) flag is the "-t" flag. Mount -t "string" causes /etc/filesystems to be searched for a

1

Page 2 of 2

stanza whose...