Heading:qjk40(635)
A list of FileStore design decisionsy756qjk40
Page Numbers: Yes  X: 527  Y: 10.5"qjk40
Inter-Office Memorandumz18592l4445y762\f5b
To	Alpine interest	Date	July 1, 1981z18592l4445d2998e21(0,65535)(1,4445)(5,11684)(6,14146)\f1 2f0t2 1t0 15t6 1f1t0 4f0t7 1t0
From	Mark Brown	Location	Palo Altoz18592l4445d2998y716e25\f1 4f0t2 1t0 10t6 1f1t0 8f0t7 1t0
Subject	A list of FileStore design decisions	Organization	CSLz18592l4445d2998e25\f1 7f0t2 1t0 36t6 1f1t0 12f0t7 1t0
XEROX       z18592l508y644e14(2116)\f2 5f0
Filed on: <Alpine>Doc>DesignDecisions.bravoe30
e10
Design decisions taken in small-group meetings (attended by Mark Brown, Karen Kolling, and Ed Taft) since last large-group meeting (early May):e12jk40
1) read/write FileStore interface.  Rationale: read/write is simpler; encryption/decryption of data can be performed on top of read/write; implementation of VM-like interface is simpler if both local and remote access is read/write.  Mapped might be preferable if we could integrate remote file access at very low level (as SDD wants to do.) e12jk40
2) data transfers are runs of pages.  Rationale: Pilot disk pages are tiny; clients will want the effect of larger page sizes.e12jk40
3) no scatter-gather for multi-page transfers.  Rationale: normal clients do not require it; RPC implementation can cope.e12jk40
4) no byte-range transfers.  Rationale: requires additional complexity in lock manager and log map; most clients want to write pages or logical units.  (Second thought: byte range transfers without locking may be useful, e.g. in implementing leader page manipulations, very simple databases such as the space allocation database. Clients must use their own locking conventions to ensure consistency of byte-range writes, or else we could adopt the solution of locking the entire page to write any byte of the page.)e12jk40\152i363I
5) require an explicit call to open a file before use.  Rationale: authentication and transactions are separate.  It is tiresome to pass authentication information over wire on each page access.  File open call returns a hard-to-forge ID for the association of <client, file, transaction>.e12jk40
6) perform authentication at the time of interface creation.  Interface can "self-destruct" if it decides that the client should not use the FileStore.  All calls through the interface have implicit access to the (authenticated) identity of the client.  Rationale: a secure connection already requires authentication activity at creation time (?).e12jk40
7) files have owners.  Rationale: directory system is separate from file system, need some way of accounting for disk space at file server level.  (Note owner # creator, in general, and that all copies of an immutable file need not have the same owner.)e12jk40
8) all calls that change space allocation (create/destroy file, set file length) must be performed under a transaction.  Rationale: implementaiton is simpler if an update to the server's space allocation database is coordinated with transaction commitment.e12jk40
9) use leader page for some file properties, to get efficiency and robustness.  As much as possible, make the interface to file properties independent of whether a property is stored in a leader page.  Candidates for not living on leader page: read date, archiving and backup information.  (Interface to file properties has not really been worked out yet.  Note that if file owner is stored in leader page, then different copies of an immutable file may have different leader pages.)e12jk40\217i4I69i193I
10) all clients of the log interface must be local.  Rationale: writers of log records must be available during recovery.  It is an unacceptable compromise of site autonomy to make site recovery dependent upon code that runs remotely.e12jk40
11) implementation of FileStore includes a simple file system, FilePageMgr, with no transactions or access control.  FilePageMgr can be implemented (for the most part) using public Pilot interfaces.  Rationale: avoid direct dependence on Pilot, use as much of Pilot as possible, allow possibility of accessing Pilot at lower level if necessary for performance.e12jk40
Open areas:e12jk40
1) Aspiration level for authentication.  Should a list of RNames be associated with each file?  What do we do about owner-based properties such as default access control, global disk quotas, etc?  Alpine is not a distributed database project, we would like to keep our aspirations very limited.e12jk40
2) Aspiration level for locks.  Should lock manager attempt to encode the locks for a run of pages in a space-efficient manner?e12jk40
3) Full specification of what operations are possible without transactions.  Is non-transactional access a file property?e12jk40