CSL Notebook Entry: Working Notes for the PCedar File System
XEROX
To
From
CSL+^.pa Carl Hauser
PARC-CSL
Subject
Date
File system for PCedar June 9, 1988
Copyright © 1988 by Xerox Corporation. All rights reserved.
FOR XEROX INTERNAL USE ONLY
Abstract Working notes for the PCedar File System. Thoughts on the interface and implementations for both PCedar and Cedar
Attributes informal, draft, technical, Cedar, Programming research
References CSL-85-7, CSL-87-7 (Blue and whites)
Introduction
The Cedar File System (CFS), described in [1], has been moderately successful in integrating local file systems and file servers for users of Cedar workstations. The Portable Cedar File System (PFS) is the intended replacement for CFS on Portable Cedar (PCedar) systems.
Introduction to Cedar and Portable Cedar
Cedar language/system/applications boilerplate
Portable Cedar goals, features, implementation strategy
Introduction to the Cedar File System
CFS characteristics
local/global files, distinguished by name structure
version numbers on local and global filenames
names collections of bits
immutable global files, identified by name and timestamp
pseudo-servers
server classes supported (Pup-FTP, XNS Filing, NFS)
Introduction to NFS
NFS characteristics
match Unix file system primitives
names places to put bits
remote file systems mounted in name space of local file system
version 3 (draft as of June 20, 1988) has direct support for versions.
PFS Concept
An interface:
implementable in Cedar over FS,
implementable in PCedar over the Unix file system (as extended by NFS)
providing opportunity for common client code in Cedar and PCedar
providing opportunity for sensible file sharing between Cedar applications and Unix applications
sensible file names in both worlds (in each world's own sense of "sensible")
deal with tioga formatting
deal with CR/LF problem
deal with Cedar file properties (keep in particular, user properties in general)
deal with Cedar attachments (more specifc than Unix symbolic links)
To what extent should the concept go beyond a minimal change in semantics for Cedar to form the basis of future file storage:
separate immutability from "has a global name" (a conservative extension of FS)
maintain version history in the file? (some indication that we can maintain a compressed total history for all our files in less space than it takes to store 2 full versions!--is now the time to explore this?) (a radical extension of FS)
Interface considerations for integrating a Cedar-ish view with a Unix-ish view of files
Unix/Cedar interoperability: Cedar applications expect to manipulate named collections of bits, Unix applications expect to manipulate bits in named places; arrange the naming so that users (people) can easily direct applications in either system to read their intended input and produce their intended output.
From Unix, there is no syntactic distinction between "local" names and "global" names. In fact, in Cedar there is no need to make the distinction, but it proved convenient given the capabilities of the Pup-FTP file servers. Cedar really needs to distinguish immutable from mutable files; it makes very limited use of mutable files. AJD contends that the use of mutable files in Cedar is so limited that the system may not even need to enforce immutability, allowing it to be implemented by convention amongst users and applications. -- I don't believe this -- chh.
what is user's private name space
unix working directory at time PCedar is started as unix application--means that user utters different names in Cedar/Unix world. Perhaps user should only utter relative names in the Cedar.
Do we want to get more radical with file naming: e.g. we could adopt user-centric global naming as in the Quicksilver file system; this is ultimately a good thing, but should we try to do it now? If so how? Do we have the infrastructure in all the networks? (I think we do in XNS, but doubt it in the others).
Implementing the PFS interface over a Unix-like file system
file name mapping
file creation algorithm (steal from NFS view of Cedar Remote File)
how do we store file properties that are not part of the Unix file model?
in a second file?
cost of access?
in
the file, as a parsable header or trailer
cost of access?
precludes access to text using normal Unix primitives (only a problem for Unix programs--hidden by PFS implementation for Cedar).
Implementing the PFS interface over CFS
What we should do as research (but not in PFS)
I envision PARC&CSL evolving an information network incorporating distributed, shared hypertext and databases. By all means, Cedar and its tools should be pushing toward implementing and using parts of this information environment for all information storage.
But in PCedar we need smoothe access to existing files using existing paradigms: to take on a radical redesign is to commit error 33 for something that could be a simple port. So, always remembering the success-disaster of the IFS, I vote for planning a simple PFS supporting our current filing paradigm, while never letting what we really want get too far from our minds.
Private names and public names
In CFS, all names are from a global name space; a certain subset of the global names are syntactically identifiable as local names. Local names refer to the file system of the workstation on which they are uttered.
global-names = purely-global-names + local-names,
but each workstation can have a file with a given local-name.
In addition to providing the mutable/immutable distinction, the global/local distinction also provides a private/public distinction for users of personal workstations. (Users who share their workstation establish a private namespace within the local namespace of their workstation). A user's private namespace is necessarily local to a workstation, although one may have a private namespace on each of several workstations).
Problem: UFS doesn't have any built-in notion of local/global name distinction. All accessible files are found by walking from the root of the local file system through so-called "mount points", which may be arbitrarily placed in the the tree.
I think it's important to continue to provide a private namespace for each user, and I think we can do this so that a user has just one private namespace for all the Unix-based workstations (a good thing, I assert). CFS-based machines would continue to have a local namespace per workstation. UFS-based machines would share a private namespace per user. Likewise, mutability could be a file property.
Security
Security is a state of mind.
Structure
PFS will be implemented in the style of Cedar remote file: i.e., a collection of "access methods" (if you will) for a collection of different file systems.
PFSImpl provides a registration mechanism for new access methods. The first access methods to be implemented are PFSSunNFS and PFSUnix.
State
August 12, 1988 10:39:41 am PDT: PFSCanonicalNamesImpl: need to define and implement the escape convention for /, ! characters in file names.