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 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. D Copyright c 1988 by Xerox Corporation. All rights reserved. NewlineDelimiter (cedardoc) styleStyleDef BeginStyle (Cedar) AttachStyle (abstract) "for abstract nodes" { head4 AlternateFontFamily 14 en tabStops } StyleRule (root) "format for root nodes" { cedarRoot } ScreenRule (root) "format for root nodes" { 0 firstHeaders 0 lastDropFolio FontPrefix docStandard 36 pt topMargin 36 pt headerMargin .5 in footerMargin .5 in bottomMargin 1.75 in leftMargin 1.5 in rightMargin 5.25 in lineLength 24 pt topIndent 24 pt topLeading 0 leftIndent 0 rightIndent } PrintRule (pagenumber) "format for folio on each page" { unleaded AlternateFontFamily } StyleRule (positionInternalMemoLogo) "Xerox logo: screen" { docStandard 1 pt leading 1 pt topLeading 1 pt bottomLeading } ScreenRule (positionInternalMemoLogo) "for Xerox logo" { docStandard 1 pt leading 1 pt topLeading -36 pt bottomLeading -1.5 in leftIndent } PrintRule (internalMemoLogo) "Xerox logo: screen" { "Logo" family 18 bp size 20 pt topLeading 20 pt bottomLeading } ScreenRule (internalMemoLogo) "for Xerox logo" { "Logo" family 18 pt size 12 pt leading -36 pt topLeading 36 pt bottomLeading -1.5 in leftIndent } PrintRule (memoHead) "for the To, From, Subject nodes at front of memos" { docStandard AlternateFontFamily 240 pt tabStops } StyleRule EndStyleIunleadedMark insideHeaderbo<QF QQFQ@ `QLQQQPQC }QOQIbodyWQQk}c !QQ;QQB I Q e&,QQP(.QQ Q1Q=QQQQQ QQQQbnQPQl#B