150 likes | 246 Vues
Explore the integration of Distributed File System (DFS) with Consumer Electronic Devices (CEDs), leveraging the EnsemBlue system for managing personal digital data effectively. Learn about Persistent Queries and Disconnected Operation for mobile devices.
E N D
EnsemBlue: Integrating Distributed Storage and Consumer Electronics (edited slides)
Consumer Electronic Devices (CEDs) • Personal digital data • Explosion • Very different goals than: • GFS, Palimpsest, xFS, OceanStore • Differences? • Palimpsest – no human • GFS – large writes • xFS – GP, but similarities • OceanStore – everyones data
Why are CEDs different from general purpose machines? • Narrowness of interface • Degree of specialization • Computationally weak Why is it complex to manage personal digital data? • Unique data formats • Data organization schemes • Limited computing resources • Consistency • Number of files, incl. replicas • Manual movement of data
Distributed Storage Solutions • DFS can help manage CEDs and multimedia My data • Based on BlueFS: • Single namespace • Supports mobile clients • Designed for small group of users • BlueFS + Ensemble = EnsemBlue • Persistent queries • Explicit support for closed-platform CED’s • Local data exchange • Disconnected operation
Integrating CEDs: Leveraging general-purpose computers Distributed File System DFS protocol DFS protocol DFS protocol General-purpose client Device-specific protocol
The EnsemBlue Daemon: Wolverine EnsemBlue DFS Modification of data in DFS namespace Detect modifications Update modifications Modification of data in CED namespace Wolverine Auth. copies • Runs on the general-purpose client • Acts on behalf of CED for all EnsemBlueactivities • Holds receipts for all objects on device; server callbacks
Integrating CEDs (receipts) • One-to-one mapping : Namespace diversity Mapping Fully-qualified pathname of file in local CED namespace: /iPod/Songs/LetItBe.mp3 Unique EnsemBlue Identifier Object 1.999.18A • “Like” a symbolic link • File-system independent
Persistent Queries • Event-notification mechanism • Reuse existing cache consistency of DFS: • Persistent query = file system object • Event notification = modification to DFS objects • Functional examples: • Transcoder (m4a => mp3) • Type-specific affinity (all jpegs => specific directory)
Persistent Queries : Example (M4A to MP3 Transcoder) File Server Sets callback with the file server Client adds a new M4A file pq_ create (..) Append event record to query Application (transcodes M4A music to MP3 format) M4A Player Creates corresponding MP3 file MP3 Player
More on Persistent Queries • Client-side Evaluation: Adv. to server side? • Better computational resource • Close-to-data computation (primary replicas lie on Server) • Persistent query issues • Garbage collect old queries • Overhead
Disconnected devices • CEDs are often disconnected • P2P => mobility • central server => safety, consistency • Ensembles • middle-ground between P2P systems and centralized file servers • collection of devices sharing a common “view” of file system
Ensembles • Ensembles store “cache” of file objects • Pseudo file server – ‘Castellan’ • Maintains a replica list of cache contents of all devices in the ensemble • Consistency of data, update propagation
Ensemble : Operation Examine replica list Castellan Update replica list RPC(to fetch data) Hit: services the request Miss: sends an error code Fetches the object Client 1
Conclusion • Focus on storage: CED’s integrated with DFS • User-specific “views” of FS – Ensembles • Namespace diversity • Persistent queries, disconnected operation on mobile devices
Discussion • Why is consistency actually an issue? • write once, read many? • personal data: human-access, eventual consistency probably ok • Castellan is a GP computer and devices are disconnected … why isn’t Castellan connected? • How does CED invoke to Castellan • Battery power? • Other thoughts? RPC(to fetch data)