A Free Associative File System

Transcription

1 A Free Associative File System Alexander K. Ames Univ. of California, Santa Cruz Abstract The Free Associative File System is an alternative in file system structure from the hierarchical directory model. Files can be freely associated with various keywords that pertain to the file. I present a design for such a system with various alternatives that could be taken along the way and describe a simple prototype that I have built to test usability of the system using a simple shell interface. 1. Introduction One of the main purposes of having file systems for our computer systems is to provide users with a means to organize their data. Such a system is more useful to a user if he is able to quickly retrieve the data that he wants. To many users the structure of such a system appears to them as a hierarchy of folders within folders or directories within directories, depending on how the system names such entities. While such a system, which is the almost universal paradigm for file organization, may impose an order that allows the users to organize their files, it is not necessarily the ideal system for all users ways of thinking. Users should be able to organize their files non-hierarchically if they wish to do so. One such problem with the hierarchical directory model is it limits the categorization of files. Some users may want to organize their files by an original categorization scheme of their choosing. With hierarchical directories the user is limited to a process of defining subcategories within categories for each directory to be created and finally placing the file in some subcategory. Such a scheme is similar to taxonomy of organisms in biology where every organism must belong to a kingdom, phylum, class, etc. However it may become unclear to the user what to do in situations where it is desirable to have some file placed in more than one of the categories. This could just mean placing multiple instances of the file in all the possible directories named for each category it could belong. That becomes problematic if a user ever wishes to modify the file, it would need to be updated in all the different directoriew where was initially placed. Another possibility is to create links to the file such that the file would reside in one main directory, and the others would contain the links pointing to that file, thus enabling the user to find it in the other directories. This solution may introduce complexity to the file system that the maintainer of the system may want to avoid. Moreover, it would still retain the rigidity of the imposed hierarchical structure that may not always be suited for users organizations of their files. Another drawback of using the directory hierarchy for organizing ones file is that it can impose a tradeoff of depth versus breadth. Users may create numerous subdirectories for various categories under a single directory. They may find that it becomes cumbersome to look at such a long list of directories if the number created becomes so great. The solution to this problem is to take advantage of hierarchical structuring, creating subdirectories within directories for better organization. However, this creates depth that could mean lengthy pathnames and directory traversals in order to find a single file. This may discourage users from creating deep hierarchies and thus maintaining broad list of directories with the drawback mentioned above instead. As an alternative to the hierarchical directory model I propose a Free Associative File System (FAFS). We can identify all files within the system by using keywords. Files may be associated with one or more keywords. Thus our keywords in essence take the place of single directories. Files attached to a given keyword can be thought of as a set of files. Thus to find specific files we can perform the set operations of union, intersection and difference on the keyword sets to produce new subsets that best describe which files we are trying to find. In this model all keywords are essentially equal in weight; there is no imposed hierarchy on the systems. Thus users may attempt to use the system as they see fit, depending on their own thinking or how best to deal with certain groups of files that may differ depending on the specific work being done by the user. This paper is organized as follows. Section 2 presents background and related work in file system organization covering a brief history of the use of hierarchical directo- 1

