An Adaptive Version-Controlled File System
Makoto Matsushitay

Tetsuo Yamamotoy

matusita@ics.es.osaka-u.ac.jp

t-yamamt@ics.es.osaka-u.ac.jp

Katsuro Inoueyz
inoue@ics.es.osaka-u.ac.jpyGraduate School of Engineering Science, Osaka University
1-3 Machikaneyama, Toyonaka, Osaka 560-8531, Japanz

Graduate School of Information Science,

Nara Institute of Science and Technology,
8916-5, Takayama, Ikoma, Nara 630-0101, Japan

ABSTRACT
There are many version management systems to identify, record, and track the changes of software products. However, most of these systems require engineers
to learn how to use these tools; if there are some missoperation, version management could be not established.
Some systems employ their proprietary versioning lesystems, and engineers do not need to consider how torecord the changes. However, these changes are stored
in special formats, so portability of the systems cannot
be accomplished.
In this paper, we propose VCFS, a novel version management le system, which automatically record changesof les. We have implemented VCFS as a stackable lesystem, which is easily ported to other systems. We
have also evaluated VCFS with le reading, le writing, compile operations, and le size of repository. As
a result, VCFS provides almost the same performance
as usual le systems, and also it provides the version
control facility.
Keywords
Software Development Environment, Con guration Management, File System
Introduction
Researches on software con guration management haveemerged to solve the diÆculties to identify, organize,
manage software products[2]. Managing products is required in each phase of software development. Elementsof software component should be clearly identi ed andde ned in a design phase.
In a coding phase, products and documents are identi ed, organized, and managed by software con guration management system. There are various researchareas in software con guration management, including
version control system that manages software products.
Generally, a software product needs some modi cations

