M. Kazar, \Synchronization and Caching Issues in the Andrew File System," USENIX Conf., pages 27-36, 1988.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....and the stateless server approach. In the stateful server approach, the server maintains the information about which data are cached by which client. Once a data item is changed, the server sends invalidation messages to the clients with copies of the particular data. The Andrew File System [19] is an example of this approach. However, in mobile environments, the server may not be able to contact the disconnected clients. Thus, a disconnection by a client automatically means that its cache is no longer valid. Moreover, if the client moves to another cell, it has to notify the server. ....

....In order to serve a request sent from a client, the BS needs to communicate with the database server to retrieve the data items. The BS may also use caching techniques. Since the communications between the database servers and the BSs are through wired links, we assume traditional techniques [19], 26] can be used to maintain cache consistency. Since the communication between the BS and the database server is transparent to the clients (i.e. from the client point of view, the BS is the same as the database server) we use the terms BS and server interchangeably. Frequently accessed data ....

M. Kazar, "Synchronization and Caching Issues in the Andrew File System," Proc. USENIX Conf., pp. 27-36, 1988.

....the operation requested on behalf of a particular user. The clients store copies of the files (typically on local disk) and the consistency of these are guaranteed by having the file server notify all hosts caching a file before allowing it to change. This notification is called a callback [2] (also called a lease [3] It allows the clients to use a cached file without any network activity, as long as it has not changed. 3 Implementation of Arla The main difference between Arla and the Transarc client is that Arla only puts a small portion of the code inside the kernel, and instead ....

M. L. Kazar, Synchronization and Caching Issues in the Andrew File System In Proceedings of the USENIX Winter Technical Conference, 1988.

....files systems, little data sharing occurs in practice [2, 17] where data sharing indicates two clients concurrently accessing the same file. Additionally, clients often access data that they have recently used. These claims are supported by the effectiveness of data caching in this environment [19, 15]. More mature distributed file systems [14, 7, 24, 16, 1, 13, 19, 23] take advantage of this observation and cache file data at clients even when no process actively uses the data. The design decision to cache file data after a file has been closed improves performance when a subsequent open from ....

....Implementing Subsets By implementing a chosen subset of all possible locking modes, some systems trade reduced complexity for minor semantic violations. File systems often select a set of distributed locks for file access that are simpler than the semantics of the underlying file open system call [7, 15]. The mismatch between open semantics and locking results in either concurrent opens being allowed that violate open semantics, or concurrent opens being disallowed that open semantics would permit. File systems opt to disallow legal opens because this policy impinges on concurrency rather than ....

[Article contains additional citation context not shown here]

M. L. Kazar. Synchronization and caching issues in the Andrew file system. In Proceedings of the USENIX Winter Technical Conference, February 1988.

....arriving at clients. Leases We propose a hybrid of the server driven and the client driven invalidation schemes using leases [18] To limit the polling for data invalidations, the servers give an invalidation contract or lease to the caching clients, as in the Andrew File System (AFS) [21]. The lease is for a certain amount of time within which the server guarantees to notify the caching client of the data updates, as illustrated in figure 5 9. Once the lease is obtained, the system turns into a reactive or a client driven system. It is now the responsibility of the client to keep ....

M.L. Kazar, Synchronization and Caching Issues in the Andrew file System. Usenix Conference Proceedings, Dallas, Winter 1998

....their caches from the server. Two main mechanisms have been suggested to deal with the cache consistency problem in distributed systems. NFS [Mic] uses the mechanism of validation check, in which the client caching a data item inquires from the server about its validity before each use. Andrew[Kaz88] and Coda[LM94a] combine the mechanisms of call backs and validation checks. When a client receives a page from a server, it also receives a call back promise for the page a guarantee that the server will notify the client if the page changes. Periodically validation checks are performed for all ....

Michael L. Kazar. Synchronization and caching issues in the andrew file system. In USENIX Conference, pages 27--36, 1988.

.... adaptations to that model such as the DoD Internet adaptation [RFC 905, RFC 982, RFC 994, RFC 1006, RFC 1085, RFC 1138] This memo proposes fully analogous conventions for applications that wish to run above the distributed file system layer as provided by AFS (a product of Transarc Corporation) [JHH88a, JHH88b, MLK88]. Such conventions are unusual, for distributed file systems historically do not address problems beyond those of a single installation. Rather, they are generally concerned with improving computer based sharing within a given site. ############### 1 AFS is a trademark of Transarc ....

Michael Leon Kazar. Synchronization and Caching Issues in the Andrew File System. In Proceedings of the Spring 1988 Usenix Conference, Dallas. Also available as technical report CMU-ITC-063, Carnegie Mellon University, Pittsburgh, PA.

....on the uniform usage patterns, which depict unrealistic and overly pessimistic predictions. Kistler and Satyanarayanan [15] at CMU have conducted an empirical study of disconnected operations of Coda, which utilizes the limited optimistic replication capabilities in the Andrew File System [14] to offer optimistic replication and caching support for operation with network disconnection. The primary interest of their study is to prove the feasibility of disconnected operation. With trace data, researchers demonstrated the feasibility by showing that the average working set is small and ....

Kazar M. Synchronization and Caching Issues in the Andrew File System. Proceeding of the Winter Usenix Conference, pp. 31-43, February 1998.

....of the world. 4.2. Data stores Currently, the data stores we support are limited to those addressable through URIs. Our applications can currently access data stores using HTTP and FTP, as well as files accessible via a standard file system interface such as local file systems, NFS[12] and AFS[6]. 4.3. Applications We have implemented three Roma aware applications. These applications allow users to view and manipulate their metadata and data from a variety of devices. The first is a web based metadata browser that provides hierarchical browsing of a user s personal data. The browser ....

....still existed. In the future, Roma must address this problem more systematically. 6. Related work Helping users access data on distributed storage repositories is an active area of research. The primary characteristic distinguishing our work from distributed file systems, such as NFS[12] AFS[6], and Coda[7] is our emphasis on unifying a wide variety of existing data repositories to help users manage their personal files. Like Roma, the Coda distributed file system seeks to allow users to remain productive during periods of weak or no network connectivity. While Roma makes metadata ....

M. L. Kazar, "Synchronization and Caching Issues in the Andrew File System." Proceedings of the Winter 1988 USENIX Technical Conference, February 1988.

.... completely solve this problem; that is, Sprite applications can believe their writes are safe but the delayed writes pile up in a volatile cache because the server is out of space [2] AFS apparently follows the same approach as NFS, forcing modified data back to the server when the file is closed [12]. Spritely NFS solves the ENOSPC problem by reserving disk space for the remaining dirty data when the file is closed. That is, when a dirty file is closed, the client counts up the number of dirty bytes and requests that the server reserve that much disk space for the file. The server may ....

....mechanism. Spritely NFS has the advantage that the extra locking overhead is necessary only if write sharing is actually taking place. 10.4. Security NFS does not provide much in the way of security, but in principle one can use cryptographic techniques to prevent illicit access to file data [12, 30]. Spritely NFS introduces the possibility of malicious interference with the cache consistency and recovery protocols. Fortunately, the worst that could be done this way would be to slow down legitimate clients (perhaps by forcing them to stop caching the files they are using, or wait for spurious ....

Michael Leon Kazar. Synchronization and Caching Issues in the Andrew File System. In Proc. Winter 1988 USENIX Conference, pages 27-36. Dallas, TX, February, 1988.

....Contention for the lock can stall the update indefinitely. The example application presents a non traditional workload to the file system. The workload lacks the properties a file system expects and therefore operates inefficiently. Specifically, the workload does not have client locality [9] the affinity of a file to a single client. Instead, all clients are interested in all files. Performance concerns aside, sequential consistency is the wrong model for updating HTML and XML. As we discussed in Section 1, reading clients cannot understand intermediate updates and byte level ....

....session. 2.2 AFS Consistency Among existing systems, the Andrew file system (AFS) comes closest to publish consistency. AFS does not implement sequential consistency. Rather, it chooses to synchronize file data between readers and writers when files opened for write are closed. Previous research [9] argues that data are shared infrequently to justify this decision. Figure 3(b) shows the protocol used in AFS to handle the dynamic updates in our example. At the start of our timing diagram all Web servers hold the file in question open for read. In AFS an open instance registers a client for ....

[Article contains additional citation context not shown here]

M. L. Kazar, "Synchronization and caching issues in the Andrew file system," in Proceedings of the USENIX Winter Technical Conference, Feb. 1988.

....Contention for the lock can stall the update indefinitely. The example application presents a non traditional workload to the file system. The workload lacks the properties a file system expects and therefore operates inefficiently. Specifically, the workload does not have client locality [18] the affinity of a file to a single client. Instead, all clients are interested in all files. Performance concerns aside, sequential consistency is the wrong model for updating HTML and XML. As we discussed in Section 1, reading clients cannot understand intermediate updates and byte level ....

....2.2 AFS Consistency For existing distributed systems, the Andrew file system (AFS) comes closest to publish consistency. AFS does not implement sequential consistency, rather it chooses to synchronize file data between readers and writers when files opened for write are closed. Previous research [18] argues that data are shared infrequently to justify this decision. DFS [19] the successor product to AFS, reversed this decision. DFS found that distributed applications sometimes require sequential consistency for correctness. While sequential consistency is now the de facto standard for file ....

[Article contains additional citation context not shown here]

M. L. Kazar. Synchronization and caching issues in the Andrew file system. In Proceedings of the USENIX Winter Technical Conference, February 1988.

....The traditional Unix volume super tree connection mechanism has been widely altered or replaced to support both small and large scale distributed file systems. Examples of the former are Sun s Network File System (NFS) 13] and IBM s TCF [12] larger scale file systems are exemplified by AFS [7], Decorum [6] Coda [14] Sprite [9] and Ficus [2, 10] The problem addressed by this paper is simply stated as follows: in the course of expanding a path name in a distributed file system, the system encounters a graft point. That is, it reaches a leaf node in the current volume which ....

Michael Leon Kazar. Synchronization and caching issues in the Andrew File System. In USENIX Conference Proceedings, pages 31--43. USENIX, February 1988.

....machines, in which servers keep track of which clients have cached what files and directories. The algorithm enables a client machine to cache files and directories, including caching of write behind. The Echo distributed caching algorithm is similar to those of the Sprite and Andrew file systems [16, 17, 24], and is discussed in detail in a separate paper [21] Thus, EchoBox is used by a client machine that handles caching. The client machine also handles failover between EchoBox server replicas. Caching and failover had several significant impacts on the design of the EchoBox interface. A design ....

Michael L. Kazar. Synchronization and caching issues in the Andrew file system. In USENIX Winter Conference Proceedings, pages 27--36. USENIX Association, February 1988.

....be ported and new applications written only when a critical mass of Roma users exists. 6 Related work Helping users access data on distributed storage repositories is an active area of research. The primary characteristic distinguishing our work from distributed le systems, such as NFS[11] AFS[6], and Coda[7] is our emphasis on unifying a wide variety of existing data repositories to help users manage their personal les. The Coda distributed le system, like Roma, seeks to allow users to remain productive during periods of weak or no network connectivity. While Roma makes metadata ....

M. L. Kazar, \Synchronization and Caching Issues in the Andrew File System." Proceedings of the Winter 1988 USENIX Technical Conference, February 1988.

....and consequently reduces latency by avoiding message round trip time. Clients cache access privileges to a file on the belief that the file will be used again locally before being used by another client. The same temporal locality that makes data caching effective in the distributed environment [19, 14] is used to improve performance for file open. Semi preemptible locks also reduce distributed lock state. Clients often hold multiple open instances of a single file concurrently. All of these open instances can be granted under a single semi preemptible lock, rather than holding a separate lock ....

....files systems, little data sharing occurs in practice [2, 16] where data sharing indicates two clients concurrently accessing the same file. Additionally, clients often access data that they have recently used. These claims are supported by the effectiveness of data caching in this environment [19, 14]. More mature distributed file systems [13, 6, 22, 15, 1, 12, 19, 21] take advantage of this observation and cache file data at clients even when no process actively uses the data. The design decision to cache file data after a file has been closed improves performance when a subsequent open from ....

[Article contains additional citation context not shown here]

M. L. Kazar. Synchronization and caching issues in the Andrew file system. In Proceedings of the USENIX Winter Technical Conference, February 1988.

....The traditional Unix mounted filesystem mechanism has been widely altered or replaced to support both small and large scale distributed file systems. Examples of the former are Sun s Network File System (NFS) SGK85] and IBM s TCF [PW85] larger scale file systems are exemplified by AFS [Kaz88], Decorum [KLA90] Coda [SKK90] and Ficus [GHM90, PGP91] In a conventional single host Unix system, a single mount table exists which contains the mappings between the mounted on directories and the roots of mounted volumes. However, in a distributed file system, the equivalent of the mount ....