2 ries in file systems and some alternatives to them. Section 3 proposes a design for the Free Associative File System noting various alternatives. Section 4 presents a prototype to evaluate the usability of such a system and proposes some possible extensions to such. Section 5 describes the evaluation of the prototype. Section 6 sums up future work and concludes. 2. Background and Related work 2.1. Hierarchical file systems overview A classic description of the use of hierarchical directories can be seen in the UNIX Time-sharing system [15, 17]. This described the directory structure for their system as being a hierarchy in which there is a top level root directory. Directories allow for a contextual view of a file system in this model where path names may be either relative to the current directory that a user is viewing or absolute, starting with the root directory. Furthermore, they include the feature of linking, in which directory entries may contain links, or pointers to files that reside in other places within the system. However, in their system, directories may not contain links to directories other than its proper subdirectory thus enforcing a strict tree-like hierarchy. Noted later [14], the prohibition against linking directories was not enforced. However, he also mentions a difficulty in using directories on the early UNIX file system was that they could not be created while the system was running. Based on the above structures, the UNIX file system reimplementation [8] would use the directory model to optimize performance. Since files generally belong to single directories, they found it efficient to place inodes of the files within the same directory in a single cylinder group to improve performance through increased locality. Thus the model of having files within directories is perpetuated through focusing an aspect of the low-level implementation around it. However, they also chip away a little at the strict tree-like hierarchical directory structure by adding symbolic links by which pathnames may contain links to directories other than their children, thus resolving that issue in the original file system implementation. This work would become the model for most commonly used file system implementations henceforth. Golden [3] presents an overview of this model within the Unix file system as it has become to be understood. He also shows how the directory paradigm has made its way into the designs of other file systems such as CP/M and PC-DOS s FAT. Due to these similarities in structure, he concludes that it should be possible to read foreign file systems despite other found difficulties Non-hierarchical Systems Ted Nelson [10] proposed a non-hierarchical structure for file organization a number years prior to the inception of directory hierarchies we find in UNIX and many other file systems. His concept was that files could be organized in zippered lists in which some files may be related by links along multiple axes other than a more traditional list containing them linearly where they may be associated only by a single concept. This work would involve into ZigZag [11, 18, 2], in which files could be organized and viewed in n dimensional space. There have been several prototypes of this idea constructed that are more tools to understand the organization that could be applied to the construction of a file system. There has no been no underlying file system constructed to actually handle real user files and file system operations using Nelson s model instead of directories in the sense of original Unix file system or FFS. Nonetheless, its interesting approach to providing a non-hierarchical structure for file organization makes it noteworthy. The Semantic File System or SFS from MIT [1] provided a change from the hierarchical directory model within a file system by allowing files to be queried by combinations of attribute value pairs. Such queries were the basis of SFS virtual directories that would make it compatible with the system interface that normally works with physical directories. Files would be indexed by use of transducers that depending on the type of file would assign values to various possible attributes for that file. However, users could not assign their own values to attributes in SFS. Following the direction taken in SFS, Essence [5] was a subsequent effort to provide keyword indexing for files within a system and allow for searching. Gopal [4] describes a system in which files in a hierarchical system can be retrieved with what he denotes as Content-Based Access in which one may create semantic directories using queries and further hierarchies may be constructed by nesting queries within queries for such directories. Marsden [7] looked at improving user access to files within a regular hierarchical system by creating an interface that allows searching and visualization by pre-existing metadata using some relational database concepts. Finally, there is LISFS [12]. Its authors consider it follows a new paradigm in file system organization, in which a combination of a file system with Boolean querying semantics and navigation are combined for more flexible access within one unified naming system. The ideas presented in this paper for FAFS are probably most similar to LISFS in some respects. 2

3 Figure 1. FAFS data structure design diagram 3. FAFS Design In designing a non-hierarchical file system, some questions may arise regarding how it may look in relation to other file systems presently used. If there is no hierarchy of directories, than what will replace them? Or will it retain directory structures and just impose a new ordering that can coexist with the old. One of the goals of this design is to have some flexibility, albeit it may appear vague at times, such that either of the approaches may be possible. Of course, if we were to completely remove all hierarchical structures, we would face many more challenges. This is unlikely to be done given how most applications have been designed to run on UNIX as we know now thus its feasibility isn t being entirely considered here. In the directory model, one may find the contents of a given subdirectory by name by knowing the path of parent directories up to the root. Once then you may traverse the pointers through each child to the given subdirectory and identify its contents. For example if I want to find the contents of c and I know the path is /a/b/c, then I can trasverse from the root through a and b to find c and then display its contents. Given the FAFS model, named attributes or keywords conceptually replace directories. This model has a flat namespace for keywords meaning all are equally accessible regardless of any context. Thus as groups of files are associated with various keywords, we need a mechanism by which a keyword may return the associated files. Our approach is to use hash tables that contain the mappings from keywords to the groups of files. The keyword serves as the key for these tables. The table should not initially be too large, though a hashing algorithm should be chosen that supports some degree of flexibility. Collisions can be handled with linked lists as we would hope to not have too many. This structure should reside in memory and there will be scheme to back it up to disk that shall be discussed later in this section. It is feasible that all defined keywords may persist indefinitely throughout the system. Even when all files once associated with a given keyword are removed, it may not be necessary to remove that keyword. Possibly, keywords could be flagged in a separate table as dormant such that they retain their locations in the master table as it is possible that a user who chose to remove a keyword from his list of keywords (separate from the table) would want to see it again given some change in the current files residing within the system. However, if keywords were to be removed from the master table frequently, we may enough missing table entries or holes growing in the table data. One possible way to handle this would be to rebuild the hash table. This should be done sparingly, possibly as a system startup or shutdown task. Groups of files within the FAFS design are essentially sets. These sets are collections of pointers to the files. To represent these sets we could either have them as linked lists containing the pointers or hash tables of varying sizes. If the amount of physical memory available happens to be scarce then using a linked-list approach to set implementation would be better, given some cost in performance. However systems with enough memory to spare for persistent data structures could use hash tables that could be rebuilt as they grow. Growth of these tables occurs as users associate more of their files with a given keyword. Our files will still reside on disk as defined by whichever block-level file system handles such allocations. For metadata associated with the files I need to propose a single change to add some new additional metadata. It is important that users be able to identify which keywords have been associated with a particular file. Keywords essentially become a new type of metadata within the file system, either replacing or supplementing directories for the purpose of organization. Thus we must keep track of them for each file. The approach is for the inodes of each file, we need to add a pointer to these keywords. A greedy approach would be to use a single disk block, which should be of the smallest size if the underlying file system has multiple size blocks, per each file to store the keywords. This would allow more room for keywords of longer length or key-phrases even to be stored for each file. The keywords should be stored as linked lists in memory and then written out to the blocks. Thus when the lists change as users modify their file associations, the blocks should be rewritten. If more keywords are associated with a given file than will fit in a single, then the end of the block should contain a pointer to another block of keywords. Alternatively we could decide to impose a metadata size cap on the number of keywords could be associated with a file as enough to fit in, shall we say, a 4K block. If saving disk space is a premium in some systems, although I can 3

