Manipulating Logical Volumes

 

 

The procedures in this section do not have Ultrix implementations.

  In addition to the procedures defined here for files and volumes, even lower-level manipulations can be performed using the LocalFile interface.

Before modifying a volume at the LocalFile level, make sure that it is dismounted. Before manipulating a file at the LocalFile level, make sure that there will be no simultaneous access to it through the OS interface.

All files created by OS have a LocalFile.FileType of 1.

   

TYPE
  VC =
    (AlreadyMountedVC, BusyVC, NotMountedVC,
     RootNotADirectoryVC, VolumeHasFilesVC);

EXCEPTION
  VolumeError (VC);

An error associated with manipulating a volume is reported by raising the exception VolumeError with an accompanying code of type VC describing the particular problem. See Appendix B.2, page , for descriptions of the individual VC values.

 

TYPE
  LogicalVolume = REF;

A value of type LogicalVolume is a reference to a logical volume. The type is implemented as a LocalFile.LogicalVolume, and the LocalFile interface must be used to perform operations on logical volumes not defined here (such as creation, deletion, and enumeration). The definition of OSFriends.LogicalVolume is opaque to avoid all clients of OS needing to be linked with an implementation of LocalFile, but a program that imports both LocalFile and OSFriends can include the definitions:

 

TYPE
  AVState = (VSReady, VSInUse, VSBadInUse, VSBad, VSScanning);

The AVState values enumerate the states that a logical volume can be in:

VSReady:

The volume is ready to be mounted; it doesn't need scavenging.

VSInUse:

The volume is mounted.

VSBadInUse:

The volume needs scavenging, but is still mounted; there may be information about the volume that has not yet been written to it.

VSBad:

The volume needs scavenging; it is not mounted.

VSScanning:

The volume is currently being scavenged.

 

TYPE
  BadReason = (ZeroLinkFiles, ActiveOps, NoRootFile, BadRootFile);

A value of type BadReason indicates why a logical volume needs to be scavenged:

ZeroLinkFiles:

The volume contains one or more files with a zero link count (that is, files for which there are no directory entries); scavenging the volume will delete these files and recover the space they occupy.

ActiveOps:

The volume went offline, or the system crashed, in the middle of an operation involving a series of writes to the volume.

NoRootFile:

The volume has no file system root file.

BadRootFile:

The volume has a file system root file, but it is not a proper directory.

 

TYPE
  VolumeInfo = RECORD
    CASE state: AVState OF

    | VSInUse:
        numActiveOps: CARDINAL;
        numZeroLinkFiles: CARDINAL;

        asPath: PathName;

    | VSBadInUse: badAsPath: PathName;

    | VSBad: reason: BadReason;

    ELSE
    END;
  END; (* VolumeInfo *)

Information pertaining to the file system's use of a logical volume is packaged as a record of type VolumeInfo.

The numActiveOps and numZeroLinkFiles fields give reference counts of in-progress operations that would require the volume to be scavenged if the system crashed or the volume went offline. The numActiveOps field currently counts directory rename operations to the volume. The numZeroLinkFiles counts files that have no more directory entries but can't be deleted until the outstanding open-file objects are closed. (See section 2.5, page .)

The asPath field gives the path name where the volume is mounted in the local file name space; the badAsPath field gives the same information for a mounted volume that needs scavenging.

The reason field tells why the volume needs scavenging.

 

PROCEDURE GetVolumeInfo(
    volume: LogicalVolume)
    : VolumeInfo
  RAISES {VolumeError};

  GetVolumeInfo returns information about the volume, including directory system information. See also LocalFile.LogicalVolumeInfo.

 

PROCEDURE Mount(
    volume: LogicalVolume;
    dir: Dir;
    path: PathName;
    force: BOOLEAN := FALSE)
  RAISES {Error, VolumeError};
  (* AlreadyMountedVC, RootNotADirectoryVC, BusyVC, ... *)

  Mount adds the specified logical volume into the local file name space by identifying the root of the volume with the specified path name. The first call to Mount after the system starts must specify a path name of / to establish the root volume of the local file system.

  If Mount is successful, it sets the state of the volume to VSInUse. If force is FALSE, the volume must initially be in the state VSReady. If force is TRUE, the volume will be mounted regardless of its state. Rather than do this you should really run a scavenger. (Currently the scavenger can only be run from the tshell.)

 

TYPE
  DismountLevel = [0 .. 2];

 

PROCEDURE Dismount(
    volume: LogicalVolume;
    force: DismountLevel := 0)
  RAISES {Error, VolumeError}; (* IOErrorEC, PvOfflineEC, BusyVC *)

Dismount removes the specified logical volume from the local file name space. All cached files on the logical volume are written out. If force is 0, Dismount raises BusyVC if there are any open files on the volume.

If force is 1, Dismount tries to close open files but raises errors such as IOErrorEC or PvOfflineEC if it has problems flushing the file data.

  If force is 2, Dismount closes open files, and ignores errors writing to the volume (however if it gets an error it does make an attempt to mark the volume as needing scavenging).

        Before calling NubMisc.Reboot or removing a physical volume, call Dismount on each mounted volume; follow that up with a call to LocalFile.FinishWrites.

 

PROCEDURE OpenFromFID(
    volume: LogicalVolume;
    block, seq: CARDINAL;
    flags: OpenMode;
    getLocks: BOOLEAN := FALSE)
  : File
  RAISES {Error, VolumeError};

OpenFromFID opens a file from its unique identifier. It uses the same rules as OS.Open except it may only be done by a super user program.

 

PROCEDURE InsertFID(
    dir: Dir;
    path: PathName;
    block, seq: CARDINAL)
  RAISES {Error}; (* NotSuperUserEC, ... *)

      InsertFID inserts the specified file identifier in the directory as given. The rules for path are the same as those for OS.HardLink (see page 4.8. The file with that id must exist and must have a valid property page. The property page of a file stores most of the attributes of the file; see the Props interface for details. InsertFID raises NotSuperUserEC unless the caller is the super-user.