Michael Leon Kazar. "Synchronization and Caching Issues in the Andrew File System." In USENIX Conference Proceedings, pp. 31--43. USENIX, February 1988.

....This scheme cannot keep caches coherent. However, it is simple in that servers keep no lock state and do nothing when a failure occurs. Other file systems choose to steal locks when clients fail. Locks are stolen in the fashion described in Section 1.2. Examples include the Andrew file system [15], Sprite [4] and the DEcorum file system. Since these file systems marshal all I O requests through a server, stealing locks is safe. In file systems that are peer based, and have no server, or use direct access to network addressable storage, stealing locks is not safe. A prevalent and ....

M. L. Kazar. Synchronization and caching issues in the Andrew file system. In Proceedings of the USENIX Winter Technical Conference, February 1988.

....as an example of the facilities typically available in a wide area file system. Using a set of trusted servers, AFS presents to clients a location transparent, hierarchical name space. Files and directories are cached on the local disks of clients using a consistency mechanism based on callbacks [9]. A volume consists of a set of files and directories located on one server and forms a partial subtree of the shared name space [11] The distribution of volumes across servers is an administrative decision. Volumes that are frequently read but rarely modified (such as system binaries) may have ....

M. L. Kazar. Synchronization and caching issues in the Andrew File System. In Proceedings of the Winter 1988 Usenix Conference. Usenix Association, January 1988.