4 hardly imagine that it could be anymore, then disk blocks could be segmented. The segments would be divided up among several files. In this each file would need to have some extra bits devoted to which segment it needs in addition to the keyword block pointer. Blocks should generally be located near the inode if not allocated adjacent to it, but any free block on disk would be sufficient despite the performance costs of locating a distant block. Another question arises of what status keywords should have in the file system. They resemble directories in that in a sense they can contain the files they are associated with, but they differ in that they cannot contain other keywords. Directories are similar to files as they contain metadata and have inodes. But should our keyword concepts be such as well? It is also unclear if keywords should be used for handling ownership of files. Possibly, each user could have his very own sets of keywords allowing for totally individualized organizational schemes. On the other hand, users may want to search for files using keywords that they themselves did not assign to the files. Directories simplify permissions by encompassing files in which all may have the same permission. This could be done with keywords, each having an inode on disk for its metadata much like a directory entries. The main hash table containing keywords would have a pointer to the inode for each in addition to the pointers to the sets of files. This has the potential to enable multi-user ownership schemes for files, as it would be possible for a single file to be associated with two keywords owned by separate users who both want the file to remain private. The file would be private to all other users but the two would have whatever access that choose to grant given the permissions within the keywords that they own. As the two main constructs introduced here to enable keyword access to files, a mechanism is needed to store them more permanently as they are presently described as functioning in memory. One possibility is to periodically write the tables to disk thus allowing for a batch of updates to be recorded to disk at once, much like the way delayed write caching works. This would allow for restoration of the data structures after a crash or accidental power loss. They could be written to one ore more special files known by the system for these structures. Another possibility is to write them like a log to disk in the vein of LFS [16]. Keeping a log of updates has the potential to introduce snapshots of the FAFS representations, as there might be some value to historical associations with files. There would be a disk space cost of keeping the logs and some cleaning function would need to be introduced that would ultimately impact the system performance. Another possibility would be to focus away from any frequent disk writes. Instead we would keep the new constructs in a non-volitile form of memory. This could be like the HeRMES idea [9] to use MRAM as the NVRAM of Figure 2. The Set Operation Engine process model choice. The main hash table and the data structures for the sets of file pointers could simply reside in the MRAM with the other metadata (inodes) and additionally the lists of attributes associated with each file. Writes to disk could be done seldom for backup purposes, if at all. However, this option should be considered an accessory for the system, as most hardware configurations are yet to provide enough NVRAM for metadata. The core to having this system work for the user is to allow queries using combinations of keywords. As groups of files can be though of as sets, then the use of the traditional set operations: intersection, union, and difference would allow users to create new sets of files for them to list from the base sets of those associated with the keywords. A processing component to be added to the system is a set operation engine. It would be able to process two sets and an operation as input, and then it will allocate and output a new set of file pointers resulting from the set operation. There will be performance costs involved in performing these operations. They may grow with the number of files in one of the sets as these operations are based on finding the common files between each, either to return them as done in set intersection, omit the duplicates in the case of set union, or omit some outright as in set difference. In addition the file pointers have to be copied. The general data and control flow for this component is shown in figure 2. These result sets should be cached alongside the query as it is likely for forgetful users to request the same query multiple times to find a same group of files without any changes. This leads to another possibility of having active caching of queries where when the base sets of files specified by a given query change, the resulting sets from the operations shall change by automatically rerunning the query operations. This would result in an improved performance experienced by the user on demand, but the set regeneration could impact performance at other times. 4