during coding phase. Each product created by a single change operation is called a \version", and version
control systems treat sequences of the versions.
Many version control frameworks and systems have been
already proposed. Using these systems, reliable changesof products are promised and cooperations with engineers are achieved[1, 3]. However, many version management systems implemented as a set of tools require
engineers to specify when a new product is saved (checkin) as a new version and what version should be takenout (check-out). As a result, engineers should learn
how to use such version management systems, and a
miss-operation causes a repository collapse. Some version management systems introduce automated checkin/check-out facility; however, these systems also employ their own formats for data repository and their
original version control frameworks.
In this paper, we propose a new version management
system named VCFS to solve such problems. This paper is organized as follows. In Section, we describe aboutother version management systems which are alreadyproposed. In Section, we explain VCFS and its implementation. In Section, we show some evaluation resultsof VCFS. Finally, we conclude this work and present
further works in Section.
Related WorkIn this section, we discuss about related works about
version management systems and their problems.
RCS
RCS (Revision Control System) is a set of tools for version management, and already used in many organizations[11].
RCS treats a product as a le in a le system, and does
management activity to les with RCS tools.
In RCS, saving a new version is done by making a di erence between a new version and a previous version. Theversion di erence is shown as a result of UNIX di command. Each version is identi ed as a version number(sequence of numerical value, i.e. \1.2.3"). Extracting
one version is also done by a RCS tool.
Since RCS is implemented as a set of tools, engineers
must learn how to use these RCS tools. In addition,
if an engineer misuses the tools, the registered versions
may be lost.
3D Filesystem
3D Filesystem is implemented as a modi ed le system
of UNIX System V release 3[7]. The le system employs
the same version management model in RCS; a stateof products are de ned as a le itself, and a version
is de ned as a sequence of numerical value. Merging
version management features to native le system makes
a tool-free operation for extracting any version; however,registering a new version requires some supporting toolassociated with the le system.
3D Filesystem makes up for some problems of RCS;
however, the le structure is their original one, so theregistered version information is only extracted via 3D
Filesystem. In addition, 3D Filesystem has only its own
version management model, engineers cannot use otherversion management models.
VMS
The le system in VMS operation system records lechanges automatically. VMS saves all of the contents of
newly saved le, and these saved contents are identi ed
by a special suÆx of lename. The VMS le systemprovides a version management facility; however, otherinformation such as le owner names is not saved.
VCFS
In this section, we will show our new version management system VCFS.
Design Policy
At rst, we specify required features of VCFS to establish better version management mechanisms as follows: Easy operation: engineers are not requested to learn

how to use VCFS at rst; typical operations should
be automatically achieved by VCFS.
 Open structure: VCFS should not have proprietary
structure of data repository.
 Plug-and-play system: VCFS should be independent
from actual version management framework itself; thesystem can be easily con gured also when a new version management framework is emerged.
As a result, VCFS is designed as a stackable le system[5]. A stackable le system does not change the internal
structure of raw le system (UFS (Unix File System),
MSDOSFS (MS-DOS File System), etc), or does notsave the le contents directly to hard disk drive; it saves

User
User
Process

Kernel

User

VFS

VCFS
VCD
Version Management
Sub-System

UNIX File System
(UFS)

RCS

VCS
Control Commands

DISK
retriveprevious
versionsshow
a deltaFigure 1: System overview of VCFS
as a plain le of a lower le system. Operations to thetarget les are automatically recorded via the lower lesystem. VCFS allows to use external version management system; two or more version management systems
can be exists simultaneously. Detailed design is shownin Section.
Overview
In VCFS, operations to a le (read and write) are automatically mapped into activities of version management; engineers do not consider what should be done tomanage the product versions. There are no di erence
between the operations to usual le system and VCFS
le system from a viewpoint of users' processes.
VCFS manages the versions of regular les (symbolic
link, special le, socket, and named-pipe are out of ourscope). A new version is created i a le is created or an
existing le is changed. Checking out the latest version
is done with simply reading the le. VCFS also supports
a le locking mechanism. Before checkin is completed,other process can only checking out the le.
VCFS employs \checkin/checkout model"[4] which was
proposed by RCS, and VCFS itself does not have its
own version management mechanism (sub-system); engineers can import a favorite version management subsystem which is adaptable to the model, i.e., VCFS canuse RCS commands.
System Design
VCFS is composed of le system (VFS), version control
daemon (VCD), version management sub-system, and
VFS control commands. Fig. 1 shows the structure of
the VFS components.
The advantage of the separation of version management
facility from the kernel is that switching check-in/checkout operations can be easily done. In addition, installing
VCFS to a software development organization can beeasily performed if RCS is already employed at the organization. VCFS also allows to work with yet anothercheck-in/check-out style version management system.

foo/header

proj

User
foo,a

foo is foo,aversion header 1

Previous
Version
Offsetversion 1
version header 2versiondb

Previous
Version
Offsetfoo,vLatestVersion
Offsetversion 2

Latestversion header 3version 3

Figure 2: Mapping les between VCFS and actual
le system
Figure 3: De nition of VCS le structure
File System Since VCFS is implemented as a stackablele system, all les handled by VCFS are stored to a raw
le system. Each le via VCFS is consists of two actual
les; one for the latest version, and another for version
repository (Fig. 2).

Table 1: De nition of VCS header
Name
Size
Content
version number 4byte latest version number
latest o set
16byte o set of a latest version

Usually VCFS shows the latest version of the le via
le system. For example, we assume that /versiondb ismounted to /proj by VCFS and create a le /proj/foo.
VCFS creates \/versiondb/foo,a" for the latest versionof le foo (/proj/foo itself) and \/versiondb/foo,v", forthe version repository. Note that /versiondb/foo,v isinvisible via VCFS; it is only for version management
and not for the ordinal operation.

can change the sub-systems to use. Current prototype
of VCFS has two kinds of version management subsystems, RCS and VCS.

a le in read-only mode, VCFS behaves as the sameas NULL le system[10]. When a process opens a lein write-only or read-write mode, VCFS hooks close()system call and performs a check-in operation to a le.
The check-in operation runs by the version control daemon and the daemon calls the version management subsystem which is outside of the kernel.

VCS is a simple version management system as theone of VMS le system. VCS saves all versions as-is,
and does not calculate the delta between versions. No
version derivation is allowed, however, registering a newversion is faster than the RCS sub-system.

RCS keeps only a delta of each version and the latest
version.
RCS allows version derivation (a tree structure
VCFS always keeps the latest version of every le (/verof
versionsequence), and a derived version is called as
siondb/foo,a in the previous example) for fast le read/writeabranch.
RCS sub-system uses RCS tools to record
to the latest version which is modi ed in the most cases
versions.
of software development. When a UNIX process opens

Version Control Daemon VCD is a daemon process
which acts as a bridge between the kernel and the version management sub-system. VCD dispatches the request from the kernel to the version management subsystem.
Version Management Sub-System The version management sub-system is the actual version management partof VCFS. In general, version management sub-system
consists of a set of tools. VCFS employs external version management systems as the sub-systems, and we

Fig. 3, Table 1, and 2 show a le structure, header definition, and version header de nition respectively. The
VCS check-in tool appends the version header and version itself to a version management le (and recalculate the version number and o set of the latest version).
A previous versions can be retrieved by tracing header
o sets. VCS also saves le attributes (ownership, lemodes); checking-out a version restores not only le contents but also le attributes.
VFS Control Commands VFS control commands help
to control VFS behavior. Following commands are al-

Time(Sec.)

Table 2: De nition of VCS version header
Name
Size
Content
attribute
size of vattr vattr structure of astructurele.
previous o set 16byte
o set of a previous
version.

ready available.

9
8
7
6
5
4
3
2
1
1

 Retrieve previous versions

Prototype of VCFS
Current prototype of VCFS runs on FreeBSD 3.0-RELEASE[6], a BSD UNIX[8, 9] variants. VCFS is written in C
and about 5000 lines total; VFS in kernel for 4500 lines,
VCD for 340 lines, and 300 lines for others.
Evaluation
This section discusses the prototype of VCFS from viewpoints of the system performance and storage size. We
take up UFS (actually FFS (Fast File System), a usual
UNIX File System) and NULLFS (loopback le system, implemented as a stackable le system) to compare with our VCFS. Note that all tests are made at
166MHz Pentium PC having 48MB RAM and FreeBSD
3.0-RELEASE.
Performance Evaluation
Read Files At rst, we measured an elapsed time for a
UNIX process to read distinct new les of 1M bytes size
repeatedly. \An elapsed time" means time between process initiation and process termination; be aware that
an elapsed time includes an overhead of typical UNIX
processes (process initialization, etc).
Fig. 4 shows the results of the reading test of VCFS,
UFS, and NULLFS. \VCFS(RCS)" means VCFS using
RCS as the version management sub-system. The vertical axis shows an elapsed time, and the horizontal axis
shows the number of le reading.
The time for VCFS(RCS) is almost the same as one of
NULLFS. With regard to le reading, it is understoodthat it takes almost no extra time as for the version
control functions in the le system. VCFS(RCS) andNULLFS are slower than UFS, since there is an implementation overhead of a stackable le system.

2

3

4

5

6

7

Number of Reading

8

9

10

Figure 4: Read 1M bytes les30
Time(Sec.)

Users can retrieve any one previous version (not thelatest version) by specifying a version number and/or
its created date.
 Make a branch
Branching is done with control commands if the version management sub-system has branching feature.
 Show a delta between versions
Users can check the di erence between versions.

VCFS(RCS)
NULLFSUFS

VCFS(RCS+)VCFS(VCS+)
VCFS(RCS)VCFS(VCS)
NULLFS
UFS

20

10

0
1

2

3

4

5

6

7

Number of Writing

8

9

10

Figure 5: Write 1M bytes lesWrite Files We also measured an elapsed time to writeles, similar to le reading test described before. Fig. 5
shows the results of writing test. \VCFS(VCS)" means
VCFS using VCS as a version management sub-system.
\VCFS(VCS+)" and \VCFS(RCS+)" includes a timeof synchronization between VCD and sub-system. In
general, VCD should not wait the termination of subsystem as usual; however we measured these for comparison purpose.

NULLFS is about 10% slower than UFS, and it is thesame result of reading test. Writing a le in VCFS requires a new version registration which is not requiredby the reading, so VCFS consumes 30% or more timecompared with UFS. Actual time for a new version registration is twice as of UFS, comparing VCFS(RCS+)/ VCFS(VCS+) with UFS. Actually, VCD and subsystem work asynchronously so VCFS is only 30% slower
than UFS, and we assume that it is reasonable.
Fig. 6 shows the same writing test, using a 32K bytes
le instead of a 1M bytes le. The same tendency isshown even if a le size is smaller than the previous
test.

Table 3: Compile an Application (Sec.)
dump tar
VCFS(VCS) 10.96 28.63
VCFS(RCS) 12.79 33.46
NULLFS11.3 32.01
UFS
10.9 28.27

Time(Sec.)3
VCFS(RCS+)VCFS(VCS+)
VCFS(RCS)VCFS(VCS)
NULLFS
UFS

2

1

0
1

2

3

4

5

6

7

8

9

10

Number of Writing

Figure 6: Write 32K bytes bytes les

VCFS(RCS+)VCFS(VCS+)
VCFS(RCS)VCFS(VCS)
NULLFSUFS

10Time(Sec.)

8
6

2
0
1

Compile
times
222
92
110

The procedure of compiling an application does readsource codes and write object codes repeatedly. As aresults, VCFS is about 20% slower than UFS; we thinkthat this overhead is not serious problems for practicalsoftware development environments.

4

0

data1
data2
data3

Table 4: A sample data
All
Files
Versions
LOC
9339
45
311
4067
20
147
2543
18
247

2

3

4

Number of Update

Figure 7: Update 1M bytes lesUpdate Files This test mixes read/write operations toa single le of 1M bytes size. When a process write toa le, the updated le contents are completely di erentof the old one (no same lines), to assure this test is theworst case for RCS. Fig. 7 shows the result of this test.
Note that \0th update" means the rst attempt to write
a le (create a le).

Total time of updating a le is the same of creating ale, except the case of VCFS(RCS); there is a slight
di erence between 0th update and 1st or later update.
Since VCFS(VCS) does not calculate a delta between
versions, it takes a xed time (even if the delta is hugeor not) to update a le if the le size is the same. In
contrast to VCFS(VCS), the more le is updated, themore time is needed in VCFS(RCS).
Compile an Application Finally, we measured a typical
software development procedure, by compiling an application. We pick up two applications, \tar" and \dump"
bundled with FreeBSD. Table 3 shows the result of anelapsed time for executing \make" programs of those
applications.

File Size Evaluation
We applied a sample data taken from a programming
seminar of Osaka University (Table 4), and measures
the total le size saved into a lesystem. The test creates/updates les, and then compile them. Table 3
shows the result.
The result of UFS shows the size of nal product version. The result of VCFS shows that more le size isrequired to save the whole data, VCFS(RCS) requires
several times as much as UFS, and VCFS(VCS) requires
ten times as much as UFS. The le size may vary; it depends on what sub-system is used with VCFS.
Discussion
Totally, VCFS is about 20% slower than UFS; however,
we consider there is acceptable for practical use. Using
VCFS with RCS sub-system, disk usage is reasonably
small.
Following is the summary of VCFS and other version
management system.
 RCS and VCFS(RCS)

Table 5: Total le size (K bytes)
UFS VCFS(RCS) VCFS(VCS)
data1 225
1388
3149
data2 117
546
1377
data3 73
604
1501

RCS consists of a set of tools, and VCFS(RCS) is ale system wrapper for RCS. In general, both systems
have almost the same functionality; however, VCFS
does not force to engineers to learn how to use RCS
tools.
 3D Filesystem and VCFS(RCS)
Both systems are implemented as a le system andprovide a version management facility. VCFS(RCS)
employs existing UFS le system and existing RCS
data structure; however, 3D Filesystem is their own
data structure, and requires check-in procedure explicitly.
Conclusion
In this paper, we show the problems of existing version
management system. We also propose a new version
management system VCFS; VCFS acts like a le systemwrapper for existing version management system. We
also evaluate VCFS in performance and le-size point ofview. VCFS provides easy operation of version management, open system structure, and plug-and-play capability of selecting external version management system.
As a further work, version management of directory or
special les are planned. Also, supporting distributed
software development environment and more usability
evaluation are required to VCFS. We are now working
on Web-based VCFS tools which overrides VFS control commands, to support graphical and understandable representation of version history.
REFERENCES
1. Babich, W. A.: Software Con guration Management , Addison-Wesley, Reading, Massachusetts(1986).
2. Conradi, R. and Westfechtel, B.: Version Models for Software Con guration Management, ACM
Computing Surveys , Vol. 30, No. 2, pp. 232{280(1998).
3. Estublier, J. and Casallas, R.: The Adele Conguration Manager, Con guration Management(Tichy, W.(ed.)), John Wiley and Sons, Ltd.,BaÆns Lane, Chichester, West Sussex PO19 1UD,
England, pp. 99{133 (1994).
4. Feiler, P. H.: Con guration Management Models in Commercial Environments, Technical Report CMU/SEI-91-TR-7, Software Engineering Institute, Carnegie-Mellon University, Pittsburgh,
Pennsylvania 15213 (1991).
5. Heidemann, J. and Popek, G.: File-System Development with Stackable Layers, ACM Transactions
on Computer Systems , Vol. 12, No. 1, pp. 58{89(1994).
6. Hubbard, J. K.: RELEASE NOTES FreeBSD
Release 3.0-RELEASE. This document is avail-able on the World-Wide Web at the URL\http://www.freebsd.org/releases/3.0R/notes.html".
7. Korn, D. G. and Krell, E.: A New Dimension for
the Unix File System, Software{Practice and Experience , Vol. 20, No. S1, pp. 19{34 (1990).
8. Leer, S., McKusick, M., karels, M. and Quarterman, J.: The Design and Implementation of the
4.3BSD UNIX Operating System , Addison-Wesley(1989).
9. McKusick, M., Bostic, K., karels, M. and Quarterman, J.: The Design and Implementation of the
4.4BSD UNIX Operating System , Addison-Wesley(1996).
10. Pendry, J.-S. and McKusick, M.: Union Mounts
in 4.4BSD-Lite, Proceedings of the USENIX 1995
Technical Conference , New Orleans, LA, USA, pp.
25{33 (1995).
11. Tichy, W. F.: RCS { A System for Version Control,
Software{Practice and Experience , Vol. 15, No. 7,
pp. 637{654 (1985).