....the number of STOREDATA requests seen by each simulated machine. The cache replacement policy used at all levels is LRU. When a file is written by a client, the simulator invalidates that file in the cache of any other client holding a copy, mimicking AFS caching behavior as closely as possible [18]. Baker et al. report that most files are quickly deleted or overwritten [19] between 65 and 80 of files are destroyed within 30 seconds of creation. Thus, simulations to determine the parameters of an efficient delayed write policy in the integrated mass storage environment are of interest. ....

M. Kazar, "Synchronization and Caching Issues in the Andrew File System," pp. 28-36 in Winter 1988 USENIX Conference Proceedings, Dallas (February, 1988).

....is based on a version of the AFS client that supports disconnected operation [8] The client cache manager supports three modes of operation; connected, disconnected, and fetch only. In connected mode the cache manager is an ordinary AFS client, using callback promises to preserve cache coherence [10]. In disconnected mode the cache manger treats the network as unavailable, and allows cached data to be used even though cache consistency can not be guaranteed. File and directory modifications are also handled optimistically: updates are reflected in the disconnected cache and logged for ....

....the availability of some communication between the client and file servers. This lets us use AFS callbacks to offer regular AFS consistency guarantees to the partially connected client: a client opening a file is guaranteed to see the data stored when the latest (connected) writer closed the file [10]. Of course, all AFS clients, including partially connected ones, see their local modifications before the file is closed and updates are propagated to the server. Directories are tricky. If a partially connected user inserts a file in a directory, and another user later inserts another file, it ....