5 A final design goal in constructing this kind of system is make it compatible with existing UNIX file system semantics as best as possible. Path expressions would definitely change for file queries. I would want to try to build it around a VFS type of interface, having it support all the same operations. Some operations may need to change slightly. For example, copying a path denoted by a series of set operations to another could allow new sets to be created by those operations and associated with either a new keyword, or perhaps an existing one. Thus the question arises for existing keywords of whether such an operation should overwrite that particular keyword s associated set or append to it. Overwrites with backup, (the old keyword would be renamed) would be the option that I would most strongly consider for this. For copy operations on files, we would want to keep the known semantic for copy, producing a replica of the original for consistency. Thus files with the same name can exist with separate keyword associations. In cases of set union for such sets containing files with identical names, the names may need to be distinguished for the user when results of a query are viewed in an application, but should be left up to that application as it would be handling separate file pointers anyway. However, creating a new keyword with associated files containing multiple files of the same file name should not be allowed unless automatic renaming could be enabled. This behavior differs from that of hierarchical systems where different files of the same name can be present in separate directories, but attempts to copy one to the other would result in the latter being overwritten by the first. A move operation would basically swap a file between one keyword s set and another, preserving all other associated keywords for that file. Readdir would return a list of files from a simple set for a single keyword or a compound set as a result of a set operation query. Create directory operations would add new keywords to the system. Additionally, we would need to add operations to provide the association and dissociation of keywords with a file, as it is separate from copying and moving. It could take the place of linking, as that is the closest operation to what we wish to achieve. Dissociation could be done with a delete operation as it would remove the file pointer from a given keyword s set, but we also have the question of a single command to remove the file outright from all keywords and delete it. That could be done above the file system by an application. The final dissociation would result in the deletion of the file from the system altogether. 4. Prototype Implementation In order to perform some simple experimentation with some of the design concepts introduced for FAFS, I chose to develop a prototype. This prototype would serve mainly as a proof of concept for usability of an actual file system implementation; it could not serve as a general file system. Given a choice of how to implementing this prototype I chose to implement it in Java over C. This decision was based on that fact that I could use many of the classes contained in the Java API [6] that could potentially shorten my development time since my concern was representing file system structure and activity. Additionally there has been other file system research has been conducted in Java to build a prototype [13]. Thus I figured it possible to do so in that language, though well aware of possible tradeoffs such as in performance. Since my present concern at the time was basically relative performance of different aspects of the prototype to normal file operations, I thought it acceptable. I implemented the FAFS using two Java classes. One with the majority of my code for the system provides the file system interface API with all pertinent operations available to a client. This also contains the data structures as described earlier as implemented using Java objects. The other class used contains the code to perform the set operations. Converting from the design described above to Java was straightforward given that the language contained the APIs for usable objects to cut down on development time had I needed to implement the object classes for my data structures from scratch. One main difference between the prototype and the design is that given I could not modify file inodes to point to the lists of keywords I created another hash table to map file object pointers to the keyword lists. Additionally, I used Java hash set objects containing pointers to file objects for each keyword mapped set. Path names to files are organized as follows. There is a single / character separating the keywords component which appears on the left side of the slash and the filename component that appears on the right. The keywords component contains one or more keywords conjoined by various symbols representing the set operations. I used & for intersection as it is a similar operation to and, for union as it is similar to or, and - for set difference. In the current prototype implementation, the operations are processes from left to right. I do not currently support grouping of set operations by parentheses, but that would definitely be a feature worth including in a future system implementation. As to run on top of the file system class, I wrote a simple shell-like interface to allow a user to manually manipulate the files within the system. This shell supports simple operations such as cd, ls, cp, etc. that would translate into file system operations. I wanted the shell to mimic the interface of most UNIX shells, including the context of a current directory. However in our case without directories, the shell allows maintaining the current context of a 5

