A Categorical Model for a Versioning File System

Transcription

1 A Categorical Model for a Versioning File System Eduardo S. L. Gastal Instituto de Informática Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal Porto Alegre RS Brazil eslgastal@inf.ufrgs.br Abstract. Category Theory is known to have a large level of abstraction. While some can see this as a weak point, others have proved that we can use this to our advantage. In this paper, we try to approach the file system design with a categorical perspective. 1. Introduction Some time ago there was a big phase shift in computing. Computers became much cheaper then they were before, and users became the most important aspect of any developed software; in particular, operating systems. The problem now was that users needed their data and programs around while using the computer. The solution was the development of file systems for quick and easy access to stored data. File systems are implemented with storage, hierarchical organization, manipulation, navigation, access, and retrieval of data in mind. Traditional file systems often work with an underlying data storage device, which provides access to an array of data-blocks. The file system software is responsible for the logical organization of such blocks (i.e., in files and directories) and for keeping relevant metadata stored for future use. However, file systems are not restricted to physically stored data, a common example are network file systems such as NFS and SMB. When working with valuable data, it is often desired that subsequent changes made to a file be stored, ensuring that no information gets lost due to user or system error. As storage space is getting cheaper by the day, it thus makes perfect sense for the file system to use some of this cheap storage to retain file modification history, guaranteeing that mistakenly removed or overwritten information can be retrieved easily. Versioning file systems serve this purpose, and are often transparent for the user. Here, we will develop a high level model for a versioning file system. For this, category theory will be our ally and all low level details shall get abstracted away. 2. The Basis The most basic organization we can think for a file system is a set of files with no order or classification. We will use this as our starting point. The primary property we need is versioning. We need a way for storing the history of our data. As we are dealing with sets (for the time being) we must relate the current state S i with the next state S i+1 of our files (we use state as in state in time ), so let us establish a relation between these two states, and let s call this relation H i.

2 Figure 1. Left: The deletion of d gives us a problem of undefined behavior. Right: The solution adding a trash file. Figure 2. Definition of H i We would clearly like H i to be functional and total this will ease our transition to the categorical view later on. As can be seen in Figure 1 (left), the deletion of file d makes H 0 a partial function. To solve this, we create a pseudo-file T that we will call trash file. All files that get deleted will relate with it trough H i. We should also notice that the creation of file c results in no problem. The final definition for H 0 can be seen in Figure 2. So far we have been working with pure sets. Now, let us translate this to a more categorical perspective. 3. Categorical View We are coming from a set theoretic model, so here we will work with a subcategory of Set where all objects are sets, and all morphisms are functions. The first step we can make is calling S i objects (as they are sets) and H i morphisms (functions). Now we need a way of defining the contents of each state. As morphisms are the best form of expression we have, let us focus on them. If we add a new object called {*} representing a unary set, observe that we can then define N functions with domain in {*} and codomain in S i, where N is the number of elements in S i (i.e., its cardinal). What we have just done is defining the files in state S i as morphisms from {*} to S i. We can now say that m:{*} S i represents file m from S i as morphism! (Please note that in Figure 3, and others, we are using repeated morphism names for clarity in understanding).

3 Figure 3. Left: The inside meaning of each function. Right: Notice how we do not lose any information with this representation. Observing our model up to this point, we already have a nice property in our hands, which is presented below Monomorphism No file deletion It can be easily seen that if our history morphism H i is a monomorphism, then no files have been removed when transitioning from state S i to state S i+1. We will prove this in two steps: first we prove that file deletion results in a non monic H i, second we prove that no file deletion results in a monic H i. Figure 4. File deletion No monomorphism Figure 4 illustrates the first step: at (1) we are just differentiating both trash morphisms. In (2) we state that for any file f in S i (different from our trash-file), then there exists morphism :{*} S i (different from our trash-morphism) that defines f. Finally, in (3) we conclude that, if f is being deleted, then the diagram formed by *, S i and S i+1 commutes, but, so H i is not monomorphism. Figure 5. No file deletion Monomorphism The second step is easier: Analyzing Figure 2 and 3, we can infer that whenever there is no file deletion, H i is an injective function. Figure 5 illustrates the remaining of

4 the proof: for any two files f 1 and f 2, if their composition with H i is the same then f 1 = f 2 and H i is monomorphism. After proving that H i is monomorphism if and only if there are no files being deleted, we wonder if there exists a similar connection between epimorphisms and file creation. With some careful inspection, we notice that this connection does not exist in our current model. For this purpose, we will create a new helper object (called {+,-} and representing a binary set) and add all possible functions from our history states to this set. Like so, we can then present this new property Epimorphism No file creation Again we will prove using two steps: first we prove that file creation results in a H i not being epimorphism, second we prove that no file creation results in H i being epimophism. Figure 6. File creation No epimorphism First step is as follows: for f a file being created, we can define two functions g 1 and g 2 such that g 1 g 2 and, when composed with H i, the diagram formed by S i, S i+1 and {+,-} commutes, proving that H i is not epimorphism. Figure 7. No file creation Epimorphism In the second step, we note that if a file is not being created, then it exists in both states S i and S i+1 (we use f 1 and f 2 to differentiate between these two states, but they refer to the same file f). Then, if the diagram formed by S i, S i+1 and {+,-} commutes, we have that g 1 = g 2 and Hi is epimorphism. Illustrated in Figure 8 is what we have so far. Please note that we will not represent compositions and identities for the sake of clarity. (Even though some compositions have meaning to our model, such as H 1 H 0 representing the transition from S 0 directly to S 2 ).

