Скачать презентацию Advanced Operating Systems Lecture notes http gost isi Скачать презентацию Advanced Operating Systems Lecture notes http gost isi

4348703c40ef2a8aab698538f9739ba0.ppt

  • Количество слайдов: 91

Advanced Operating Systems Lecture notes http: //gost. isi. edu/555 Dr. Clifford Neuman University of Advanced Operating Systems Lecture notes http: //gost. isi. edu/555 Dr. Clifford Neuman University of Southern California Information Sciences Institute Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Announcements v. Mid-term exam Friday October 19 th q 2 PM-4 PM, location GFS Announcements v. Mid-term exam Friday October 19 th q 2 PM-4 PM, location GFS 106 q Open Book, Open Note, No Electronics q No lecture following. v. Dr. Neuman’s Office hours q October 12 – no office hours Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

CSci 555: Advanced Operating Systems Lecture 7 – October 12, 2007 Virtualization, File Systems CSci 555: Advanced Operating Systems Lecture 7 – October 12, 2007 Virtualization, File Systems Dr. Clifford Neuman University of Southern California Information Sciences Institute Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

COVERED LAST LECTURE Hardware Requirements for Trusted Computing v. How do we know what COVERED LAST LECTURE Hardware Requirements for Trusted Computing v. How do we know what software is running? q Exercise: Suppose a virus infected our application. q Suppose we were running a hacked kernel. q Suppose we were running in a virtual machine. q Suppose someone replaced our hardware with something similar, but with special operations. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

COVERED LAST LECTURE A basis step for trust v. The Hardware must be secure. COVERED LAST LECTURE A basis step for trust v. The Hardware must be secure. q And it must be able to prove that it has not been modified or replaced. q This requires special keys accessible only to the hardware. q It requires tamper resistance that destroys the key if someone tries to open the chip. q (we also need validation of the hardware implementation) Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

But this is an OS class v. The OS must be secure q And But this is an OS class v. The OS must be secure q And it must be able to prove that it has not been modified or replaced. q This requires special keys accessible to OS. § These keys are provided when booted. § They are bound to a checksum. § They may be managed in hardware or by the OS itself. q What does this protect against? Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

What does the OS do v. The OS must perform special functions q Must What does the OS do v. The OS must perform special functions q Must provide certified keys for the applications (as the HW did for the OS). q The OS must protect itself, and its own keys – so that malware or other users can not act as the OS. q The OS must protect process from one another. Some functions may require stronger separation than typically provided today. q The Trusted Applications themselves must similarly application specific protections to the data they manipulate. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

This helps to contain breaches v. But it doesn’t prevent breaches. q A buggy This helps to contain breaches v. But it doesn’t prevent breaches. q A buggy OS can still be compromised. q Bugs in applications still leave vulnerabilities. q But one can at least be more sure about what version of software one is communicating with. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Virtualization v. Operating Systems are all about virtualization q One of the most important Virtualization v. Operating Systems are all about virtualization q One of the most important function of a modern operating system is managing virtual address spaces. q But most operating systems do this for applications, not for other OSs. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Virtualization of the OS v. Some have said that all problems in computer science Virtualization of the OS v. Some have said that all problems in computer science can be handled by adding a later of indirection. q Others have described solutions as reducing the problem to a previously unsolved problem. v. Virtualization of OS’s does both. q It provides a useful abstraction for running guest OS’s. q But the guest OS’s have the same problems as if they were running natively. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

What is the benefit of virtualization v. Management q You can running many more What is the benefit of virtualization v. Management q You can running many more “machines” and create new ones in an automated manner. q This is useful for server farms. v. Separation q “Separate” machines provide a fairly strong, though coarse grained level of protection. q Because the isolation can be configured to be almost total, there are fewer special cases or management interfaces to get wrong. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