6 set of files as specified by a query path. Thus instead of having a pwd command, I provide the pwatts to print the working attributes or set of keywords serving as a current context for files to view in the shell. I also had cd renamed to cwatts for consistent naming as the user would technically be changing his working attributes, but I provide aliases of the known shell commands to their equivalents. One feature of note in the test shell implementation is that navigation is possible through something I call aggregate query paths. Essentially, queries to new sets of files, the equivalent of paths in this system, can be built upon augmenting the query to the current path query statement. Parameters for commands entered in the shell that want a path can begin with a set operation and that will thus join the current path query with the new path query by that given operation. For example if your current path view is a b, which is a view of the union of the sets for keywords a and b, performing a ls or cwatts on -c would be the same as performing the whole query on a b-c. This allows users ease in refinement of their queries to different sets of files. Examples containing these will appear in section 5. This allows for some navigation through the query space using the provided shell interface. A useful additional feature not implemented in this shell would be to maintain a history of path changes. Since there are no parent directories in this model, i.e. "..", one cannot simply go up to get back to a more general query from a specific. Here, if a user uses the aggregate query paths paradigm to build up queries, stepping back from a more specific query with more terms to one with less would be a possible replacement at the shell level. However, if the user tries a complex query initially instead of composing it incrementally, there would be no associated history to step back through given a simple interface like our shell Extensions The shell interface has been provided for initial testing of the system, but the real power from a system like this should lie in the creation of more powerful user interfaces (GUIs). If the motivation for the construction of such a system is usability, then ultimately usability must be tackled from this angle beyond that of the underlying system. Present file browsers that contain a modifiable current path and the contents (list of files) under that path would certainly function in the FAFS model. However, there would be greater possibilities for query building tools similar to document search engines and other nice user interfaces could be built to assist users in assigning keywords to files when they save them. This would allow for changes to the very standardized file load/save dialog that persists in most graphical user applications found in many platforms with windowing systems. Figure 3. Initial keyword sets Additionally as described in [12], it should be possible to implement name/value attribute pairs to describe files on top of the basic FAFS system. One of the initial decisions I had to make regarding the framework for this system was whether files should be tagged with single keywords or to use pairs like in SFS [1]. I decided to go with the keywords approach because mainly it seemed that associating files with general concepts that may not always fall into categories seemed more flexible. But secondly, it occurred to me that assigning a keyword to name/value pairs using some form of delimiter such as a : for Name:Value would be possible with an implementation to handle such on top of the system. This would allow for sorting files by new metadata introduced in the system where you may have a variety of values for a given name in a pairing, whereas sorting a group of files by single keyword does not make much sense. 5. Evaluation 5.1. Usability The first part of my evaluation is to examine the usability of the shell interface that I have constructed around the file system. I present here some simple examples of the file system shell in use to locate some groups of files. Figure 3 shows various calls to ls in an FAFS shell session. These files contain reviews of articles read for a software engineering class. The all keyword contains the universal set of files. The other keywords: overview, design, management, managament have been created and various files have been assigned to each. In figure 4 we examine some simple queries using the above keywords. Our user first noticed that for some of the files that he placed them in a misspelled management keyword. To see all the files together from both keywords as they should be, the user enters ls managament to union with the current path of working attributes. He con- 6

