Quantum 3.5 manual Overview, Active vs. Passive Supported Platforms

Appendix D Quality of Service Guide Overview

Overview

Active vs. Passive

Supported Platforms

QOS is stripe-group centric; all configuration and operations act on a specific stripe group. This allows stripe groups with differing access characteristics to use different real-time settings. When a client requests a certain amount of real-time I/O, the FSM informs all connected clients of the amount remaining and available for non-real-time I/O accesses.

This information is encapsulated in a token. Think of the token as a capability that enables the client to perform I/O without contacting the FSM. When the amount of real-time I/O on a stripe group changes, the FSM informs all connected clients about the change via a callback.

In both the client and the server, QOS is implemented as a state machine. Each state has a set of events and allowable actions. In this document, the term state thusly refers to the internal state machine.

QOS is a passive, not active implementation of real-time I/O. In an active implementation (such as the SGI IRIX guaranteed rate I/O known as GRIO), the scheduler is tightly coupled with the I/O subsystem. The qualities of the disk subsystem are well known so the scheduler can guarantee that a process will be scheduled such that it will receive the required amount of bandwidth. Since SNFS is a cross-platform file system that does not have hooks in the operating system scheduler, it cannot provide such a guarantee.

In a passive implementation, a real-time process gates its I/O according to some outside metric (such as a frame rate for specific video formats). The file system then gates all other non-real-time I/O so they do not interfere.

These differences cannot be over-stressed. It is a misconception to think that QOS, despite its name, guarantees a specific amount of real-time I/O to a process.

QOS has been tested on Windows XP, Linux, IRIX, and Solaris. In the Windows world, an application gets a handle to a file to perform I/O, usually via the Win32 CreateFile() API. In the UNIX world, an application receives a file descriptor (fd) via the open(2) system call. In this document, “handle” is synonymous with fd.

StorNext 3.5 Installation Guide 143