Tape Control UNIX Backup and Restore

12.6 Tape Control

Assuming the use of the regular not−Berkeley style no rewind device file, proper forward and backward moving of a tape still seems a little confusing. To understand this better, we should also recall that there are two types of mt device files: Berkeley and regular non−Berkeley, also known as ATT style, and they behave differently. This means that the same set of tape−related commands would handle a tape differently depending on the type of the tape device file selected. The trailing letter b in the device filename identifies Berkeley−style devices, so it is very easy to distinguish between the two types of tape devices. The system works in the following way assuming non−Berkeley style devices: At the end of a recording on a tape performed by dump, tar, or other an EOF pointer is automatically appended after the backup record. • Any movement of the tape is referenced by those EOF pointers. • A tape always stops at the first block that follows a designated EOF pointer a tape forwards just after the closest EOF pointer, whatever the direction of the previous tape movement was. • The mt command, which is used to move a tape, refers to a number of EOF pointers, determined by its count option, to be skipped in any direction every EOF pointer on the way is counted. • That is why the command: mt −f devrmt0n bsf 1 does not change a tapes position. The graphical presentation in Figure 12.1 should contribute to a better understanding of this issue. 298 Figure 12.1: Tape control — regular ATT−style tape device. The Berkeley−style tape devices behave differently in that during tape movement, the tape remains in its actual position without forwarding to the closest EOF pointer. This small difference requires modified control of the tape during the restore procedure. This is presented in Figure 12.2. 299 Figure 12.2: Tape control — Berkeley−style tape device. 300

Chapter 13: Time−Related UNIX Facilities

13.1 Network Time Distribution

UNIX supports the distribution of an accurate time throughout the network. This means that each host in the overall network is synchronized to a selected timeserver, or servers, which transmit a reference clock time to the time client hosts. A reference clock will generally though not always be a radio time code receiver that is synchronized to a source of standard time such as NIST in the U.S., or NRC in Canada. The time distribution is based on the network time protocol NTP, currently version 4 which is fully compliant with version 3 standard, defined by Request for Comments RFC 1305, and compatible with previous versions 2 and 1, defined by RFC 1119 and RFC 1059. The computation done in the protocol is fully provided in fixed−point arithmetic, and together with the clock adjustment code, brings a high precision that maintains accuracy comparable with even the most precise external time sources.

13.1.1 The NTP Daemon

A special NTP daemon, named xntpd, is responsible for maintaining a UNIX systems time−of−day; it is also known as the time server. The time server provides the time service, or acts as a time client. We will use the term the xntpd daemon or the NTP daemon, just to avoid any possible confusion. The xntpd daemon works in compliance with Internet standard time servers; it follows the distributed reference time. The xntpd daemon exits collapses if the difference in the system time and the reference time is more than 1000 sec; otherwise, it slowly brings the system time in line with the distributed reference time. The NTP daemon reads its configuration file etcntp.conf or etcinetntp.conf, as on Solaris 2.x at the startup time, and learns its duties. If any configuration change has been made, the daemon must be restarted. The daemon can be configured to act strictly as a time client by specifying appropriate configuration entries, which means it will only synchronize its own systems time, or it will act as a potential time server. The term potential is used to emphasize the fact that even when the local xntpd daemon is willing and ready to transfer the reference time over the network, the NTP daemons running on other hosts decide if they will use the offered service. This concept will be clearer once we explain basic configuration entries. The xntpd daemon is not mandatory on every system. It is easy to determine if it is running on your system by executing the command as in this example, from HP−UX 10.20: ps −ef | grep ntp | grep −v grep root 1284 1 0 Feb 25 ? 5:27 usrsbinxntpd Or, on Solaris 2.x: ps −ef | grep ntp | grep −v grep root 956 1 0 Mar 08 ? 0:03 usrlibinetxntpd The NTP daemon is started only if the configuration file is set appropriately. Here is the partial rc startup sequence on Solaris 2.6 from the etcinit.dxntpd rc script: start Only start if there is a config file if [ −r etcinetntp.conf ] ; then ARGS= cat etcinetntp.conf | usrbinnawk ….. ..... 301