What makes virtualization hard v. Operating systems are usually written to assume that they What makes virtualization hard v. Operating systems are usually written to assume that they run in privileged mode. v. The Hypervisor (the OS of OS’s) manages the guest OS’s as if they are applications. v. Some architecture provide more than two “Rings” which allows the guest OS to reside between the two states. q But there are still often assumptions in coding that need to be corrected in the guest OS. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Managing Virtual Resource v. Page faults typically trap to the Hypervisor (host OS). q Managing Virtual Resource v. Page faults typically trap to the Hypervisor (host OS). q Issues arise from the need to replace page tables when switching between guest OS’s. q Xen places itself in the Guest OS’s first region of memory so that the page table does not need to be rewitten for traps to the Hypervisor. v. Disks managed as block devices allocated to guest OS’s, so that the Xen code to protect disk extents can be as simple as possible. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Partitioning of Resources v. Fixed partitioning of resources makes the job of managing the Partitioning of Resources v. Fixed partitioning of resources makes the job of managing the Guest OS’s easier, but it is not always the most efficient way to partition. q Resources unused by one OS (CPU, Memory, Disk) are not available to others. v. But fixed provisioning prevents use of resources in one guest OS from effecting performance or even denying service to applications running in other guest OSs. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

The Security of Virtualization v+++ Isolation and protection between OS’s can be simple (and The Security of Virtualization v+++ Isolation and protection between OS’s can be simple (and at a very coarse level of granularity). v+++ This coarse level of isolation may be an easier security abstraction to conceptualize than the finer grained policies typically encountered in OSs. v--- Some malware (Blue pill) can move the real OS into a virtual machine from within which the host OS (the Malware) can not be detected. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Virtualization and Trusted Computing v. The separation provided by virtualization may be just what Virtualization and Trusted Computing v. The separation provided by virtualization may be just what is needed to keep data managed by trusted applications out of the hands of other processes. v. But a trusted Guest OS would have to make sure the data is protected on disk as well. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

CSci 555: Advanced Operating Systems Lecture 7 – October 12, 2007 File Systems Dr. CSci 555: Advanced Operating Systems Lecture 7 – October 12, 2007 File Systems Dr. Clifford Neuman University of Southern California Information Sciences Institute Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

File Systems v. Provide set of primitives that abstract users from details of storage File Systems v. Provide set of primitives that abstract users from details of storage access and management. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Distributed File Systems v. Promote sharing across machine boundaries. v. Transparent access to files. Distributed File Systems v. Promote sharing across machine boundaries. v. Transparent access to files. v. Make diskless machines viable. v. Increase disk space availability by avoiding duplication. v. Balance load among multiple servers. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Sun Network File System 1 v De facto standard: q Mid 80’s. q Widely Sun Network File System 1 v De facto standard: q Mid 80’s. q Widely adopted in academia and industry. v Provides transparent access to remote files. v Uses Sun RPC and XDR. q NFS protocol defined as set of procedures and corresponding arguments. q Synchronous RPC Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Sun NFS 2 v. Stateless server: q Remote procedure calls are selfcontained. q Servers Sun NFS 2 v. Stateless server: q Remote procedure calls are selfcontained. q Servers don’t need to keep state about previous requests. § Flush all modified data to disk before returning from RPC call. q Robustness. § No state to recover. § Clients retry. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Location Transparency v. Client’s file name space includes remote files. q Shared remote files Location Transparency v. Client’s file name space includes remote files. q Shared remote files are exported by server. q They need to be remote-mounted by client. Server 1 /root export users joe bob Server 2 /root Client /root nfs vmunix usr students users staff ann eve Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Achieving Transparency 1 v. Mount service. q Mount remote file systems in the client’s Achieving Transparency 1 v. Mount service. q Mount remote file systems in the client’s local file name space. q Mount service process runs on each node to provide RPC interface for mounting and unmounting file systems at client. q Runs at system boot time or user login time. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Achieving Transparency 2 v Automounter. q Dynamically mounts file systems. q Runs as user-level Achieving Transparency 2 v Automounter. q Dynamically mounts file systems. q Runs as user-level process on clients (daemon). q Resolves references to unmounted pathnames by mounting them on demand. q Maintains a table of mount points and the corresponding server(s); sends probes to server(s). q Primitive form of replication Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Transparency? v. Early binding. q Mount system call attaches remote file system to local Transparency? v. Early binding. q Mount system call attaches remote file system to local mount point. q Client deals with host name once. q But, mount needs to happen before remote files become accessible. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Other Functions v. NFS file and directory operations: q read, write, create, delete, getattr, Other Functions v. NFS file and directory operations: q read, write, create, delete, getattr, etc. v. Access control: q File and directory access permissions. v. Path name translation: q Lookup for each path component. q Caching. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Implementation NFS server Unix Kernel Client process Unix Kernel VFS Unix FS NFS client Implementation NFS server Unix Kernel Client process Unix Kernel VFS Unix FS NFS client Client VFS RPC Unix FS Server Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Virtual File System v. VFS added to UNIX kernel. Location-transparent file access. q Distinguishes Virtual File System v. VFS added to UNIX kernel. Location-transparent file access. q Distinguishes between local and remote access. q v@ client: q Processes file system calls to determine whether access is local (passes it to UNIX FS) or remote (passes it to NFS client). v@ server: q NFS server receives request and passes it to local FS through VFS. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

VFS v If local, translates file handle to internal file id’s (in UNIX i-nodes). VFS v If local, translates file handle to internal file id’s (in UNIX i-nodes). v V-node: § If file local, reference to file’s i-node. § If file remote, reference to file handle. v File handle: uniquely distinguishes file. File system id I-node # I-node generation # Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

NFS Caching v. File contents and attributes. v. Client versus server caching. Server Client NFS Caching v. File contents and attributes. v. Client versus server caching. Server Client $ $ Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Server Caching v. Read: q Same as UNIX FS. q Caching of file pages Server Caching v. Read: q Same as UNIX FS. q Caching of file pages and attributes. q Cache replacement uses LRU. v. Write: q Write through (as opposed to delayed writes of conventional UNIX FS). Why? q [Delayed writes: modified pages written to disk when buffer space needed, sync operation (every 30 sec), file close]. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Client Caching 1 v. Timestamp-based cache validation. v. Read: q Validity condition: (T-Tc < Client Caching 1 v. Timestamp-based cache validation. v. Read: q Validity condition: (T-Tc < TTL) V (Tmc=Tms) v. Write: q Modified pages marked and flushed to server at file close or sync. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Client Caching 2 v. Consistency? q Not always guaranteed! q e. g. , client Client Caching 2 v. Consistency? q Not always guaranteed! q e. g. , client modifies file; delay for modification to reach servers + 3 sec (TTL) window for cache validation from clients sharing file. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Cache Validation v Validation check performed when: q First reference to file after TTL Cache Validation v Validation check performed when: q First reference to file after TTL expires. q File open or new block fetched from server. v Done for all files, even if not being shared. q Why? v Expensive! q Potentially, every 3 sec get file attributes. q If needed invalidate all blocks. q Fetch fresh copy when file is next accessed. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

The Sprite File System v. Main memory caching on both client and server. v. The Sprite File System v. Main memory caching on both client and server. v. Write-sharing consistency guarantees. v. Variable size caches. q VM and FS negotiate amount of memory needed. q According to caching needs, cache size changes. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Sprite v. Sprite supports concurrent writes by disabling caching of write-shared files. q If Sprite v. Sprite supports concurrent writes by disabling caching of write-shared files. q If file shared, server notifies client that has file open for writing to write modified blocks back to server. q Server notifies all client that have file open for read that file is no longer cacheable; clients discard all cached blocks, so access goes through server. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Sprite v. Sprite servers are stateful. q Need to keep state about current accesses. Sprite v. Sprite servers are stateful. q Need to keep state about current accesses. q Centralized points for cache consistency. § Bottleneck? § Single point of failure? v. Tradeoff: consistency versus performance/robustness. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Andrew v. Distributed computing environment developed at CMU. v. Campus wide computing system. q Andrew v. Distributed computing environment developed at CMU. v. Campus wide computing system. q Between 5 and 10 K workstations. q 1991: ~ 800 workstations, 40 servers. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Andrew FS v. Goals: q Information sharing. q Scalability. § Key strategy: caching of Andrew FS v. Goals: q Information sharing. q Scalability. § Key strategy: caching of whole files at client. § Whole file serving – Entire file transferred to client. § Whole file caching – Local copy of file cached on client’s local disk. – Survive client’s reboots and server unavailability. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Whole File Caching v. Local cache contains several most recently used files. (1) open Whole File Caching v. Local cache contains several most recently used files. (1) open ? (2) open C (6) file S (5) file (3) (4) - Subsequent operations on file applied to local copy. - On close, if file modified, sent back to server. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Implementation 1 v. Network of workstations running Unix BSD 4. 3 and Mach. v. Implementation 1 v. Network of workstations running Unix BSD 4. 3 and Mach. v. Implemented as 2 user-level processes: q Vice: runs at each Andrew server. q Venus: runs at each Andrew client. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Implementation 2 Client User Venus program Unix kernel Network Vice Unix kernel Server v Implementation 2 Client User Venus program Unix kernel Network Vice Unix kernel Server v Modified BSD 4. 3 Unix kernel. q At client, intercept file system calls (open, close, etc. ) and pass them to Venus when referring to shared files. v File partition on local disk used as cache. v Venus manages cache. q LRU replacement policy. q Cache large enough to hold 100’s of averagesized files. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

File Sharing v. Files are shared or local. Shared files § Utilities (/bin, /lib): File Sharing v. Files are shared or local. Shared files § Utilities (/bin, /lib): infrequently updated or files accessed by single user (user’s home directory). § Stored on servers and cached on clients. § Local copies remain valid for long time. q Local files § Temporary files (/tmp) and files used for start-up. § Stored on local machine’s disk. q Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

File Name Space Local Shared / tmp bin vmunix cmu bin v Regular UNIX File Name Space Local Shared / tmp bin vmunix cmu bin v Regular UNIX directory hierarchy. v “cmu” subtree contains shared files. v Local files stored on local machine. v Shared files: symbolic links to shared files. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

AFS Caching v AFS-1 uses timestamp-based cache invalidation. v AFS-2 and 3 use callbacks. AFS Caching v AFS-1 uses timestamp-based cache invalidation. v AFS-2 and 3 use callbacks. q When serving file, Vice server promises to notify Venus client when file is modified. q Stateless servers? q Callback stored with cached file. § Valid. § Canceled: when client is notified by server that file has been modified. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

AFS Caching v Callbacks implemented using RPC. v When accessing file, Venus checks if AFS Caching v Callbacks implemented using RPC. v When accessing file, Venus checks if file exists and if callback valid; if canceled, fetches fresh copy from server. v Failure recovery: q When restarting after failure, Venus checks each cached file by sending validation request to server. q Also periodic checks in case of communication failures. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

AFS Caching v. At file close time, Venus on client modifying file sends update AFS Caching v. At file close time, Venus on client modifying file sends update to Vice server. v. Server updates its own copy and sends callback cancellation to all clients caching file. v. Consistency? v. Concurrent updates? Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

AFS Replication v. Read-only replication. q Only read-only files allowed to be replicated at AFS Replication v. Read-only replication. q Only read-only files allowed to be replicated at several servers. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Coda v Evolved from AFS. v Goal: constant data availability. q Improved replication. § Coda v Evolved from AFS. v Goal: constant data availability. q Improved replication. § Replication of read-write volumes. q Disconnected operation: mobility. § Extension of AFS’s whole file caching mechanism. v Access to shared file repository (servers) versus relying on local resources when server not available. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Replication in Coda v. Replication unit: file volume (set of files). v. Set of Replication in Coda v. Replication unit: file volume (set of files). v. Set of replicas of file volume: volume storage group (VSG). v. Subset of replicas available to client: AVSG. Different clients have different AVSGs. q AVSG membership changes as server availability changes. q On write: when file is closed, copies of modified file broadcast to AVSG. q Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Optimistic Replication v. Goal is availability! v. Replicated files are allowed to be modified Optimistic Replication v. Goal is availability! v. Replicated files are allowed to be modified even in the presence of partitions or during disconnected operation. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Disconnected Operation v AVSG = { }. v Network/server failures or host on the Disconnected Operation v AVSG = { }. v Network/server failures or host on the move. v Rely on local cache to serve all needed files. v Loading the cache: q User intervention: list of files to be cached. q Learning usage patterns over time. v Upon reconnection, cached copies validated against server’s files. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Normal and Disconnected Operation v. During normal operation: Coda behaves like AFS. q Cache Normal and Disconnected Operation v. During normal operation: Coda behaves like AFS. q Cache miss transparent to user; only performance penalty. q Load balancing across replicas. q Cost: replica consistency + cache consistency. q v. Disconnected operation: q No replicas are accessible; cache miss prevents further progress; need to load cache before disconnection. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Replication and Caching v Coda integrates server replication and client caching. q On cache Replication and Caching v Coda integrates server replication and client caching. q On cache hit and valid data: Venus does not need to contact server. q On cache miss: Venus gets data from an AVSG server, i. e. , the preferred server (PS). § PS chosen at random or based on proximity, load. q Venus also contacts other AVSG servers and collect their versions; if conflict, abort operation; if replicas stale, update them off-line. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Next File Systems Topics v. Leases q Continuum of cache consistency mechanisms. v. Log Next File Systems Topics v. Leases q Continuum of cache consistency mechanisms. v. Log Structured File System and RAID. q FS performance from the storage management point of view. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Caching v Improves performance in terms of response time, availability during disconnected operation, and Caching v Improves performance in terms of response time, availability during disconnected operation, and fault tolerance. v Price: consistency q Methods: § Timestamp-based invalidation – Check on use § Callbacks Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Leases v Time-based cache consistency protocol. v Contract between client and server. q Lease Leases v Time-based cache consistency protocol. v Contract between client and server. q Lease grants holder control over writes to corresponding data item during lease term. q Server must obtain approval from holder of lease before modifying data. q When holder grants approval for write, it invalidates its local copy. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Protocol Description 1 T=0 (1) read (file-name) Read C S (2) file, lease(term) T Protocol Description 1 T=0 (1) read (file-name) Read C S (2) file, lease(term) T < term Read C (2) file (1) read (file-name) $ S If file still in cache: if lease is still valid, no need to go to server. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Protocol Description 2 T > term (1) read (file-name) Read C S (2) if Protocol Description 2 T > term (1) read (file-name) Read C S (2) if file changed, file, extend lease On writes: T=0 Write (1) write (file-name) C S Server defers write request till: approval from lease holder(s) or lease expires. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Considerations v. Unreachable lease holder(s)? v. Leases and callbacks. q Consistency? q Lease term Considerations v. Unreachable lease holder(s)? v. Leases and callbacks. q Consistency? q Lease term Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Lease Term v. Short leases: q Minimize delays due to failures. q Minimize impact Lease Term v. Short leases: q Minimize delays due to failures. q Minimize impact of false sharing. q Reduce storage requirements at server (expired leases reclaimed). v. Long leases: q More efficient for repeated access with little write sharing. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Lease Management 1 v. Client requests lease extension before lease expires in anticipation of Lease Management 1 v. Client requests lease extension before lease expires in anticipation of file being accessed. q Performance improvement? Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Lease Management 2 v. Multiple files per lease. q Performance improvement? q Example: one Lease Management 2 v. Multiple files per lease. q Performance improvement? q Example: one lease per directory. q System files: widely shared but infrequently written. q False sharing? q Multicast lease extensions periodically. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Lease Management 3 v. Lease term based on file access characteristics. q Heavily write-shared Lease Management 3 v. Lease term based on file access characteristics. q Heavily write-shared file: lease term = 0. q Longer lease terms for distant clients. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Clock Synchronization Issues v. Servers and clients should be roughly synchronized. q If server Clock Synchronization Issues v. Servers and clients should be roughly synchronized. q If server clock advances too fast or client’s clock too slow: inconsistencies. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Next. . . v Papers on file system performance from storage management perspective. v Next. . . v Papers on file system performance from storage management perspective. v Issues: q Disk access time >>> memory access time. q Discrepancy between disk access time improvements and other components (e. g. , CPU). v Minimize impact of disk access time by: q Reducing # of disk accesses or q Reducing access time by performing parallel access. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Log-Structured File System v Built as extension to Sprite FS (Sprite LFS). v New Log-Structured File System v Built as extension to Sprite FS (Sprite LFS). v New disk storage technique that tries to use disks more efficiently. v Assumes main memory cache for files. v Larger memory makes cache more efficient in satisfying reads. q Most of the working set is cached. v Thus, most disk access cost due to writes! Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Main Idea v Batch multiple writes in file cache. q Transform many small writes Main Idea v Batch multiple writes in file cache. q Transform many small writes into 1 large one. q Close to disk’s full bandwidth utilization. v Write to disk in one write in a contiguous region of disk called log. q Eliminates seeks. q Improves crash recovery. § Sequential structure of log. § Only most recent portion of log needs to be examined. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

LSFS Structure v. Two key functions: q How to retrieve information from log. q LSFS Structure v. Two key functions: q How to retrieve information from log. q How to manage free disk space. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

File Location and Retrieval 1 v Allows random access to information in the log. File Location and Retrieval 1 v Allows random access to information in the log. q Goal is to match or increase read performance. q Keeps indexing structures with log. v Each file has i-node containing: q File attributes (type, owner, permissions). q Disk address of first 10 blocks. q Files > 10 blocks, i-node contains pointer to more data. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

File Location and Retrieval 2 v In UNIX FS: q Fixed mapping between disk File Location and Retrieval 2 v In UNIX FS: q Fixed mapping between disk address and file inode: disk address as function of file id. v In LFS: q q I-nodes written to log. I-node map keeps current location of each i-node. File id q i-node’s disk address I-node maps usually fit in main memory cache. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Free Space Management v Goal: maintain large, contiguous free chunks of disk space for Free Space Management v Goal: maintain large, contiguous free chunks of disk space for writing data. v Problem: fragmentation. v Approaches: q q Thread around used blocks. § Skip over active blocks and thread log through free extents. Copying. § Active data copied in compacted form at head of log. § Generates contiguous free space. § But, expensive! Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Free Space Management in LFS v Divide disk into large, fixed-size segments. q Segment Free Space Management in LFS v Divide disk into large, fixed-size segments. q Segment size is large enough so that transfer time (for read/write) >>> seek time. v Hybrid approach. q Combination of threading and copying. q Copying: segment cleaning. q Threading between segments. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Segment Cleaning v Process of copying “live” data out of segment before rewriting segment. Segment Cleaning v Process of copying “live” data out of segment before rewriting segment. v Number of segments read into memory; identify live data; write live data back to smaller number of clean, contiguous segments. v Segments read are marked as “clean”. v Some bookkeeping needed: update files’ inodes to point to new block locations, etc. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Crash Recovery v. When crash occurs, last few disk operations may have left disk Crash Recovery v. When crash occurs, last few disk operations may have left disk in inconsistent state. q E. g. , new file written but directory entry not updated. v. At reboot time, OS must correct possible inconsistencies. v. Traditional UNIX FS: need to scan whole disk. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Crash Recovery in Sprite LFS 1 v. Locations of last disk operations are at Crash Recovery in Sprite LFS 1 v. Locations of last disk operations are at the end of the log. q Easy to perform crash recovery. v 2 recovery strategies: q Checkpoints and roll-forward. v. Checkpoints: q Positions in the log where everything is consistent. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Crash Recovery in Sprite LFS 2 v. After crash, scan disk backward from end Crash Recovery in Sprite LFS 2 v. After crash, scan disk backward from end of log to checkpoint, then scan forward to recover as much information as possible: roll forward. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

More on LFS v. Paper talks about their experience implementing and using LFS. v. More on LFS v. Paper talks about their experience implementing and using LFS. v. Performance evaluation using benchmarks. v. Cleaning overhead. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Redundant Arrays of Inexpensive Disks (RAID) v Improve disk access time by using arrays Redundant Arrays of Inexpensive Disks (RAID) v Improve disk access time by using arrays of disks. v Motivation: q q Disks are getting inexpensive. Lower cost disks: § Less capacity. § But cheaper, smaller, and lower power. v Paper proposal: build I/O systems as arrays of inexpensive disks. q E. g. , 75 inexpensive disks have 12 * I/O bandwidth of expensive disks with same capacity. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

RAID Organization 1 v. Interleaving disks. q Supercomputing applications. q Transfer of large blocks RAID Organization 1 v. Interleaving disks. q Supercomputing applications. q Transfer of large blocks of data at high rates. . Grouped read: single read spread over multiple disks Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

RAID Organization 2 v. Independent disks. q Transaction processing applications. q Database partitioned across RAID Organization 2 v. Independent disks. q Transaction processing applications. q Database partitioned across disks. q Concurrent access to independent items. . Read Write Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Problem: Reliability v Disk unreliability causes frequent backups. v What happens with 100*number of Problem: Reliability v Disk unreliability causes frequent backups. v What happens with 100*number of disks? q MTTF becomes prohibitive q Fault tolerance otherwise disk arrays are too unreliable to be useful. v RAID: use of extra disks containing redundant information. q Similar to redundant transmission of data. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

RAID Levels v. Different levels provide different reliability, cost, and performance. v. MTTF as RAID Levels v. Different levels provide different reliability, cost, and performance. v. MTTF as function of total number of disks, number of data disks in a group (G), number of check disks per group (C), and number of groups. v. C determined by RAID level. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

First RAID Level v. Mirrors. q Most expensive approach. q All disks duplicated (G=1 First RAID Level v. Mirrors. q Most expensive approach. q All disks duplicated (G=1 and C=1). q Every write to data disk results in write to check disk. q Double cost and half capacity. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Second RAID Level v. Hamming code. v. Interleave data across disks in a group. Second RAID Level v. Hamming code. v. Interleave data across disks in a group. v. Add enough check disks to detect/correct error. v. Single parity disk detects single error. v. Makes sense for large data transfers. v. Small transfers mean all disks must be accessed (to check if data is correct). Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Third RAID Level v Lower cost by reducing C to 1. q Single parity Third RAID Level v Lower cost by reducing C to 1. q Single parity disk. v Rationale: q Most check disks in RAID 2 used to detect which disks failed. q Disk controllers do that. q Data on failed disk can be reconstructed by computing the parity on remaining disks and comparing it with parity for full group. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Fourth RAID Level v. Try to improve performance of small transfers using parallelism. v. Fourth RAID Level v. Try to improve performance of small transfers using parallelism. v. Transfer units stored in single sector. q Reads are independent, i. e. , errors can be detected without having to use other disks (rely on controller). q Also, maximum disk rate. q Writes still need multiple disk access. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

Fifth RAID Level v. Tries to achieve parallelism for writes as well. v. Distributes Fifth RAID Level v. Tries to achieve parallelism for writes as well. v. Distributes data as well as check information across all disks. Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

The Google File System v. Focused on special cases: q Permanent failure normal q The Google File System v. Focused on special cases: q Permanent failure normal q Files are huge – aggregated q Few random writes – mostly append q Designed together with the application § And implemented as library Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

The Google File System v. Some requirements q Well defined semantics for concurrent append. The Google File System v. Some requirements q Well defined semantics for concurrent append. q High bandwidth (more important than latency) q Highly scalable § Master handles meta-data (only) Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE

The Google File System v. Chunks q Replicated § Provides location updates to master The Google File System v. Chunks q Replicated § Provides location updates to master v. Consistency q Atomic namespace q Leases maintain mutation order q Atomic appends q Concurrent writes can be inconsistent Copyright © 1995 -2005 Clifford Neuman and Dongho Kim - UNIVERSITY OF SOUTHERN CALIFORNIA - INFORMATION SCIENCES INSTITUTE