7 Figure 4. Examples of ls operations produced by set operations Figure 5. Examples of adding files to keywords using the shell tinues to refine his query by adding a second union with design to include those files as well, and then wants to omit the overview files. The commands that follow produce that result. Finally he wants to see all files pertaining to both design and overview so he enters an ls command to return the intersection of those keywords sets. Now our shell user realizes that there is a file tagged as design and another as management that in fact belong in both of those sets. Figure 5 shows the user shell operations to correct this. The user starts using the management keyword as context (working attribute). The first tag command he executes adds the first file that is in his current path to design. The second command shows him adding the file that is in the design keyword set to the current path. Thus tagging appears much like copying files except that it does not produce replicas of the original files as we can see in the final call to ls in the figure Performance I intended to gather performance data from the prototype to see if there are any potential scalability issues from the design. As the purpose of the prototype was to test out simple usability issues and not to handle real issues of Figure 6. Listfiles response times performance metering, I was prepared to present far from comprehensive results. The first problem with measuring the prototype is that the current version of java that I had to work with (1.4.2) does not have any finer granularity built into the jdk beyond ms. The second was that variations in response time are more likely caused by random scheduling issues on the host running the prototype. Nonetheless I decided to proceed in attempt to perhaps see some correlation. I ran a test script that from two pools of files, one with 525 and another with 744, assigned them to 21 keywords. There were 38 and 56 files associated with each keyword from each set respectively and 5 to 10 file overlap between keywords such that set operations would produce new sets of varying sizes. I then measured the time it took in ms to perform various listfiles operations within the file system object with one to four keywords in the query with operations for more than one making the single the baseline. Each group was done about 78 times varying the set operations and keywords used and twice that for the pool of 525 files. The response times have been averaged (many were 0 due to the extreme course granularity and are presented in Figure 6. We can see some increase from one to four keywords, but there was too much noise to really tell what is actually being measured. Perhaps when the next Java jdk is available that has a nanosecond timer, it will be possible to repeat the experiment and see some more meaningful results. 6. Future Work and Conclusion Much of this paper presents alternatives for the construction of a system. My main future goal for this system would be to attempt to build a better working prototype of the system. Experimenting with building a kernel implementation to run along side a traditional file system would allow to experiment with many of the alternatives presented here. This would allow us to better understand the various tradeoffs that we would encounter by choosing one alternative over another. Additionally, the user interface design 7

8 to go along with the system should be undertaken as it can better demonstrate the potential of how it can be valuable to file systems users of varying operational skill levels. I have demonstrated here that it is possible to break away from the status quo of file system organization. While we probably will be able to continue to use our file systems just like they are now without disruption, there is no reason why must if there are alternatives out there. Thus if empowering people through giving them better tools for their livelihoods is a worthwhile goal, I would hope that this work would contribute toward that goal. References [14] D. M. Ritchie. The evolution of the unix time-sharing system. The Bell System Technical Journal, 63(6 (part 2)): , [15] D. M. Ritchie and K. Thompson. The UNIX time-sharing system. The Bell System Technical Journal, 57(6 (part 2)):1905+, [16] M. Rosenblum and J. K. Ousterhout. The design and implementation of a log-structured file system. In Proceedings of the thirteenth ACM symposium on Operating systems principles, pages ACM Press, [17] K. Thompson. UNIX implementation. The Bell System Technical Journal, 57(6): , [18] Zigzag, [1] M. A. S. David K. Gifford, Pierre Jouvelot and J. W. O. Jr. Semantic file systems. Proceedings of the 13th ACM Symposium on Operating Systems Principles, pages 16 25, October [2] T. L.. K. Ervasti. Gzigzag - a platform for cybertext experiments. [3] D. Golden and M. Pechura. The structure of microcomputer file systems. Commun. ACM, 29(3): , [4] B. Gopal and U. Manber. Integrating content-based access mechanisms with hierarchical file systems. In Operating Systems Design and Implementation, pages , [5] D. R. Hardy and M. F. Schwartz. Essence: A resource discovery system based on semantic file indexing. In USENIX Winter, pages , [6] Javatm 2 platform, standard edition, v api specification, [7] G. Marsden and D. E. Cairns. Improving the usability of the hierarchical file system. In Proceedings of the 2003 annual research conference of the South African institute of computer scientists and information technologists on Enablement through technology, pages South African Institute for Computer Scientists and Information Technologists, [8] M. K. McKusick, W. N. Joy, S. J. Leffler, and R. S. Fabry. A fast file system for UNIX. Computer Systems, 2(3): , [9] E. L. Miller, S. A. Brandt, and D. D. E. Long. Hermes: High-performance reliable mram-enabled storage. In Proceedings of the 8th IEEE Workshop on Hot Topics in Operating Systems (HotOS-VIII), pages 83 87, May [10] T. H. Nelson. Complex information processing: a file structure for the complex, the changing and the indeterminate. In Proceedings of the th national conference, pages ACM Press, [11] T. H. Nelson. Zigzag (tech briefing). In Proceedings of the twelfth ACM conference on Hypertext and Hypermedia, pages ACM Press, [12] Y. Padioleau and O. Ridoux. A logic file system. In Proceedings of the 2003 USENIX Annual Technical Conference, June [13] S. Rhea, P. Eaton, D. Geels, H. Weatherspoon, B. Zhao, and J. Kubiatowicz. Pond: The oceanstore prototype,