Replication for Mobile Computing Prasun Dewan Department of Computer Science University of North Carolina

Slides:



Advertisements
Similar presentations
Eventual Consistency Jinyang. Sequential consistency Sequential consistency properties: –Latest read must see latest write Handles caching –All writes.
Advertisements

Automating Hoarding Prasun Dewan Department of Computer Science University of North Carolina
Computer Science Lecture 20, page 1 CS677: Distributed OS Today: Coda, xFS Case Study: Coda File System Brief overview of other recent file systems –xFS.
File System for Mobile Computing Quick overview of AFS identify the issues for file system design in wireless and mobile environments Design Options for.
Overview of Mobile Computing (3): File System. File System for Mobile Computing Issues for file system design in wireless and mobile environments Design.
G Robert Grimm New York University Disconnected Operation in the Coda File System.
Disconnected Operation in the Coda File System James J. Kistler and M. Satyanarayanan Carnegie Mellon University Presented by Deepak Mehtani.
Disconnected Operation in the Coda File System James J. Kistler and M. Satyanarayanan Carnegie Mellon University Presented by Cong.
Distributed Systems 2006 Styles of Client/Server Computing.
Computer Science Lecture 16, page 1 CS677: Distributed OS Last Class: Web Caching Use web caching as an illustrative example Distribution protocols –Invalidate.
Coda file system: Disconnected operation By Wallis Chau May 7, 2003.
“Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System ” Distributed Systems Κωνσταντακοπούλου Τζένη.
Computer Science Lecture 21, page 1 CS677: Distributed OS Today: Coda, xFS Case Study: Coda File System Brief overview of other recent file systems –xFS.
Department of Electrical Engineering
Toolkits for Building Mobile Systems 3/28/2002 Michael Ferguson
Disconnected Operation In The Coda File System James J Kistler & M Satyanarayanan Carnegie Mellon University Presented By Prashanth L Anmol N M Yulong.
G Robert Grimm New York University Bayou: A Weakly Connected Replicated Storage System.
Jeff Chheng Jun Du.  Distributed file system  Designed for scalability, security, and high availability  Descendant of version 2 of Andrew File System.
Database Administration Part 1 Chapter Six CSCI260 Database Applications.
Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System D. B. Terry, M. M. Theimer, K. Petersen, A. J. Demers, M. J. Spreitzer.
Mobility Presented by: Mohamed Elhawary. Mobility Distributed file systems increase availability Remote failures may cause serious troubles Server replication.
Client-Server Computing in Mobile Environments
Sun NFS Distributed File System Presentation by Jeff Graham and David Larsen.
Adaptation for Mobile Data Access (DM1 & PL1) Yerang Hur Mar. 24, 1998.
Update Propagation with Variable Connectivity Prasun Dewan Department of Computer Science University of North Carolina
Distributed Systems Principles and Paradigms Chapter 10 Distributed File Systems 01 Introduction 02 Communication 03 Processes 04 Naming 05 Synchronization.
Mobility in Distributed Computing With Special Emphasis on Data Mobility.
CS Storage Systems Lecture 14 Consistency and Availability Tradeoffs.
Feb 7, 2001CSCI {4,6}900: Ubiquitous Computing1 Announcements Tomorrow’s class is officially cancelled. If you need someone to go over the reference implementation.
By Lecturer / Aisha Dawood 1.  You can control the number of dispatcher processes in the instance. Unlike the number of shared servers, the number of.
Designing a global repository using OceanStore Steven Czerwinski, Anthony Joseph, John Kubiatowicz Summer Retreat June 11, 2002 UC Berkeley.
Distributed File Systems Case Studies: Sprite Coda.
Object-Oriented Analysis & Design Subversion. Contents  Configuration management  The repository  Versioning  Tags  Branches  Subversion 2.
Chapter 10: File-System Interface Silberschatz, Galvin and Gagne ©2005 Operating System Concepts – 7 th Edition, Jan 1, 2005 Chapter 10: File-System.
Overview – Chapter 11 SQL 710 Overview of Replication
Replication and Consistency (3). Reference r Automated Hoarding for Mobile Computers by G. Kuenning and G. Popek.
Introduction to DFS. Distributed File Systems A file system whose clients, servers and storage devices are dispersed among the machines of a distributed.
Feb 27, 2001CSCI {4,6}900: Ubiquitous Computing1 Announcements.
DISCONNECTED OPERATION IN THE CODA FILE SYSTEM J. J. Kistler M. Sataynarayanan Carnegie-Mellon University.
CODA: A HIGHLY AVAILABLE FILE SYSTEM FOR A DISTRIBUTED WORKSTATION ENVIRONMENT M. Satyanarayanan, J. J. Kistler, P. Kumar, M. E. Okasaki, E. H. Siegel,
Mobile File System Byung Chul Tak. AFS  Andrew File System Distributed computing environment developed at CMU provides transparent access to remote shared.
Mobile Data Access1 Replication, Caching, Prefetching and Hoarding for Mobile Computing.
Computer Science Lecture 19, page 1 CS677: Distributed OS Last Class: Fault tolerance Reliable communication –One-one communication –One-many communication.
CS425 / CSE424 / ECE428 — Distributed Systems — Fall 2011 Some material derived from slides by Prashant Shenoy (Umass) & courses.washington.edu/css434/students/Coda.ppt.
Distributed File Systems
1 Multiversion Reconciliation for Mobile Databases Shirish Hemanath Phatak & B.R.Badrinath Presented By Presented By Md. Abdur Rahman Md. Abdur Rahman.
Information/File Access and Sharing Coda: A Case Study J. Kistler, M. Satyanarayanan. Disconnected operation in the Coda File System. ACM Transaction on.
Caching Consistency and Concurrency Control Contact: Dingshan He
GLOBAL EDGE SOFTWERE LTD1 R EMOTE F ILE S HARING - Ardhanareesh Aradhyamath.
An Architecture for Mobile Databases By Vishal Desai.
Outline for Today’s Lecture Administrative: Objective: –Disconnection in file systems –Energy management.
20 Copyright © 2008, Oracle. All rights reserved. Cache Management.
Consistency Guarantees Prasun Dewan Department of Computer Science University of North Carolina
Eventual Consistency Jinyang. Review: Sequential consistency Sequential consistency properties: –All read/write ops follow some total ordering –Read must.
Highly Available Services and Transactions with Replicated Data Jason Lenthe.
Computer Science Lecture 19, page 1 CS677: Distributed OS Last class: Distributed File Systems Issues in distributed file systems Sun’s Network File System.
THE EVOLUTION OF CODA M. Satyanarayanan Carnegie-Mellon University.
Computer Science Lecture 19, page 1 CS677: Distributed OS Last Class: Fault tolerance Reliable communication –One-one communication –One-many communication.
Mobility Victoria Krafft CS /25/05. General Idea People and their machines move around Machines want to share data Networks and machines fail Network.
Mobile File Systems.
Coda / AFS Thomas Brown Albert Ng.
Nomadic File Systems Uri Moszkowicz 05/02/02.
Disconnected Operation in the Coda File System
Presented By Abhishek Khaitan Adhip Joshi
Today: Coda, xFS Case Study: Coda File System
Outline Announcements Lab2 Distributed File Systems 1/17/2019 COP5611.
Today: Distributed File Systems
Outline Review of Quiz #1 Distributed File Systems 4/20/2019 COP5611.
Gold Rush : Mobile Transaction Middleware with JAVA Object Replication
System-Level Support CIS 640.
Presentation transcript:

