• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
Download
 
Appeared in the Proceedings of theSummer USENIX Conference,June 1994, pages 183-195
Resolving File Conflicts in the Ficus File System
 
Peter Reiher, John Heidemann, David Ratner, Greg Skinner, Gerald Popek  Department of Computer ScienceUniversity of California, Los Angeles
Abstract
Ficus is a flexible replication facility with optimisticconcurrency control designed to span a wide rangeof scales and network environments. Optimistic con-currency control provides rapid local access and highavailabilityof files forupdate in the face of disconnec-tion, at the cost of occasional conflicts that are onlydiscovered when the system is reconnected. Ficus re-liably detects all possible conflicts. Many conflictscan be automatically resolved by recognizing the filetype and understanding the file’s semantics. This pa-per describes experiences withconflicts and automaticconflict resolutionin Ficus. It presents data on the fre-quency and character of conflicts in our environment.This paper also describes how semantically knowl-edgeable resolvers are designed and implemented, anddiscusses ourexperiences withtheirstrengths and lim-itations. We conclude from our experience that opti-mistic concurrency works well in at least one realisticenvironment, conflicts are rare, and a large proportionof those conflicts that do occur can be automaticallysolved without human intervention.
1 Introduction
The value of file replication is widely recognized, butreplicationofupdatablefilesleads immediatelytocon-sistency problems. File replicas can be partitionedfrom each other for a variety of reasons, ranging fromfailures of machines and networks to intentionally in-termittentconnections(e.g., connectionviamodem, orreplicas on portable machines that are not always at-tached to a network). If no efforts are taken, partition-
 
This work was sponsored by the Defense Advanced ResearchProjects Agency under contract N00174-91-C-0107. Gerald Popek is also affiliated with Locus Computing Corporation.The authors canbe reachedat 4760Boelter Hall, UCLA, Los An-geles,CA,90024,orbyelectronicmailto
ficus@cs.ucla.edu
.
ing can permit conflicting updates to different replicasof a file. Much of the value of replication is based onall replicas being identical, so inconsistent updates area potentiallyserious problem.Earlysolutionstotheproblemreliedonvariouscon-servativealgorithmsthat preventedconflictingupdatesto different replicas [1]. These solutions used a widevarietyofmechanisms, but theircommon theme isthattheyrefuseupdatesthat haveanypossibilityofcausingconflicting updates. These solutions trade availabilityfor consistency. When consistency of replicas is of vi-tal importance, conservative solutionsare preferable.However,experiencewithfileaccessbytypicalusershas shownthat many filesare onlyaccessed bya singleuser [10]. Of those that are shared by multiple users,few are updated by more than one user. In such en-vironments, a mechanism that prevents one user fromupdatinga file in favor of preservingthe update abilityofotheruserswhomightnevergenerateanupdateisse-riously flawed. Conservative replication mechanismsexhibit this flaw.Optimisticreplication mechanisms do not. They al-low any replica of a file to be updated at any time.This choice ensures that users who need to update afile can do so when any replica is available. However,optimistic mechanisms gain this availability by trad-ing off consistency. Since any replica can be updated,two non-communicating replicas can be changed in-dependently, leading to
conflicts
, i.e., different replicacontents. To maintain consistency, a system with op-timistic replication must detect and recover from suchconflicts.The improved availability of optimistic systemsmust be weighed against the frequency and cost of re-covering from conflicts. A hypothesis of this paper isthat thecost ofoptimismislowinmany environments.To test this hypothesis, this paper reports conflictresolution experiences with Ficus, an optimistic filesystem developed at UCLA [4]. Ficus has supported
 
Appeared in the Proceedings of theSummer USENIX Conference,June 1994, pages 183-195
the primary computing needs of over a dozen users atUCLA for more than three years.Ficus has a general architecture for dealing with fileconflicts. Conflicts are automatically detected and ex-amined to determine if they can also be resolved au-tomatically. Special programs called
resolvers
handleconflicts that can be dealt with automatically.Ficus is able to resolve almost all conflicts for a par-ticularly important class of files—directories. Ficussupports a Unix-style directory system; the semanticsof Unix directories provide that almost every conflictthat can occur in them can be automatically resolved.Directory conflicts could be resolved by submittingthem to a resolver that implements the algorithms nec-essary to resolve their conflicts, but the integrityof theUnix file system is so closely linked to its directoriesthat we have chosen to put the algorithms into Ficusitself.We have instrumented the Ficus system to keeptrack of the number of conflicts generated and howmany conflicts were resolved automatically. This pa-per presents the statistics gathered, which support thecontentionthat,forimportantpatternsofusage, thefre-quency of file conflicts is low enough that optimisticreplication is highly attractive. Further, the statisticsdemonstrate that the use of automatic resolvers is bothpractical and important to reduce the number of con-flicts reported to users.The next section presents an overview of the Ficusfile system. We begin there with an example of howa conflict can arise in an optimisticreplicationsystem,discuss the different kinds of conflicts that can arise,briefly describe how conflicts are detected, and coverother relevant aspects of Ficus. Section 3 describesthe Ficus resolution architecture. It discusses the au-tomated directory conflict resolution mechanisms inFicus and describes how Ficus handles other types of conflicts. Section 4 discusses Ficus conflict resolverprograms. It covers their interface and the various ap-proaches used to resolve conflicts for different typesof files. Section 5 presents conflict data gathered fromFicus; Section 6 discusses some related research. Weclose with a discussion of future work and some con-clusions.
2 Ficus Overview
Ficus is a distributed file system utilizing optimisticreplication[16, 4]. The default synchronizationpolicyprovides
single copy availability
; so long as any copyof a data item is accessible, it may be updated. Oncea single replica has been updated, the system makes abest effort to notify all accessible replicas that a newversionofthefileexistsviaupdate propagation. Thosereplicas then pull over the new data. Ficus guarantees
no lost update
semantics despite this optimistic con-currency control. Conflicting updates are guaranteedto be detected, allowing recovery after the fact.Ficus groups subtrees of files into
volumes
. A vol-ume can be replicated multiple times. A backgroundprocess knownas
reconciliation
runsonbehalf ofeachvolume replica after each reboot and periodically dur-ingnormal operation. It compares all files and directo-riesofthelocal volumereplicawitha remotereplicaof the volume, pullingover missed updates and detectingconcurrent update conflicts.Severaltypesofconflictsarepossible. Theyinclude:
 
