A multilevel file system for high assurance

The designs of applications for multilevel systems cannot merely duplicate those of the untrusted world. When applications are built on a high assurance base, they will be constrained by the underlying policy enforcement mechanism. Consideration must be given to the creation and management of multilevel data structures by untrusted subjects. Applications should be designed to rely upon the TCB's security policy enforcement services rather than build new access control services beyond the TCB perimeter. The results of an analysis of the design of a general purpose file system developed to execute as an untrusted application on a high assurance TCB are presented. The design illustrates a number of solutions to problems resulting from a high assurance environment.<<ETX>>


Introduction
As a result of the Trusted Computer System Evaluation Criteria (TCSEC:) [2] system architecture requirement for minimization, trusted systems at the highest levels of assurance can present primitive interfaces lacking the rich variety of functions typically offered by general purpose operating systems. The primitive nature of high assurance trusted computing base (TCB) interfaces has lead some to argue that high assurance systems are unusable. Others assert tha,t, as a result of it,s enforcement of both mandatory and discretionary ac,cess control policie,s, the underlying TCB places constraints on untrusted subjects that render the development of all but the most trivial of ap plical,ions impossible.
'This paper presents an analysis of a file system developed as part of the Gemini Application Resource and Network Support (GARNETS) [5], an operatirig system intended to execute as an untrusted applica-t8ioti on a Class, A 1 TCB.' rhe results presented here will dernonstrate that an ayplic.ation as broadly stated as a general purpose file system can he designed and implemented on a high assurance base, thus providing a usable applications support environment. The design uses TCB mechanisms to provide an interface which is both "friendly" The principle motivation for choosing a rigorous approach to software design and implementation derives from Dijkstra's [9] successful implementation of an operating system using a small engineering team A second motivation for achie% ing at least Class (:2 an hitectural requiremerits results from the potent la1 for using GARNETS as part of an Class A1 composition under the Trusted Net,work Interpretation (7 " I) of the TCSEC [4] Instead of implementing GAR-NElTS as an untrusted application on a monolithically evaluated TCB, one might elect to w e it as part of a Class A1 TNI composition In this case mandatory access control policy would be enforcpd b \ the underlying Gemini Trusted Network Proresbor (<,TNP) [20], a recentlj evaluated Class A1 TNI "Mccrmponent" Here the (;EMSOS Discrettonarj T( 'B and GARNETS would be executed on a virtual niachine created by the underlying GTNP and would be uiitrusted with respect to mandatory access control pcllicy If a database management system enforcing a highly granular access control pollcj were to be ported onto the GARNETS interface, then GARNETS woiild bt,come part of a TNI "D component" [ll]. t,t,ry TCB provides a ring mechanisni which is used to create the protection domains available to each procrss. The classic definition of yroc:css-dom.ain pinr is applicable to each GEMSOS subjeci . Thus there is a TCB subject enforcing discretionary policy, a GAR-KETS subject, and an applications subject. Figure 2 depicts a systems archit.ecture for a data base management system h s e d on a 'T"I composition. l~i this case, the T(:B perimeter is at the DBMS interface. The same subject applies to both GARN E3" and the IIBMS.

File System Building Blocks
The GARNETS documentation revealed that the GARNETS file system is constructed using named objects exported at the interface of the GEMSOS distributed TCB. There are two types of named objects: discretionary access control lists (DACLs) and multisegments. Access control lists ( ACLs) are associated with every object of both types and are used by the TCB to mediate discretionary access to the objects. Objects at the TCB interface may be composed of one or more storage objects. Associated with each storage object is a label which is used by the TCB to enforce it non-discretionary access control policy.