Replication for Mobile Computing Prasun Dewan Department of Computer Science University of North Carolina

2 Mobile Data Physical Location? n Address Book n Documents n Spreadsheets n Drawings n Maps n Programs Logical link

3 Physical Location Network Local Client Remote Server

4 Client vs. Remote n Local Client u No network cost F latency F $$$ u Availability F Disconnection is default F Involuntary out of range power outage F Voluntary preserve battery saving money n Remote Server u Larger Data Size u More Secure & Robust u Sharing possible

5 Coda Solution: Hybrid Scheme Network Local Client Remote Server While connected, remote server “cache” While disconnected local client

6 Caching vs. Hoarding n Classic caching u Uncached data always available but with higher cost u Caching for future performance u Filled on demand u Stale data purged u Writes to cache committed immediately n Hoarding u Uncached data unavailable when disconnected u Caching for future performance & availability F partial replication u Filled on demand/pre-fetched u Stale data sometimes better than no data u Writes to cache committed later on reconnection F tracking changes F conflict detection F conflict resolution

7 State Transition Diagram Emulation Provide access to cached, possibly stale data Track changes to cached data (delayed commit) Disconnection Merging Detect conflicts Resolve conflicts Physical Reconnection Logical Reconnection Hoarding Cache data Write through (immediate commit)