Update/update conflicts
 
Name conflicts
 
Remove/update conflictsTheremainderofthissectionwilldiscussthesetypesof conflicts in more detail. The next section describeshow we manage these conflicts.Since single copy availabilitypermits any replica tobe updated, even a simple partitioningof a two-replicafile can result in a conflict. Figure 1 illustrates thissituation. File foo has two replicas in Figure 1a, withreplica 1 at site A and replica 2 at site B. If sites Aand B are partitioned, as Figure 1b shows, updates toboth replicas are accepted. Then, when the partitionis merged, as shown in figure 1c, file foo exists in twoversions. This is an
update/updateconflict 
.Directories provide a special case of update/updateconflicts. Partitioned creation of independent files inthe same directory would ordinarily result in an up-date/update conflict on that directory. Since directo-ries are internal to the file system, Ficus automaticallyresolves this sort of concurrent update, producing theunion of all directory changes. (See [6] for a descrip-tion of the algorithms employed in directory manage-ment.) A problem occurs when two files are indepen-dently created with the same name; Unix requires thateach directory entry be unique. We term is kind of directory update/update conflict a
name conflict 
.Figure2illustratesadifferentkindofconflict. Infig-ure2a, wesee tworeplicasoffilefoobeforeapartition.In 2b, file foo is removed at site B (indicated by theshading of site B’s replica), while the partitioned rep-lica at site A is updated. When the partitionmerges, asshown in 2c, if no update had occurred, then the otherreplica should simply be removed. However, if theupdated replica is removed in thissituation,the updategenerated during the partitionis lost, possibly withoutthe knowledge of the person making the update. Fi-cus’“nolostupdatesemantics” requiresthattheupdategenerated at site A not be discarded as a result of the
 
Appeared in the Proceedings of theSummer USENIX Conference,June 1994, pages 183-195
FooReplica 1FooReplica 1FooReplica 1FooReplica 2FooReplica 2FooReplica 2
Site ASite B
PartitionUpdatexUpdateyFig. 1a − Before partitionFig. 1b − During partitionFig. 1c − After partitionConflict
Figure 1: An update/update conflict.removal of the file at site B. This kind of conflict iscalled a
remove/update conflict 
.If a file is independently deleted from two replicasof a partitioneddirectory, Ficus does not loga conflict.This delete/delete situation is not a problem, providedany other replicas of the file are also deleted when thepartitions merge, since both deletions have preciselythe same effect.Ficusmakes a “best-effort” attempt topropagateup-dates as they occur. However, even when no partition-ings or other machine failures happen, update propa-gationisnot guaranteed. Thus, conflictingupdatescanarise even without machine or network failures. Also,Ficus does not lock replicas for update even within apartition, so two replicas can accept simultaneous up-dates toa file that couldresult ina conflict. Inpractice,the update propagation mechanism is fast and reliableenoughthatconflictsunrelatedtoactual failuresorpar-titioningalmost never occur.Ficus detects all types of conflicts using a mecha-nism known as a
version vector 
[14]. Each file replicamaintainsitsownversionvectorthat keeps trackofthehistory of updates to the file. Conflicts are detectedby comparing version vectors from two file replicas.Version vectors reliably detect all file conflicts that in-volve replicas of a single file. They do not assist inensuring the consistency of updates that span multiplefiles. Other mechanisms (not supported in Ficus, norin most file systems) are required to do so.
3 Ficus Conflict Resolution Architecture
Several types of conflicts are possible in Ficus. Be-cause of the importance of the integrity of directo-ries, directory conflicts receive special handling. Re-move/update conflicts also require some special treat-ment. Update/update conflicts on non-directory filesare the most common case. The followingsubsectionsdiscuss each type of conflict and its handling in moredetail.
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...