Multics Storage System

How Multics Programs Access Data Files

This page begins a description of selected components and operations of the Multics Storage System. It was originally written to help users of the analyze_multics subsystem understand Storage System components, the azm commands that display storage-related data structures, and relationships between these data structures.

This information has been adapted to provide a more general introduction to the Multics Storage System for a reader familiar with Multics programs written in the Multics PL/I programming language. But it still includes examples displaying structure content using analyze_multics subsystem requests.

The Storage System is composed of four major subsystems: Segment Control, Page Control, Directory Control and Device Control (the Disk Device Interface Module). Terminology, operations, and significant data structures of these subsystems are introduced in each page of the description.

Each page begins with name(s) of the major subsystem being described, followed by a list of significant operations and/or main data structures referenced on that page. For example:

  SUBSYSTEMS:  Directory Control, Device Control (Disk DIM)

  Multics Storage System -- items include
     Segments
     Tree-structured Data Base -- composed of
        Directory Segments -- each tree node containing
           Directory header
           Directory entries -- each describing a segment in the tree.

This is followed by titled sections describing a subsystem operation, its main data structures, etc. These section titles are listed at the top of each page, for ease of reference.

Purpose of the Storage System

The Multics Storage System, and its Segment Control, Page Control,
Directory Control, and Disk Device Interface Module (Disk DIM) subsystems
manage the services which:
 - store data (permanently or temporarily) in segments; and
 - allow a user program to directly access contents of non-directory
   segments.


A variety of data structures participate in providing these services.
The azm page_control_check (pcc) request reports inconsistencies in
the relationships between the Segment Control and Page Control data
structures.

A user trying to interpret pcc output needs to understand how the
memory workspace of a process is tied to segments in the Multics
Storage System; and how Segment Control, Page Control, and Disk DIM
cooperate to load a page from disk into hardware memory when the
corresponding page of a segment is referenced: a service called
"Demand Paging".


The next few sections introduce the Multics Storage System as viewed by
the pcc request.  The checking and inconsistency reports produced in
output from the pcc request stem from this specialized viewpoint.

Multics Storage Items

The basic unit of storage in the Multics Storage System is the segment.
Segments form a tree-structured data base that is organized by a
hierarchy of directories.

The azm page_control_check (pcc) request views each "segment" as an
individual memory region directly accessible to a program running in a
process.


Each segment holds a different type of data.  Data types include:
 - an executing user program;
 - a stack containing subroutine call history and automatic variables
   used by each called subroutine in a particular ring-of-execution;
 - program input or output data;
 - library subroutines;
 - a gate to supervisor subroutines in an inner ring;
 - the actual supervisor subroutines;
 - supervisor data;
 - a directory which catalogs attributes of other segments and their
   location within the tree-structured directory hierarchy.

For details about the Storage System, refer to the Multics Programmer's Reference Manual (order AG91-04). Section 2 introduces the Storage System segments and directories, and describes using an absolute pathname to identify segments, directories and links.

Storage System Terms

A "directory segment" is a special type of segment accessible only by
programs executing in ring-0.  It contains:
  - a header (>ldd>incl>dir_header.incl.pl1) describing location of
    the directory within the tree, and various attributes of the
    directory segment;
  - a list of "directory entries" (>ldd>incl>dir_entry.incl.pl1).
    Each describes attributes of a tree item located just below the
    containing directory's position within the hierarchy.  Each tree
    item is either:
     - a "non-directory segment": a leaf of the tree holding data;
     - a "child directory": a directory describing tree elements at an
       immediately inferior level of the tree; or
     - a "link": a character-string pathname locating another item of
       the tree.


The term "segment" usually refers only to a non-directory segment; but
in some contexts, it may include both non-directory and directory
segments.

The term "directory" refers only to a "directory segment".  Actual
contents of a directory may be referenced or changed only by programs
of the Directory Control subsystem which execute in the ring-0
supervisor.


Any segment or directory can be located by one of the "names" attached
to its entry.  The entry is stored within the directory immediately
superior to the segment in the Storage System hierarchy: its "parent
directory".  That directory is located in the same manner by a name on
its entry in a superior directory and so on, up to the "root" or
top-most directory of the inverted tree.

The concatenation of all these names (separated by ">" symbols) forms
an "absolute pathname" that identifies a specific "item" (non-directory
segment, directory segment, or link) within the Storage System
hierarchy.

The inverted tree structure of directories and files is illustrated in the AG91-04A, Figure 2-1. This illustration shows two non-directory segments (the oval items) having the following path names:

    >udd>Project_id>Person_id>episilon

    >udd>Others>Jones>chess

Directory Control Operations

Programs executing outside of ring-0 may call Directory Control
services (subroutines) to:
 - use an "absolute pathname" to identify a particular item in the
   Storage System hierarchy.
 - list items (entries) in a particular directory.
 - create, delete, or rename a specific item in a directory.
 - get or set other attributes of an entry (access, length, etc.).

Segment Control Operations

Segment Control provides additional services for non-directory segments
including:
 - "initiating a segment": making it known as a segment in the virtual
   memory workspace of a process so contents of the segment can be
   referenced or changed by instructions of a user program executing in
   that process.
 - truncating, setting bit-count and maximum length (in words) of the
   segment.
 - "terminating the segment": removing knowledge of that segment from
   the process workspace.

Storage System Topics in this Description

The following topics are included in this brief introduction to the Multics Storage System. The first two topics tell how the workspace of a Multics user process is structured, and how Multics data is stored on disk. The next three topics describe operations performed by a user program to load data into a process, and access that data from a user program.

 Process Virtual Memory                      (virtual_segment.gi.info)
 Permanent Storage on Disk for a Segment       ( disk_segment.gi.info)

 Connect a Segment to a Process
  A) Make Segment Known to the Process          (initiate_seg.gi.info)
      - Find segment information using the
        directory hierarchy.
      - Verify process has some access rights to segment.
      - If segment is on a private LV: verify LV is mounted and
        attached by the user process.
      - Get KSTE and SDW for segment.
         - Re-use existing KSTE/SDW if segment already in-use by
           process, or has been used earlier in the login session.
            - Extend seg access (if ACL/RBs now grant write access).
        OR
         - Describe Segment to Hardware and Supervisor
            - Fill-in faulted Segment Descriptor Word (SDW)
            - Fill-in Known Segment Table Entry (KSTE)

  B) Segment Fault When Accessed by the Process    (seg_fault.gi.info)
      - Find segment in, or add a segment to, the
        List of Active Segments in-use by the system.
      - Fill-in process access rights in SDW and KSTE.
         - If process rights change encacheability of the segment,
           change encacheability setting in SDWs of ALL referencing
           processes.
      - Add SDW Trailer Record (STR) to ASTE tracking this process as
        referencing the active segment.

 Demand Paging                                 (demand_paging.gi.info)
 Consistency Checks by page_control_check         (pcc_checks.gi.info)
 Hardcore Segment Varieties                    (hardcore_segs.gi.info)

Click on any of the links above to jump to description of a particular topic. To continue reading the full description, select: virtual_segment.gi.info

Files versus Segments

For some observations of ‘’files’’ and ‘’segments’’ see Files Versus Segments.