8 Cache replacement/filling n Classic cache filling/replacement u granularity = disk block/cache line u priority = f ( recent usage) u filled on access n Coda cache filling/replacement u granularity F whole file remote disk address meaningless system-determined prefetching F ancestor directories path name resolution u priority = f (recent usage, user- specified) F user-determined prefetching u filled on access, user-request, and periodically

9 User-Determined Prefetching Per user, per workstation hoard profiles, specifying u Files to be added or deleted u Current and future (+) F children (c) F or descendents(d) u Priority a /coda/usr/jjk d+ a /coda/usr/jjk/papers 100:d+ Personal Files a /usr/X11/bin/xterm a /usr/X11/bin/xinit Executables Source Files a /coda/src/venus 100:c+ a /coda/include 100:c+ Expanded during name-binding phase

10 Two-phase Hoard Walk n Phase 1: Reevaluate name bindings u new children matching user-specifications may have been created by other clients. n Phase 2: Recalculate priorities, evict and fetch if necessary u no un cached object higher priority than cached objects

11 Emulation n Log changes to files u mkdir d1,write f1, …. n Compress logs u (mkdir d, rmdir d, write f, write f) write f n Level of write logging? u write f, contents F No need to store open and close F File updates not interleaved u write f, atOffset, buffer F More efficient n Compression advantages u some traces only 20% u others % u variability because of hot files?

12 Merging n Problem because of concurrent conflicting modifications u Cached and server data may be modified simultaneously. n Find and resolve conflicts n Concurrent directory changes resolved automatically n Not so for files

13 Directory Merging (from LOCUS) n Operations u add(d, e) u del(d, e) u mod(d, attr, val ) u Link n Conficts u Client: add(d, e), uncached e existed on server at hoard time or server did added e to d subsequently u Client: mod(a1, v1), Server: mod(a2, v2) u Client: changed d; Server: deleted d F Or vice versa

14 False Conflict Example mv d1/e1 d2/e2 touch d1/e1 link (d1/e1, d2/e2) del(d1, e1) write (d1/e1) conflict

15 File Merging n Harder problem because file is unstructured from OS point of view n Let application program that understands file structure and semantics detect and resolve conflicts u Drawing program allows concurrent additions like directory u Calendar program allows reservations at different times. n Or let user resolve conflicts u User makes different reservation n System simply calls application program

16 Issues raised by Coda n Considers strong connection and disconnection u weak connection? hoarding, emulation, or something else? n Client to server merging u client to client? n User-determined pre-fetching of files u System-determined u Application determined? n Merging depends on physical rather than logical connection. u Sometimes user wants separate version to keep changes private. u User-defined transactions!

17 Issues raised by Coda n Automatic directory merging u Synchronization guarantees a la serializability? u Inflexible resolution F May want both server and client to delete for delete to succeed (user cleaning up local hoard) n Manual (Application or end-user) file merging u Automatic (with guarantees)? n Directory and file hoarding and merging u Smaller grain than file. u Non persistent data n What if changes rejected. u Cascaded rollbacks

18 Issues raised by Coda n Client to server merging u client to client? Anti-Entropy Epidemic Algorithms u News, Lotus Notes, Bayou, TACT u Clients do pair-wise merging u Eventually consistency u Problem of write order since no single arbitrator F In host priority order

19 One- vs Two-level P2P Architectures Lotus Notes client server merging client News, Grapevine, Bayou client

20 One- vs Two- Level C2S Architectures Sync server merging client Coda server client

21 Issues raised by Coda n What if changes rejected. u Cascaded rollbacks n Bayou u Uncommitted writes are tentative u System keeps track of tentatively written objects. u Application can display this to user

22 Issues raised by Coda n Merging depends on physical rather than logical connection. u Sometimes user wants separate version to keep changes private. Rover u Application explicitly imports (caches) and exports (merges) objects. u Merge-aware application.

23 Issues raised by Coda User-determined pre-fetching of files u System-defined u Application-defined

24 Issues raised by Coda User-determined pre-fetching of files u System-determined u Detection of file working sets. F Look at past behavior. F Trace data. What executables forked. What files accessed. F If current behavior looks like past behavior, cache data. F Metric for similarity. u Look at semantic distance between files. User-determined pre-fetching of files u System-defined u Application-defined