The Alpine Project

Status Report

October 14, 1981

Mark Brown, Karen Kolling, Ed Taft



1. Why a(nother) new file server?

2. What Alpine does

3. What Alpine doesn’t do

4. Example of use

5. Internal organization

6. Status and plans



1. Why a(nother) new file server?

Changing style of usage

Universal file system

Data base systems

IFS limitations

Per-connection cost too high

Inadequate performance

Doesn’t support unique IDs

Oriented toward sequential transfer of entire files (Leaf server is an add-on)

No transactions

Juniper limitations

Inadequate performance

Poor support for sequential transfers

Functionality imperfectly matched to needs of data bases

Parts of implementation poorly understood

Converting to Pilot is impractical



2. What Alpine does

Files

Identified by unique IDs

Page-level read/write

File properties

Transactions

Can span multiple servers

Can have multiple clients

Locking, concurrency control

Physical locking at file and page level

Read, write, update locks

Lock interface supports logical locking

Access control, space accounting

Depends heavily on Grapevine facilities

Support for higher-level servers on Alpine server machine

Lock and Log interfaces available to local clients

Workstation file system

Good performance

Both random and sequential access

Efficient, low-cost connections (RPC)

Optimized special cases (single-machine transactions, read-only transactions, whole-file locks, deferred updates, no unnecessary logging)

Reliability

Crash recovery

Media failure recovery (optional)

Fast restart after most crashes



3. What Alpine doesn’t do

File location

Directories (text names)

FTP access

Guaranteed real-time response



4. Example of use

Bind, establish conversation

CedarRPC.Import[
proc: AlpineFileRpcControl.ImportInterface,
interface: [type: "AlpineFile", instance: "MontBlanc.Alpine"]];

CedarRPC.Import[
proc: AlpineTransactionRpcControl.ImportInterface,
interface: [type: "AlpineTransaction", instance: "MontBlanc.Alpine"]];

c: ConversationID ← CedarRPC.StartConversation[
caller: "Taft.PA", callerKey: [...], callee: "MontBlanc.Alpine"];

Begin transaction

t: TransID ← AlpineTransaction.Create[conversation: c];

Open file

f: OpenFileHandle ← AlpineFile.Open[
conversation: c, trans: t, volume: [...], file: [...],
access: readWrite, lock: [intendUpdate, wait],recoveryOption: log];

Read/write pages

AlpineFile.ReadPages[
conversation: c, handle: f, pageRun: [0, 10], pageBuffer: p,
lock: [read, wait]];

AlpineFile.WritePages[
conversation: c, handle: f, pageRun: [0, 10], pageBuffer: p,
lock: [update, wait]];

End transaction

outcome: Outcome ← AlpineTransaction.Finish[
conversation: c, trans: t, requestedOutcome: commit];



5. Internal organization

Based on Pilot

Initial implementation uses public interfaces only

Later may use internal interfaces for performance reasons

Substantial caching for good performance

Cache file pages in VM

Numerous internal maps for volatile data structures



6. Status and plans

Public interfaces are specified

Internal interfaces are mostly specified

Implementation has begun

Access control

Transactions

Basic mechanisms working 1Q82

Remote access, files, transactions

Usable for experimental applications (e.g., Cedar data base)

Generally usable system 3Q82

At least one full-time server (Dorado)

Backup, full failure recovery

Longer-range possibilities

Archiving

Client caching

Other servers in Alpine server machine (data base, directory, FTP, ...)



Where to learn more about Alpine

Alpine file server overview

[Indigo]<Alpine>Doc>
AlpineOverview.press

—the basis for this talk (essentially)

FileStore public interfaces

[Indigo]<Alpine>Doc>
FileStore8.press

—describes Mesa interfaces exported to remote clients

Internal working documents

[Indigo]<Alpine>Doc>*.bravo

[Indigo]<Alpine>Doc>
AlpineFileStore2.press