Segments
The fundament,al storage objects and the loci of mandatory access control are segments. GEMSOS segments are similar to those described iit the Multics system [19]. Associated with each segment is an immutable access class which reflects the sensitivity of the information stored in the segment [18]. A process, as the surrogate for the user, provides the vehicle by which the user can reference and access segments. Segments may be referenced once they are added to the virtual memory of the process, in GEMSOS, an action called "making known" a segment. When part of the virtual memory of the process, segments may be read o r written, according to the mode of accests obtained, as a piece of memory. Finally, segments are simultaneously and independentsly shared by proc.esses, where the actions of each process on a given segm6,rit are controlled by the accvss rights with which the segment is made known to the process. At t,he GEMSOS TCB interface, segments are accessible only as 1:lements of multisegments, which will be discussed below.

Discretionary Access Control Lists
Discretionary access control lists (DA(:Ls) are interpretively accessed named objects exported at the GEMSOS TCB interface used for mediating discretionary access. Each DACL contains a limited number of access c,ontrol lists corresponding to the number of entries that can be created off of the DACL segment in the GEMSOS segment naming system [18 . The ACLs access to DACLs and msegs which are associated with that particular DACL by virtue of being "entries" off of the DACL. Each DACL contains two modifiable templates which are used by the TCB to initialize the access control lists for DACLs and multisegments respectively, thus ensuring a default access control list for each object. DACLs are used by GARNETS as be building blocks for directories.

Multisegments
Multisegments, or msegs, are named TCB objects. Each multisegment consists of a collection of zero or more segments. Each segment is a TCB storage object having a label attribute so that access to individual segments is mediated by the underlying mandatory TCB. Within a given multisegment, all segments are hierarchically related to a single base segment with which an ACL is associated. Once current access to the base segment of the mseg is obtained, discretionary access to other members of that mseg's hierarchy is granted. An mseg may be multilevel and access to each se ment within an mseg is mediated by the TCB for bindting to the base segment and for the non-'TCB subject's access with respect to the mandatory access control policy. The rules for Compatibility and inverse compatibility [7,8,181 govern the mandatory relationship between a segment and its entries. The size of each segment within an mseg is bounded only by an upper limit to segment, size imposed by the TCB. Msegs are used to contain data. GARNETS' internal data structures, such as directory databases, and int,erpretively accessed files are built from msegs. Msegs are also exported at the GARNETS interface.

File System Objects
In this section, analysis of the rationale for the choice of objects visible at the GARNETS interface is reviewed. A uiding principle evident throughout the GARNETS fesign documentation was the reliance upon strong TCB mechanisms to provide the enforcement of access control policy rather than building mechanisms within the operating system which would have provided a lower level of or no assurance that the DAC policy was enforced correctly [lo]. Thus despite the fact that GARNETS is not part of the high assurance TCB, it exhibits "strong DAC". This means that, although GARNETS might be flawed or contain malicious software, user data is protected by TCB mecha nisms. The types of objects supported by GARNETS were based upon the objec,tives of relying on the high asurance TCB to provide access control policy enforcement and constructing a file system which could be managed without resorting to trusted subjects.
The GEMSOS TCB provides a ring mechanism [ 181 which GARNETS uses to protect its internal data structures and provide interpretive access to objects by less privileged applications.
contained in DACLs are used to mediate d iscretionary

Directories
Several access control objectives provided motivation for the design of GARNETS' directories.
GARNETS' designers chose to permit DAC access to files independent of discretionary access to directories along the paths t o files. (This choice results in a divergence from UNIX [6] which requires access to all directories along a path in order to access a file. The result of this design choice in an environment based on the high assurance GEMSOS DAC interface was a rather complex directory structure. In addition, GARNETS' designers sought to create a file system in which the default access to files and named msegs (see section 4.2) could be managed independently of the default access to directories.

Internal Directory Structure
The file system is built from three parallel trees each with a similar structure. The first is a directory tree in which access to a particular DACL in that tree determines whether or not the subject can manipulate directories, e.g. create and delete entries. Associated with each directory component in the directory tree is an mseg used to contain GARNETS-internal directory management databases.
Files occupy a separate, but parallel, tree consisting of two components per directory: a DACL from which the tree is extended and a DACL containin the access control lists applied to the files and name2 msegs which are its entries.
Finally a third tree is constructed from segment entries within an mseg the internal structure of which mirrors the directory tree. This huge mseg contains a dynamic "road map" to the file system and is used to walk the directory and file trees in search of target objects. It contains, for example, the names and aliases for directory entries. Because access to this giant mseg must be set at the root of the tree, its discretionary access control list must be such that it in accessible to all GARNETS subjects. Upon first inspection one might assume that this mseg, which is writable by all GARNETS subjects (constrained by the mandatory labels associated with each component segment), renders the entire file system vulnerable to attack. There are t,hree reasons why this is not so: 1. Data containers, viz. files and named msegs, are protected by ACLs associated with the file tree. So even if the information in !,he global mseg were to become corrupted, the data to bv protected would still be subject to access mediation by the TCB, however difficult it might be to locate.

2.
The mseg is accessible only by GARNETS subjects, thus a GARNETS Trojan Horse rather than a malicious application would be needed to intentionally disrupt this portion of the directory data.
checks within the directory tu protect the mseg from unauthorized modification. Figure 3 illustrates the components that are used to huild GARNETS directories GM is the multisegment in which provides all s u b jects with a road map to the directory tree DTD is the Directory Tree DACL. the GEMSOS DACL used to c,ontrol access to the tree from which directories are built and contains the access control lists associated with directory entries to the directory D M is the Directory Multisegnient. the GEMSOS multisegment used to contain dynamic data associated with directory entries FTD is the File Tree DACL, tiit. GEMSOS DACL used to extend the t,ree FD the File DACL, the GEMSOS IIACL which contains the access control lists associated with file entries to the directory 'These three trees permit the DA(:, including the default ac.cess control lists, for files arid directories to be managed independently. In addition, access to files does not require explicit access to intervening directories.

Single Level Directories
GARNETS supports directories which contain information all at one access class.

4.1..3 Multilevel Directories (reiected)
From the GARNETS perspective, multilevel directories were considered to be directories which contained information at different, access classes. GARNETS designers chose not to support multilevel directories. The need for trusted subjects to manage multilevel tlirectories was the principle reason for their rejection. In addition, GARNETS" virtual niultilevel directtories (see section 7.3) providt= an agreeable alt,ernat,ivr t.o physical rnultilevel t i i rec tories.

U p g r a d e d Directories
GARNETS permits the creation of upgraded directories. The GEMSOS TC'B requires that the compalibility property be preserved, thus the access class of an upgraded directory must dominate that of its parent [lS]. GARNETS limits directory information contained in the parent directory to that which should be visible at parent directory's access class. For example, the names and creation dates of upgraded subdirectoriw are visible to parent-level subjects. All dynamic directory information is contained in t,he upgraded directory itself. Thus, attributes such as the time of last modification and cont$enl,s of of the upgraded directory are visible only at the upgraded access class. In order to provide uniform directory semantics and implementation, both normal and upgraded directories are treated and initialized using the same functions. In the case of upgraded directories, the initialization is exported to the GARNETS interface since it must be performed by a subject at the upgraded access class rather than one at the level of the parent directory.
Deletion of upgraded directories will require the use of a trusted subject, which in this context does not necessarily imply the use of a subject with the entire range of access classes possible on the system, but one whose range encompasses the access class of the upgraded directory and its parent. Because of this need for a trusted subject, GARNETS controls the creation of upgraded directories. and requires users to have a t,pecial authorization to create upgraded directories. The fact that special measures are required to delete upgraded directories might indicate that such objects tihould be prohibited. Subsequent discussion will illustrate how they can be avoided, however possible requirements for a multilevel file system on a multilevel volume appears to have lead to their inclusion in I he file system.

Named Multisegments
At its interface, GARNETS presents multisegments that are nameable directory entries. In contrast to tiles, which are interpretatively accessed GARNETS objects, once a multisegment is included in the pror.ess' address space', segments within a named mseg may be accessed directly via the available hardware primitives. The GEMSOS segment aliasing virtualizes segment names in order to prevent covert channels that would result from a "flat" system-wide segment naming scheme [IS]. Within each process, subjects in more privileged domains must protect the segments wed for subject-internal databases from corruption by less privileged subjects. GARNETS accomplishes this hy virtualizing its per-process segment naming scheme m d utilizing the GEMSOS ring mechanism to insure i he integrity of its own segments.
There are three major reasons to justify the exportation of named msegs at the GARNETS interface. First named msegs permit processes to avoid unnecessary buffering. For example, if 4:xecutable rodcl is stored in files, then internal to the file the oxecutable will be broken up into one or more segments each with a length equal to the standard file block size. When code is to be executed, it must be read from the file and placed into one or more exeiutable segments the size of which corresponds to that required by the code itself. By using named msegs to contain executables, the code can be stored in segments within the file system which are the correct size and directly executable. Since code should not he modifiable, these segments can be shared by multiple processes (only data segments need to be created t)n a per-process basis). Thus named msegs promote s h a r i n g of executables the benefits of which include c.fficient use of real memory resources and potential increased performance resulting from reduced swapping. Because named msegs are directly accessible

Extended Code Sharing
The availability of riisegs as containers for code permits the use of the T(:B ring mechanism to create code scgirients which may he accessed by subjects in niultiple dONiitinS uithin the same process This was utilized to advantage by GARNETS in a storage maner which is r e q u i r d b j GARNETS itself and is availle for USP 11) lou Ievi'l Iibrariw I I I the appliration Tti(, t WO domains rriaintained t h(,ir dr main as wt 11 own initialization code and data segments for the storage manager, but shared the bulk of the executable code in comrnon. Thus GARNETS provides executa bles which, if labeled at the system low access class, are executable by all GARNETS and application subjects: code sharing is both inter-and intra-process. Since the shared code made TCR function calls, applications executing the code are spared the additional context switches through GARNETS. This could provide a perfortnance advantage.

Single Level Named Multisegments
Subjects which have modify or append access to a directory are able to create single level named mulhegments. The ACL associated with a particular named multisegment determines the modv of discretionary access permitted for a given subject.

Multilevel Named Multisegments
Multilevel named multisegments are exported at the GARNETS interface and are available for applications designers to create multilevel data structures. Obviously, electing to utilize these objects requires care on t)he part of applications designers since the untrusted subjects of the GARNETS environment cannot delete upgraded objects. To prevent users from wantonly creating objects which require administrative intervention, viz., trusted subjects, to delete, (iARNETS requires users to have a special authorization to create inultilevel narned msegs.

4-3 Files
I n this section the analysis reviews the choices regarding files made by the GARNETS designers The focus here is on decisions related to the high assurance rnultilevel perspective.

Single Level Files
Files are interpretively ~X S S objccts provided for iise bsy applications at the GARNETS iriterface One A( 'L managed by the TCB is associated with each file File at tributes maintained by GARNETS include file size time of last modification, and a write version (see sectiim 9 2 ) read, lo fi1t.s is ulidated only wheri the access IS rnade by subjects at tlic Irve.1 of the file Time of last access, viz

4..3.2 Multilevel Files (rejected)
C; A RNETS designers chose not to support multilevel files. Apparently, experience had already indicated that sufficient care in the design of applications could eliminate perceived requirements for multilevel files [14, 121. Where multilevel objectss are required, it is p1)ssible for untrusted applications to create views that give the user the illusion of multilevel objects. The semantics of multilevel files would have created an incc:Jherent interface. A small sample of the problems associated with multilevel files clarifies the reasons for tlieir rejection: Where would file attributes be stored, a1 the lowest access clltss of the file or the highest? H o w could standardized support libraries at the application level, e.g. the ANSI C language libraries, bt. used in the context of multilevel files? How would C C jmplex trusted subjech be avoided'! As a result of electing to not implement rnultilrvel files, all attributes for all files art! stored within a d -rr~&ry in a single direct,ory-local objwt which has t,he sitme mandatory access class as the film and their parent directory. Obviously t,his object. is not protect,ed by individual file A(.'Ls but the A(;L associated with the directory. Thus the directory is t,he unit of access control for attributes. For most purposes, this would btadequate, however, if high granularity on DAC for at tributes is needed. then additiortal directories will b<-required.

Solving the Gizillion Problem
High assurance rnultilevel trusted systems must hji.ndlp the problem of a potentially very large num-l>t)r of access classes. (Systems are i n use which have 1 5 x 10' access classes [I].) Known as the gztillzon p robleiri [ 1 11 ~ it had tc be addrrssed when building flvxible untrusted applications OII ( i EMSOS. The underlying TCB provides access classes consisting of i,wo sc,ts of 16 hierarchical levels and 96 non-hierarchical categories. Because TCB complexii,y must be mininiizrd at, high assurance, an objective o f any design tvchniqur to acc,onmiorlatr these nccrss classes will be bra the avoidance of the construction of elaborate data structures by the 'RTB in supporl of applications.
At each access class, the GEMSOS syst ern provides only one object which can be usrd as an access class base by non-'TC;B applications. As a consequence, an untrusted application such as a file system cannot depend upon trusted mechanisms to build its multilevel data structures; whatever file system constructs are required at a particular access class must be constructed by the untrusted operating system.
When a previously unencountered acctss class is selected, a GARNETS subject must be able to create the data structures and data bases required to support an application subject. At a minimum, a stack for the application subject executing on GARNETS will be needed.
Several solutions were possible Userc could request that the GARNETS administrator create the data structures at the new access class. A t system low, the administrator would create an upgraded directory below the file system root for each new access class. Then at each new access class the adrninistrator would have to create the necessary file system data structures. A disndvantage of this approach is that the GARN E l 3 administrator would ham* access to the system at the full range of access classes. In addition, use of the system at a new access class would depend upon the administrator's timely response to requests.
An alternative would be for the administrator to create data structures at all possible accebs classes a praorz. The advantage to this approach is that the data structures would be available whenever a user wished to use a "new" access class. We note that this choice is untenable because of the time required to create a gizillion data structures. On the other hand, I f a trusted subject were employed to automate this process, the GARNETS designers would have failed in their objective to have the system managed by untrusted subjects. In addition, a trusted siibject able to create portions of the file system would be far too complex to satisfy high assurance system architecture requirements, which must be met by the GEMSOS TCB. In either case, the creation of a gieillion data structures would certainly consume all of tlie system's available disk spare.
GARNETS utilized another strategy: E O dynamically create all required data structures at each newly encountered acces:, class On the first occurrence of a previously unencoiintered access class, i.e., the instantiation of a GARVETS subject a t that axess class, the GEMSOS TC13 builds a DACL segment that may be used by non-TCB subjects as a base f1,r creating data structures ,I function is provided a1 the TCB interface to locate the DACL. With this t ase, GAR-NETS dynamically builds the segment substructure needed for its owii execution and portion? of the file system sufficient to support initial execut on of non-GARNETS applications. Once all of the esr+ential data structures have been created for a particular access class, GARNETS is able to supporf additional non-TCB subjects at that level.
A portion of the file system is created at each new access class. The per access class file system base is called a per access class (PAC) directory With the PAC' directory, application subjects at the new access class have a location for "home" and "terriporary" di-rw tories It should be noted that when GARNETS is first iriatalled, a GARNETS administrator must login at the system low access class and execute bootstrapping code which has been previously installed using a tool provided with the Gemini system. Thus GARNETS code is not located in the file system, but in separate data structures a t pre-defined locations. Later, when other subjects at higher access classes are inst mtiated, these GARNETS subjects will dominate t h . access class of the code and will be be able to cre-P the file system structures using the per access class I) ist' as a ytartiiig point 6 File System Object Naming 6

.2 Aliases
Within a directory, GARNETS pcmnits the use of alias names for objects These aliases are tied to the physical object so that the object is not deleted until ita last alias is deleted

Links
GARNETS designers chose not t,o use hard links, links such that the object is shared between its n;tines A compelling reason for t,his choice was the fat t that the mandatory TC'B would prohibit the credt ion of such links across access classes.
Instead, GARNETS implements symbolic links earh of which is a path to a target object Symbolic link paths rnay contain links. When access to an ob-.lei t is made via a GARNETS function, the existence of intervening links is transparent to the user. In atidition to links to files and named msegs, GARNETS permits synibolic links to be created to directories and to links thernselves As is the case in many file systems uhxng symbolic links, GARNETS does not explicitly chvck for cycles when st,arting to traverse a path. Insti ad, the nurnber of links traversed i s counted and w l i~n an upper lintit is encounterecl a cvcle is assuined hiicl the traversal is aborted

Per Access Class Links
GARNETS supports a form of symbolic link which in( ludes a field for an access class these are known as pei access class (PAC) links When resolving a PAC link, GARNETS finds the PAC directory corresponding to the access class in the link The remainder of thr. path associated with the PAC link is traversed relative to the PAC' directory

Leveraging File System Solutions
Having provided a solution to the gizillion probleni, a number of benefits result

7.1
When the TCB is configured with single level voluriies, the GARNETS file system can be distributed 1)) access class by building single level file systems on par h volume Symbolic links permit the file systern to be bound into a multilevel data structure, with the uritlerlying volume configuration transparent to appIical ions.

Creation of Per Access Class Re-
Within an operating system certain services are provided to all operating system subjects. In a distributed operating system such as GARNETS providing these services is based on the ability of instances of the system to coordinate their management of those services. The creation of services on a per access class basis permits coordinated services without trusted subjects lJnique file system identifiers comprise an example of an internal resource which is needed for coherent management of file systems. In general, unique file system identifiers are numbers chosen from a large set, are never reused, and are always bound to a specific object. Unique file system identifiers for multilevel systems present special problems. Constraints of the tnandatory access control enforcement mechanism prebent one untrusted source of file system identifiers for all GARNETS subjects. Having guaranteed that there will be resources available at each new access class that can be used by GARNETS to build its internal data Iiases, GARNETS can dynamically construct file system identifier services at each new access class. To insure that file system identifiers are unique across access classes, the access class is implicitly part of the identifier, viz. if two names refer to objects with the aame numerical identifier but different acccss classes, then the names refer to different objects.

A Virtual Multilevel File System
When combined with symbolic links, PAC links offer a number of advantages for creating a multilevel file system. source Services single level subjects can create and destroy symbolic links, no interaction with subjects or objects at other access classes is required links can be created which cross volume boundaries symbolic links may be created to objects at either higher or lower access classes because GARNETS permits the creation of links to directories, it is possible to create the illusion of upgraded directories, files and nanied msegs without creating objects which are physically upgraded relative to the directory in which they appear to be located. This permits "upgraded" file system objects to exist in GARNETS without requiring a trusted subject for the deletion of such objects symbolic links need not be bound to preexisting objects. This permits the user to create a "view" of the file system at a particular access class without having to toggle between several other access classes to insure that the objects exist GARNETS users have the ability to create and manage uzrtual rnulteleuel dtrectortes without the aid of trusted subjects. These directories are likely to provide users with substantial file system management benefits, saving users considerable time when interactively navigating through the file system

Working Directories
Many file systems support the notion of a current working directory, i.e. a directory relative to which other objects in the file system are riamed. Because thP components of the file systern with which an application might be working could be distributed over several different volumes, GARNETS supports multiple working directories. This may be employed by applications to reduce path walking and, if desired, can always be reduced to the degenerate case of only one current working directory by applic,ation libraries.

GARNETS Self Protection
The GEMSOS TCB creates protection domains and provides a ring mechanism 181. Although the GEMtion to protect itself from external tampering or modification, it is necessary for t,he application to use them effectively. GARNETS sumeeds in this respect. The GARNETS system is parameterized to so that its subjects execute in a specific protection domain. App1ic.ation subjects execute in a less privileged domain. The inlerpretatively accessed objects such as files and directories that GARNETS 1)resent.s at, its interface, as well as GARNETS' internal data structures are stored in TCB objects which are accessible only by subjects at least as privileged as those in tmhe GAR.NETS ring.

GARNETS Ring Brackets
(:ertain directories within the GARNETS file systeiri are required by GARNETS for its own correct operation. The DACLs used to construct, directories arp TCB objects which are interpretively accessed by GARNETS, thus the GEMSOS ring mechanism has already be applied against tshese ohjects and cannot be used by GARNETS in this instarice 'To permit (:A[<-NETS to distinguish between directories which (;A 1%-NETS may access on behalf of applications and those that GARNETS reserves for its own use, GARNIIX" created its own simple ring mechanism. The operating system supports its own ring brackets and provides for caller validation. Thtt GARNE'L'S ring brackets defiiie a range of callers on whose behalf GARNETS will grant selected modes of access.
GARNETS ring brackets apply to all objects within a particular directory and are permanently set at the tiiue of directory creation from a modifiable template in trhe parent directory.

File Consistency
A desirable feature of file systems is file consistency in the face of discontinuities. The GARNETS system contains a mechanism to permit, fine-grained robustness selection.
Robustness level is intended to provide users with a fltxibla mechanism to assign consistency requirements SOS mechanisms are ataila 6 le to permit an applica-to files. The GEMSOS TCB does not give any guarantees that a segment when added to the address space of a process, swapped into volatile memory, and subsequently modified will be written to secondary storage: instead an explicit function call must be made to the TCB to flush the segment to secondary storage. Guarantees regarding the consistency of data in volatile memory with respect to its version on secondary storage must be provided by non-TCB mechanisms. Following a system discontinuity, users need to know the state of their files. For a file system, a redo log scheme such as those found in databases would be too complex. Instead, GARNETS provides an indicator of file consistency and four robustness levels for maintaining consistency between copies in memory and those on secondary storage. Following a system discontinuity, it is up to the GARNETS administrator or user to c,xamine the consistency indicators and repair files as needed.
In specifying robustness levels, two factors are considered: whether the file block is written to secondary storage and whether the indicator of file consistency I S written to secondary storage. Four file robustness levels are available: tione This robustness level provides no file consistency support. It is most appropriate for temporary files.
on-close When a file is opened it is marked potentially inconsistent and the indicator is written to secondary storage. No guarantees regarding file robustness are given while the file is open. When the file is closed, all modified file blocks are guaranteed to havr been written to secondary stora e and the file is marked as consistent and the in%icator is written t o secondary storage.
checkpointing This robustness level is intended for use by applications such as databases Modified file blocks are written to secondary storage as part of each call to the GARNETS wrtte-filc function.
To reduce the overhead associated with updates of the associat,ed consistency indicator, the indicator is updated only when the file is opened and when it is later closed.
on-write Each write is provided with the assurance that modified file blocks are written to secondary storage and the file is marked as consistent following a successful return to the application For files which may have multiple concurrent writt m , robustness is a file attribute assigned on a perclirectory basis and may not be modified following directory creation. This design choice reflects4 the practical observation that users tend to treat all of the files in a particular dirwtory similarly.
An option provides for directories in which access to all contained files is restricted to a single writer at a time. For such files it is possible to allow the writer to het the file's robustness level a t the time it is opened. Full file write, locks are used to insure single writer iLCCt?SS.