5 Figure 8. Our model so far Now that we have this basic model on our hands, let us start adding other necessary functionalities to our system. 4. File properties The same way our special object {*} can be seen as the representation of property existence, we can think of other properties that our files may have. For instance, on multi-user systems, it is often required that file permissions (read, write and execute) be stored on the file system. To create a new property, we add an object isomorphic to a unary set (same as {*}) and give it a name, such as Read. We now need to identify all files that have this property; for this, we use morphisms. If we want file f to have the Read property, we create a morphism f R from our property-object Read to the history state of f. As we re working under a subcategory of Set, f R is a function defined as f R : Read S i where f R (x) = f, x Є Read ( Read is a unary set). This is illustrated in Figure 9. One thing that should be noticed is that the trash-file should always have all properties. This is due to morphism composition. For instance, if file f is being deleted in the transition between S i and S i+1, it will be collapsed under our trash-file, taking all its properties with it. So, we need a morphism from our property-object (e.g. Read ) to S i+1, representing the composition H i f R. Figure 9. Example of read and write properties: file f is read-only

6 5. Directory hierarchy One important organization feature we are missing is directories. A typical file system contains thousands of files, and directories help organize them by keeping related files together. Directories can also contain other directories inside them, called subdirectories. Together, all directories form a directory hierarchy. But how do we add directories to our model? A directory is not a file, so it should not be in our history-states. However, a directory can be seen as a property. So, to create directories, we create properties (as defined in Section 4) and use morphisms to list its files. Notice that, the same way our trash-file must have all properties, all our directories must contain a trash-file. Now we have directories and files under those directories, but we re still missing a hierarchy between these directories. As always, let us use morphisms for that. If we want directory Paul to be a subdirectory of Users, we create a morphism from object Users to object Paul. That s it! Finally, we will add another special object to this construction, and we will call it the root-directory object. All other directories will be a subdirectory of this rootdirectory. We can easily see that our special object {*} can represent this root directory! Figure 10. Example of directories In Figure 10, we illustrate an example where the users John and Paul each have a directory under the Users directory. Initially, John has file a and Paul has no files. Paul then creates file b (H 0 ), and then John deletes his file a (H 1 ). In green we have some (not all) of the compositions drawn. Notice that our special object {*} still represents existence of all files in our system. Analyzing our definition of directories as properties, we can observe that more than one directory can have an arrow to the same file. This may seem erroneous at first, but this is a known feature of modern file systems, called hard links. A hard link is nothing but a reference, or pointer, to the physical file data. That is, the same data can be associated with multiple names, and this names can even be stored in different locations.

7 6. Directory history The categorical model we are developing is for a versioning file system. Our files already have history mappings, but our directory hierarchy does not. We must then find a way to represent directory creation and deletion in our file system. Since S i and S i+1 represent sets, our history morphism H i represents a function. Now, the states we are trying to relate (directories states D i ) are not sets, but categories. So our directory history morphism will be represented by a functor F i :D i D i+1, i.e., a mapping between categories. The definition of F i must treat two conditions: creation and deletion of directories. Directory creation is trivial, since our state D i will be a subcategory of D i+1. Directory deletion involves collapsing the directory being removed into its parent directory. Figure 11. Directory history Figure 11 illustrates an example of directory history. Directory John is being removed while directory Users is created. In green we show only the relevant mappings of functor F i (morphisms mapping is trivial), and in red we show the only morphism mapping that might be of some trouble. Once again, compositions and identities are omitted for the sake o clarity. 7. Conclusions In this paper we presented a new approach to file system design using category theory, building all concepts from the ground up. Our primary goal was to design a high level model for a versioning file system, where all relevant modifications are stored, ensuring that no valuable data is ever lost. Our final model is well behaved and is a very rich representation: the amount of information contained within is really overwhelming. Observe also that during the course of this paper no assumption is made about the data being stored. So, by using our model as the high-level organization, we can then think

8 about using a very efficient data structure to arrange all data without worrying about file system structure (e.g. directory hierarchy). Other constructions (such as terminal object, product, limit, equaliser and the notion of dual) may also give us more information we may be missing, but that would require some more research. With category theory being the base of this model, it is easy for knowledge from other models to be brought over to ours, most certainly showing us meanings we may have never thought before. References Menezes, PB. and Haeusler, EH. (2001). Category theory for Computer Science (in portuguese), Sagra Luzzato Publishing, second edition. Santry, DJ., Feeley, MJ and Hutchinson, NC. (U. British Columbia and Hewlett- Packard). "Elephant: The File System that Never Forgets."