1. Data Sharing in OSD Environment Dingshan He September 30, 2002.

2. Motivation & Issues OSD claims improved device & data sharing across platforms How does OSD facilitate data sharing? How to define data consistency semantics in the OSD environment? How to achieve data sharing following the defined data consistency semantics?

3. OSD Environment Network OSD Client replications of the same object Manager object access OPEN/CLOSE READ/WRITE MANAGEMENT

4. Region Concept There is a Region Manager represents the region RM’s communicate in the P2P manner OSD Client OSD Manager Region Network region boundaryP2P communication

5. Local Copy vs. Remote Copy From a single client’s point of view –Local copy: copy within the same region –Remote copy: copy within another region However, a client is unaware of whether the copy is local or remote A client always sends OPEN request to its regional manager, using a unique object id as parameter. The regional manager figures out where to find a nearby copy (either local or remote)

6. Primary/Secondary Copies Differentiate the importance of copies of the same object Facilitate concurrency control Open Question: –Is the role of primary copy static or dynamic?

7. Concurrency Control Multiple clients may simultaneously READ/WRITE the same object on a single OSD device, or multiple OSD devices Design Choices –Locking –Resynchronization

8. Locking Locking for one replication of an object could be performed at the regional manager of the OSD containing this replication Locking for different replications (stored on different OSD devices) of the same object –Either centralized by using a single manager –Or distributed by exchange information among managers

9. Locking Pros : –Applicable to any objects –Strong consistency Cons: –Slow response due to locking overhead –Potential deadlock –Increasing network traffic –Low availability with weak connectivity

10. Resynchronization Dealing with multiple clients simultaneously READ/WRITE different replications (on different OSD devices) of the same object Requirement: The resynchronization behavior of the object should be well defined and deterministic

11. Resynchronization Pros: –Quick response –Less network traffic –Higher availability –Suitable for weak connectivity environment Cons: –Not necessarily applicable to all kinds of objects –Weak consistency

12. Comments We are dealing with both strong connectivity and weak connectivity (such as mobile computing) environment Resynchronization is necessary We still want to achieve as much consistency as possible, so we can’t only rely on resynchronization

13. Conclusion Resynchronization and server locking should be both used Server locking is used to achieve as much consistency as possible Resynchronization is used to handle network partition condition, where complete consistency is just impossible, unless response time could be infinitely sacrificed

14. Levels of consistency Strong consistency: using server locking whenever object is accessed Weak consistency: using resynchronization Medium consistency: using both server locking and resynchronization

15. Object Support Object should have a way to indicate its desired consistency level For resynchronization, object should have its particular synchronization method, which will deterministically synchronize inconsistent replications of the same object

16. Caching Necessary!! Possible caching locations –Client –Manager Caching (temporary)  Replication (relatively permanent)

17. Caching Consistency Strong –Using revalidation –High latency Weak –Works like web caching –Potential inconsistency

18. Caching Granularity Big object Partial access Object could provide support by specifying the way to decompose itself –Example: a relational table object could decompose itself by rows.

19. Summary Object access in OSD environment Region concept Locking Resynchronization Caching