Michael Leon Kazar, "Synchronization and Caching Issues in the Andrew File System," in Proc. of the Winter USENIX Conf. (February 1988).

....protocol revisions would follow, allowing us to defer features. Improved data and cache consistency is an obvious candidate for NFS Version 4. POSIX write sharing semantics exist today on a single NFS client. NFS Versions 2 and 3 support a client driven bounded time based model for write sharing [Kazar88], with close to open consistency. This model does not provide sufficient guarantees for concurrent write sharing between cooperating clients in the absence of explicit locking. The fact that write sharing is infrequent even in those distributed file systems that support it [Welch90] is a reason ....

Kazar, Michael Leon, "Synchronization and Caching Issues in the Andrew File System," USENIX Conference Proceedings, USENIX Association, Berkeley, CA, Dallas Winter 1988, pages 27-36. Describes cache consistency in AFS and contrasts it with other distributed file systems.

....for its extra complexity are not compelling. Our work incorporates a distributed caching algorithm, in which servers keep track of which client machines have cached what data and call them back when their caches must be invalidated. The algorithm is similar in many respects to those of the Andrew [12, 14] and Sprite [22] systems, and to one advanced by Burrows [4] 2 Replication Algorithm We describe the replication algorithm in detail in this section. We begin by outlining the phases that the algorithm goes through in its operation and the states that each replica can be in, then go on to ....

....the token and is asking for it back, or is asking for a token that the clerk already (perhaps unknowingly) held. We spent quite a bit of effort trying to develop a neat, efficient solution to this problem without success and at last fell back on the simple technique used in CMU s Andrew system [14]. When a request and a callback cross as just described, the clerk responds positively to the callback and internally marks the request as aborted. When the aborted request returns, the clerk retries it. Such retries occur rarely, so we consider this solution adequate. 3.2 Token recovery The ....

[Article contains additional citation context not shown here]

