B Theory of Operation





This appendix reviews operational theory of the Sun Prestoserve product. This information serves as background material to increase your understanding of the system administration issues discussed in Chapter 4, "Normal Operation" and Chapter 5, "Abnormal Operations."

B.1 Introduction

Sun Prestoserve is implemented as a UNIX device driver, using non-volatile memory to cache synchronous write requests. As the cache fills, older data is written asynchronously to the real disk. Sun Prestoserve works as a layer between other disk drivers and the rest of the UNIX kernel. Stubs replace the original driver's entry points in the device switch tables. Whenever Sun Prestoserve needs to perform actual I/O (for example, when its cache needs to be drained), it uses the real device driver routines. Normally, the real device routines can directly access the data cached in Sun Prestoserve's non-volatile memory.

Sun Prestoserve requires minimal day-to-day administration. However, the system administrator should be familiar with how the presto command works. This command is described in both Chapter 2, "Installing the Prestoserve SunOS 4.x Software", Chapter 3, "Installing the Prestoserve Solaris 2.x Software", and Chapter 4, "Normal Operation."

In normal use, intervention is only required when a new filesystem is mounted and you want to accelerate this filesystem with Sun Prestoserve. In this case, it is necessary to use the presto command, according this syntax.

# presto -u filesystem

The presto command accelerates this filesystem. If you encounter error conditions, refer to Chapter 5 to determine the problem.

B.2 Sun Prestoserve Buffer Management

Buffers in the Sun Prestoserve non-volatile cache undergo several state transitions. A dirty buffer is one that contains a disk block image that has not been flushed to disk. A clean buffer contains a valid disk block image that has been flushed to disk. An invalid buffer does not presently contain a disk block image. An active buffer is one that is currently in transition to the actual disk, for example a write operation has started, but has not been completed on that buffer. The buffer state transition diagram is as follows:

    invalid Æ dirty Æ active Æ clean Æ dirty

B.3 Sun Prestoserve States

The Prestoserve hardware should be thought of as a disk since it can contain data that is not yet written to disk. The Prestoserve driver goes to great lengths to ensure that this data is never lost. In an error condition, the driver never discards data unless explicitly requested to do so by the super user.

Prestoserve is always in one of these three states:

The goal at boot time is to successfully flush any dirty Sun Prestoserve buffers and end in the DOWN state. If there are dirty buffers in the Sun Prestoserve cache, they are flushed, and Sun Prestoserve remains in the DOWN state unless an error occurs during flushing. In this case, Sun Prestoserve enters the ERROR state. When in the ERROR state, the cache is effectively read-only until the error condition is cleared. Then, Sun Prestoserve re-enters the DOWN state.

After boot time, Sun Prestoserve is automatically enabled by the presto -u command, which is inserted by the installation script. This command, which may also be executed manually by the superuser, brings Sun Prestoserve into the UP state. The command presto -d brings Sun Prestoserve back into the DOWN state, but only if the Sun Prestoserve cache can be successfully flushed. If Sun Prestoserve cannot be successfully flushed, it enters the ERROR state. Thus, whenever Sun Prestoserve makes a state transition from UP to DOWN, all Sun Prestoserve buffers are successfully flushed and invalidated.

Sun Prestoserve can be brought to the DOWN state from the UP state in several ways. In addition to presto -d, those commands which use the reboot system call cause Sun Prestoserve to enter the DOWN state if all dirty buffers are successfully flushed. If not, Sun Prestoserve enters the ERROR state. See the Preface, "When You Need Help with UNIX Commands," for references to documentation about the reboot system call.