Michael L. Kazar. Synchronization and caching issues in the Andrew file system. In Winter Conference Proceedings, pages 27--36. USENIX Association, February 1988.

....Goals 10 September 3, 1991 5:08 AFS 3 Architectural Overview Chapter 4 AFS High Level Design 4.1 Introduction This chapter presents an overview of the system architecture for the AFS 3 WADFS. Different treatments of the AFS system may be found in several documents, including [3] 4] 5] and [2]. Certain system features discussed here are examined in more detail in the set of accompanying AFS programmer specification documents. After the archtectural overview, the system goals enumerated in Chapter 3 are revisited, and the contribution of the various AFS design decisions and resulting ....

Michael L. Kazar, Synchronization and Caching Issues in the Andrew File System, USENIX Proceedings, Dallas, TX, Winter 1988.

....is based on a version of the AFS client that supports disconnected operation [7] The client cache manager supports three modes of operation; connected, disconnected, and fetch only. In connected mode the cache manager is an ordinary AFS client, using callback promises to preserve cache coherence [10]. In disconnected mode the cache manger treats the network as unavailable, and allows cached data to be used even though cache consistency can not be guaranteed. File and directory modifications are also handled optimistically: updates are reflected in the disconnected cache and logged for later ....

....availability of some communication between the client and file servers. This lets us use AFS callbacks to offer regular AFS consistency guarantees to the partially connected client: such a client opening a file is guaranteed to see the data stored when the latest (connected) writer closed the file [10]. Of course, all AFS clients, including partially connected ones, see their local modifications before the file is closed and propagated to the server. Directories can be tricky. A partially connected user may insert a file in a directory, while another user inserts another entry into the ....

Michael Leon Kazar, "Synchronization and Caching Issues in the Andrew File System," in Proc. of the Winter USENIX Conf. (February 1988).

....of the current version of AFS (AFS 3) to make the rest of the paper understandable. Using a set of trusted servers, AFS presents a location transparent Unix file name space to clients. Files and directories are cached on the local disks of clients using a consistency mechanism based on callbacks [3]. Directories are cached in their entirety, while files are cached in 64 KB chunks. All updates to a file are propagated to its server upon close. Directory modifications are propagated immediately. Backup, disk quota enforcement, and most other administrative operations in AFS operate on volumes ....

Kazar, M.L., Synchronization and Caching Issues in the Andrew File System. Usenix Conference Proceedings, Winter 1988.

....of the current version of AFS (AFS 3) to make the rest of the paper understandable. Using a set of trusted servers, AFS presents a location transparent Unix file name space to clients. Files and directories are cached on the local disks of clients using a consistency mechanism based on callbacks [6]. Directories are cached in their entirety, while files are cached in 64 KB chunks. All updates to a file are propagated to its server upon close. Directory modifications are propagated immediately. Backup, disk quota enforcement, and most other administrative operations in AFS operate on volumes ....

Kazar, M.L., Synchronization and Caching Issues in the Andrew File System. Usenix Conference Proceedings, Winter 1988.

....JetFile is designed to support large caches (on the order of gigabytes) to improve availability and to avoid the effects of transmission delays. JetFile takes a best effort approach with worst case guarantees to maintain cache coherency. Coherency is maintained through a lease [14] or callback [17] style mechanism 1 . The callback mechanism is best effort in the sense that there is a high probability, but no absolute guarantee, that a callback reaches all destinations. If there are nodes that did not receive a callback message, the amount of time they will continue to access stale data is ....

....limited by a worst case bound. In the worst case, when packet loss is high, JetFile provides consistency at about the same level as NFS [30] Under more normal network conditions, with low packet drop rates, cache consistency in JetFile is much stronger and closer to that of the Andrew File System [17]. Applications that require consistency stronger than what JetFile guarantee may experience problems. This is an effect of the optimistic and best effort algorithms that JetFile uses. Only under good network conditions will JetFile provide consistency stronger than NFS. To exemplify this, if a ....

[Article contains additional citation context not shown here]

M. L. Kazar, Synchronization and Caching Issues in the Andrew File System In Proceedings of the USENIX Winter Technical Conference, 1988.

....in the number of users. The chief obstacles to high performance in a wide area information system are server and network loads and network latency. Traditional techniques of caching and replication address performance issues associated with the exponential growth in users, servers, and information [10]. Traditionally, caching and replication are used to improve performance. Caching decreases latency, server load, and network load because the request to retrieve a document can be handled by the local client machine. Replication transparently distributes server and network load. In addition, both ....

M. L. Kazar. Synchronization and caching issues in the Andrew File System. In Proceedings of the Winter 1988 Usenix Conference. Usenix Association, January 1988.

.... [23] Locus provides strong coherence with a distributed token passing algorithm [20] while Sprite detects concurrent update at a central site and disables caching for coherence [17] Later systems provide variations on the token algorithm: AFS s callbacks are essentially centrally managed tokens [11]; Gray s leases are tokens that can time out to simplify error recovery [6] Cache coherence in stacking borrows the basic coherence approach used in these systems. Unlike these systems, stacking faces the unique problem of data identification across different data representations. 6.2 ....

Michael Leon Kazar. Synchronization and caching issues in the Andrew File System. In USENIX Conference Proceedings, pages 31--43. USENIX, February 1988.

....approach were discussed in Section 6.2 above. Sprite does not use leases. If a server loses touch with a clerk, it invalidates the clerk s tokens immediately. Therefore, for the reasons discussed in Section 6.2 above, Sprite does not provide strict single copy equivalence. The Andrew File System [13, 14] caches both files and directories on client machines. On directory updates, AFS does write through, not write behind. AFS caches files in their entirety, not block by block, and it delays writing changes to a file back to the server at least until the file is closed. The file cache is kept ....

Michael L. Kazar. Synchronization and caching issues in the Andrew file system. In Proc. Winter 1988 USENIX Conference, pages 27--36. USENIX Association, February 1988.

....the changes. Can this style of window system be built on other operating systems A major part of the design of 8 1 2 depends on its structure as a file server. In principle this could be done for any system that supports user processes that serve files, such as any system running NFS or AFS [Sun89, Kaza87]. One requirement, however, is 8 1 2 s need to respond to its clients requests out of order: if one client reads dev cons in a window with no characters to be read, other clients should be able to perform I O in their windows, or even the same window. Another constraint is that the 8 1 2 ....

Mike Kazar, "Synchronization and Caching issues in the Andrew File System", Tech. Rept. CMU-ITC-058, Information Technology Center, Carnegie Mellon University, June, 1987

....describe congestion avoidance schemes for NFS over UDP. Caching policies The NFS version 3 protocol does not define a policy for caching on the client or server. In particular, there is no support for strict cache consistency between a client and server, nor between different clients. See [Kazar] for a discussion of the issues of cache synchronization and mechanisms in several distributed file systems. Stable versus unstable writes The setting of the stable field in the WRITE arguments, that is whether or not to do asynchronous WRITE requests, is straightforward on a UNIX client. If the ....

Kazar, Michael Leon, "Synchronization and Caching Issues in the Andrew File System," USENIX Conference Proceedings, USENIX Association, Berkeley, CA, Dallas Winter 1988, pages 27-36. A description of the cache consistency scheme in AFS. Contrasted with other distributed file systems.

No context found.

M. Kazar, \Synchronization and Caching Issues in the Andrew File System," USENIX Conf., pages 27-36, 1988.

No context found.

M. Kazar, Synchronization and Caching Issues in the Andrew File System, USENIX Conf., pp. 27--36, 1988.

No context found.

Kazar, Michael Leon, "Synchronization and Caching Issues in the Andrew File System," USENIX Conference Proceedings, USENIX Association, Berkeley, CA, Dallas Winter 1988, pages 27-36. A description of the cache consistency scheme in AFS. Contrasted with other distributed file systems.

No context found.

M. Kazar, Synchronization and Caching Issues in the Andrew File System, USENIX Conf., pp. 27--36, 1988.

No context found.

Kazar, Michael Leon, "Synchronization and Caching Issues in the Andrew File System," USENIX Conference Proceedings, USENIX Association, Berkeley, CA, Dallas Winter 1988, pages 27-36. A description of the cache consistency scheme in AFS. Contrasted with other distributed file systems.

No context found.

M. L. Kazar. Synchronization and caching issues in the Andrew file system. In Proceedings Winter 1988 USENIX, pages 27--36, Dallas, Feb. 1988.

No context found.

Michael L. Kazar,Synchronization and Caching Issues in the Andrew File System, In Proc. Winter 1988 USENIX Conference, pg. 27-36, Dallas, TX, February 1988.

No context found.

M. Kazar, "Synchronization and Caching Issues in the Andrew File System," pp. 28-36 in Winter 1988 USENIX Conference Proceedings, Dallas (February, 1988).

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC