Kazar et al., "DEcorum File System Architectural Overview,. of USENIX Summer Conference, Anaheim, California, 1990.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....it has been closed by all clients. The modified scheme makes a file cacheable again as soon as it has been closed by enough clients to eliminate the concurrent write sharing. The second alternative is a token based scheme simi lar to that implemented in the Locus [14] Echo [6] and DEcorum [5] file systems. In this approach a file is always cacheable on at least one client. In order to access a file, a client must obtain a read only or read write token from the server; once a client has obtained the appropriate token it is free to cache the file and access it. The server guarantees ....

Kazar, M. L., Leverett, B. W., Anderson, O. T., Apostolides, V., Bottos, B. A., Chutani, S., Everhart, C. F., Mason, W. A., Tu, S. and Zayas, E. R., "DEcorum File System Architectural Overview", Proceedings of the Summer 1990 USENIX Conference, Anaheim, CA, June 11-15 1990, 151- 164.

....outputs kernel C sources. Legion s goal of acceptance amongst diverse organizations requires both that it provide secure means of cross domain access and that administrative overhead be minimized. Centralized key services, such as Kerberos, have been successfully employed by AFS [21] 38] and DFS [22], but do not meet these requirements. The centralized key management in Kerberos becomes increasingly difficult as the system scales. The Self certifying File System (SFS) 31] embeds a public key in the name of a file, making self certifying pathnames. LegionFS leverages a similar, distributed ....

M. L. Kazar, B. W. Leverett, O. T. Anderson, V. Apostolides, B. A. Bottos, S. Chutani, C. F. Everhart, W. A. Mason, S.-T. Tu, and E. R. Zayas. Decorum file system architectural overview. In Proceedings of the

....all locking modes pairwise. This data structure fully specifies the interactions between locking modes, but grows quadratically in size with respect to the number of locking modes. Alternatively, modern file systems use ad hoc rule based methods to evaluate locks that are efficient and compact [16]. However, without formally specified semantics, the interactions between locking modes can be difficult to reason about and implement correctly. We present a formal specification of locking modes and derive from this a data structure and algorithms for the management of distributed locks called ....

....as Gigabit Ethernet [9] A distributed file system built on a SAN removes the server bottleneck for I O requests by giving clients a direct data path to disks. File system clients on a SAN access data directly over the storage area network. In contrast, most traditional client server file systems [26, 14, 16, 7] store data on the server s private disks. Clients function ship all data requests to a server that performs I O on their behalf. Unlike traditional file systems, Storage Tank clients perform I O directly to shared storage devices. This direct data access model is similar to the file system for ....

[Article contains additional citation context not shown here]

M. L. Kazar, B. W. Leverett, O. T. Anderson, V. Apostolides, B. A. Bottos, S. Chutani, C. F. Everhart, W. A. Mason, S. Tu, and R. Zayas. DEcorum file system architectural overview. In Proceedings of the Summer USENIX Conference, June 1990.

....and to exchange per realm keys. Hierarchical organization and authentication of realms can reduce the number of inter realm relationships. Kerberos has been used on other distributed file systems, such as the Andrew File System [Howard] the Open Software Foundation s Distributed File System [Kazar], NFS Version 2 and 3 [RFC2623] and most recently, Microsoft s CIFS (Windows 2000) Microsoft00] Kerberos is an excellent choice for enterprises and work groups operating within an Intranet, since it provides centralized control, as well as single sign on to the network. But NFS Version 4 is ....

....NFS Version 4 does not address server toserver file system migration protocols or the issues of maintaining replica consistency and migration atomicity. It remains for future working groups to define. Until then, vendor specific solutions may arise. 16.5. Single system image or name space [Kazar, Howard, Microsoft99] describe approaches to providing a shared consistent name space that hides server details of data location from users. An NFS Version 4 server hides some details of data location by presenting a per server single image of all exported file systems to a client. There is interest in providing a ....

Kazar, M.L., Leverett, B., et.al, "Decorum File System Architectural Overview," Proceedings of the USENIX Summer 1990 Conference.

....not address interactive and synchronous data sharing. NFS, on the other hand, accommodates the requirement of expanding the local file system view (UNIX) into a heterogeneous local area network environment to a certain degree [1] In this paper, I will discuss, how the DCE File System (DFS) 2][3] meets the requirements in today s and future environments. A distributed file system approaches a general purpose service for accessing and controlling data resources transparently, independent of the location where they are stored. Thus, specialized services such as distributed databases, ....

Michael L. Kazar, DEcorum File System Architectural Overview, USENIX Summer Conference (June 11-15, 1990)

....designed and optimized for a particular type of environment or usage pattern. General purpose file systems are often implemented based on design decisions pertinent to the system s intended scale, be it a wide area environment, Ale97] Vah98] a local area environment [San85] How88] Sat90] [Kaz90], a cluster [Ji00] And95] or a single host [McK84] Additionally, file systems may target a particular domain such as real time continuous media access [Mar96] or particular interfaces such as those provided by parallel file systems [Cor93] Nie96] There are two main reasons for this design ....

....the inclusion of a public key in the name of a file, making self certifying pathnames. The management of keys in LegionFS is accomplished in the same manner; however LegionFS achieves scalability (and other goals) through mechanisms other than scalable key management. AFS [How88] Sat90] and DFS [Kaz90] are each based on Kerberos [Neu94] which is a centralized key service. The centralized key management of Kerberos is very difficult to manage as the number of clients increases significantly. WebFS [Vah98] implements a distributed file system based on HTTP, and as such is not amenable to ....

Kazar, Michael, Bruce W. Leverett, Owen T. Anderson, Vasilis Apostolides, Beth A. Bottos, Sailesh Chutani, Craig F. Everhart, W. Wnthony Mason, Shu-Ysui Tu, and Edward R. Zayas. Decorum file system architectural overview. In Proceedings of the Summer 1990 USENIX, pages 151163, Anaheim, CA, 1990.

....index to reflect the new location of the data. If an operation is interrupted before it completes, the index points to the old data, and the data from the incomplete operation is ignored. Both logging and shadow paging have been used in a variety of systems. For example, the Episode file system [73] and the Cedar file system [63] both use logging to recover system meta data. Also, the IBM AIX 3.0 file system uses logging to recover completed operations [22] The IBM VM file system uses shadow pages to update its file system. The advantage of logging over shadow paging is that the logging ....

M. L. Kazar and et al. DEcorum file system architectural overview. In Proceedings Summer 1990 USENIX, pages 151--163, Anaheim, CA, June 1990.

....be written to disk very efficiently. The actual data are written back to the file system at 18 some later point when the disk accesses will not impact performance. There have been several variants of the journaling file systems and they have become widely accepted in the commercial marketplace [13, 59, 106] The second class of file systems are called log structured, and they replace the entire file system with a single log based representation of the file system. While the logging file systems write small log records to disk when data in the cache is dirtied, the log structured systems (LFS) ....

M. Kazar, B. Leverett, O. Anderson, A. Vasilis, B. Bottos, S. Chutani, C. Everhart, A. Mason, S. Tu, and E. Zayas. Decorum file system architectural overview. In Proceedings of the 1990 Summer Usenix, pages 151--164, Anaheim, CA, June 1990.

....system is that, as much as applications do not rely on the file system as a fully trusted partner in their recovery, distributed file systems do not rely on the clients ability to tolerate failures to improve their own reliability and performance. For instance, several distributed file systems [5, 28, 16, 17, 18, 24] rely on recovery protocols that use information provided by clients to restore the state of a faulty server s cache. These protocols for server recovery, however, are not designed for environments in which (1) clients cooperate in distributed applications and (2) clients attempt to recover to a ....

M.Kazar, B.Leverett, O.Anderson, V.Apostolides, V.Bottos, S.Chutani, C.Everhart, W.Mason, S.Tu, and E.Zayas. Decorum File System Architectural Overview. In Proceedings of the Summer 1990 USENIX Conference, pages 151--163, June 1990.

.... At any time means in this context, that the method has to be able to cope with single code server failures, e.g. by the use of replication of classes. There are some existing components that offer this functionality, e.g. distributed file systems with replication facilities like DFS [KLA90] or general object location systems (code pieces are in this sense objects ) like the one used in Hermes [BA90] Since this aspect is not so important to efficiency, we decided to implement an own, small mechanism that also offers the requested features and fits into our architecture without the ....

Kazar, Leverett, Anderson et. al.: DEcorum File System Architectural Overview, in: Proc. Summer 1990 USENIX Conf., Summer 1990

.... the kernel uses efficient synchronization primitives based on fast test and set instructions, which are not available to applications [AT T] Modern file systems use logging to provide improved performance and fast recovery, but these logging mechanisms are not available for application use [CHANG90, CHUT92, KAZAR90, VXFS]. Today s applications are unable to realize the potential of today s hardware [OUST90] Database management systems are the classic example of competition between applications and the operating systems [STON81] However, they are only one example; real time systems, highspeed networking ....

....in a Large Shared Database, in Modeling in Data Base Management Systems, Elsevier North Holland, New York, pp. 365 394 (1976) IEEE93] IEEE, Portable Operating System Interface (POSIX) Part 1: System Application Program Interface (API) C Language] IEEE Standard 1003.1b, September 1993. [KAZAR90] Kazar, M. Leverett, B. Anderson, O. Vasilis, A. Bottos, B. Chutani, S. Everhart, C. Mason, A. Tu, S. Zayas, E. DECorum File System Architectural Overview, Proceedings of the 1990 Sum mer Usenix, Anaheim, CA, June 1990, 151 164. LISK93] Liskov, B. Day, M. and Shrira, M. ....

[Article contains additional citation context not shown here]

Kazar, M., Leverett, B., Anderson, O., Vasilis, A., Bottos, B., Chutani, S., Everhart, C., Mason, A., Tu, S., Zayas, E., "DECorum File System Architectural Overview," Proceedings of the 1990 Summer Usenix, Anaheim, CA, June 1990, pp. 151--164.

....traffic, and thus cannot guarantee the integrity of data from file systems on which users do not have accounts. Though AFS can be compiled to encrypt network communications to servers on which users have accounts, the commercial binary distributions in widespread use do not offer any secrecy. DFS [15] is a second generation file system, based on AFS, in which a centrally maintained database determines all available file systems. 13 To make the benefits of self certifying pathnames more concrete, consider the following security conundrum posed by AFS. AFS uses password authentication to ....

.... Let R[0] R[n 19] be the encryption result transmitted on the wire ffl Let SHA 1 16 designate the first 16 bytes of a SHA 1 hash ffl Let P [0] P [3] ntonl(0x80000000jn) ffl Let P [4] P [3 n] M[0] M [n Gamma 1] ffl Let P[4 n] P[4 n 15] SHA 1=16(A[0] A[15] jj P [0] p[3 n] jj A[16] A[31] ffl for (i 0; i n 19; i i 1) fR[i] P [i] Phi A[32 i]g In other words, the first 32 bytes of ARC4 data get used to compute a 16 byte MAC on the message length and contents. Then then entire packet including length, message contents, and ....

Michael L. Kazar, Bruce W. Leverett, Owen T. Anderson, Vasilis Apostolides, Beth A. Bottos, Sailesh Chutani, Craig F. Everhart, W. Anthony Mason, ShuTsui Tu, and Edward R. Zayas. DEcorum file system architectural overview. In Proceedings of the Summer 1990 USENIX, pages 151--163, Anaheim, CA, 1990. USENIX. 138

.... in large scale systems that serve dynamically changing Web content with a distributed file system: files containing HTML or XML that are concurrently updated (written) and served to Web clients (read) A good example of such a system is IBM s Olympics web site [2] which used the DFS file system [3] to replicate changing data like race results at a global scale. Distributed file systems provide synchronized access and consistent views of shared data, shielding Web servers from complexity by moving these tasks into the file system. Most often file systems implement sequential consistency ....

....on a storage area network (SAN) A SAN is a high speed network designed to allow multiple computers to have shared access to many storage devices. For our distributed file system on a SAN, clients access data directly over the storage area network. Most traditional client server file systems [5, 6, 3] store data on the server s private disks. Clients dispatch all data requests to a server that performs I O on their behalf. Unlike traditional file systems, Storage Tank clients perform I O directly to shared storage devices on a SAN (Figure 1) This direct data access model is similar to the ....

[Article contains additional citation context not shown here]

M. L. Kazar, B. W. Leverett, O. T. Anderson, V. Apostolides, B. A. Bottos, S. Chutani, C. F. Everhart, W. A. Mason, S. Tu, and R. Zayas, "DEcorum file system architectural overview," in Proceedings of the Summer USENIX Conference, June 1990.

.... large scale systems that serve dynamically changing Web content with a distributed file system: files that contain HTML and XML that are concurrently updated (written) and served to Web clients (read) A good example of such a system is IBM s Olympics web site [27] which uses the DFS file system [19] to replicate changing data like race results at a global scale. The distributed file system takes responsibility for providing synchronized access and consistent views of shared data, shielding Web servers from complexity by moving these tasks into the file system. The file y The work of this ....

....with the scalability and management benefits of a distributed file system without the performance penalty expected from a client server file system. For our distributed file system on a SAN, clients access data directly over the storage area network. Most traditional client server file systems [28, 16, 19, 7] store data on the server s private disks. Clients dispatch all data requests to a server that performs I O on their behalf. Unlike traditional file systems, Storage Tank clients perform I O directly to shared storage devices on a SAN (Figure 1) This direct data access model is similar to the ....

[Article contains additional citation context not shown here]

M. L. Kazar, B. W. Leverett, O. T. Anderson, V. Apostolides, B. A. Bottos, S. Chutani, C. F. Everhart, W. A. Mason, S. Tu, and R. Zayas. DEcorum file system architectural overview. In Proceedings of the Summer USENIX Conference, June 1990.

....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 indicates that path ....

Michael L. Kazar, Bruce W. Leverett, Owen T. Anderson, Vasilis Apostolides, Beth A. Bottos, Sailesh Chutani, Craig F. Everhart, W. Anthony Mason, Shu-Tsui Tu, and Edward R. Zayas. Decorum file system architectural overview. In USENIX Conference Proceedings, pages 151--163. USENIX, June 1990.

....over the storage area network. Most traditional client server file systems (SAN) Storage Area Network Control Network Tape Server Server Server Client Client Client Disk Disk Server Cluster Figure 1: Schematic of the Storage Tank distributed file system on a storage area network (SAN) [24, 13, 15, 6] store data on the server s private disks. Clients function ship all data requests to a server that performs I O on their behalf. Unlike traditional file systems, Storage Tank clients perform I O directly to shared storage devices. This direct data access model is similar to the file system for ....

....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 the same system is more likely than a request from another client to ....

[Article contains additional citation context not shown here]

M. L. Kazar, B. W. Leverett, O. T. Anderson, V. Apostolides, B. A. Bottos, S. Chutani, C. F. Everhart, W. A. Mason, S. Tu, and R. Zayas. DEcorum file system architectural overview. In Proceedings of the Summer USENIX Conference, June 1990.

....Some of my changes may be missing For frequent and systematic sharing of files, a better approach is to use distributed CHAPTER 1. INTRODUCTION 3 file systems, such as Sun Microsystems s NFS [42, 37] Carnegie Mellon University s and IBM s AFS [51, 13, 45] or the DCE Distributed File System [17]. DFSs are usually designed using a client server model. Files and directories are physically located in a server (or a group of servers) The server exports a file system service to its clients. The clients thus can mount the exported file system on local mount points. Once this is done, ....

M. L. Kazar, B. W. Leverett, O.T. Anderson, V. Apostolides, B. A. Bottos, S. Chutani, C. F. Everhart, W. A. Mason, S.-T. Tu, and E. R. Zayas. Decorum File System Architectural Overview. In Proceedings of the Summer 1990 USENIX Technical Conference, June 1990.

....with the scalability and management benefits of a distributed file system, without the performance penalty expected from client server file systems. For our distributed file system on a SAN, clients access data directly over the storage area network. Most traditional client server file systems [29, 20, 16, 7] store data on the server s private disks. Clients function ship all data requests to a server that performs I O on their behalf. Unlike traditional file systems, Storage Tank clients perform I O directly to shared storage devices on a SAN (Figure 1) This direct data access model is similar to ....

....will not be exercised again, or the control network between the server and the computer has partitioned. An isolated computer may be unaware that it is isolated and continue operating on locked data. In many file systems, servers steal locks from unreachable clients to make data highly available [7, 16]. A locking authority steals a lock when it stops honoring a client s lock without notifying the client, and gives a conflicting lock on the same data object to another client in the system. Stealing locks is desirable when client computers become unreachable, because it makes locked data ....

[Article contains additional citation context not shown here]

M. L. Kazar, B. W. Leverett, O. T. Anderson, V. Apostolides, B. A. Bottos, S. Chutani, C. F. Everhart, W. A. Mason, S. Tu, and R. Zayas. DEcorum file system architectural overview. In Proceedings of the Summer USENIX Conference, June 1990.

....or FTP. Among these are decreased server and network load, improved latency, and more complete security. These benefits result from wide area file system support for a global name space, location transparency, client caching, data replication, and access control mechanisms. File systems like DFS [8], AFS [7] and NFS [5] demonstrate to a different degree the viability of the wide area file system paradigm. 2.1 The AFS File System AFS serves 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 ....

M. Kazar, B. Leverett, O. Anderson, V. Apostolides, B. Bottos, S. Chutani, C. Everhart, W. Mason, S. Tu, and E. Zayas. DEcorum File System architectural overview. In Proceedings of the Summer 1990 Usenix Conference, Anaheim, California, June 1990.

....a lowspeed link to greatly increase performance by choosing when to use the limited bandwidth available to perform write operations. Should automated consistency prove valuable in the low speed network environment, Srinivasan and Mogul s work with Spritely NFS [14, 15] and Transarc s work with DFS [16] provide a useful analysis of consistency issues in a delayed write caching system. Formatted October 14, 1994 2 Delayed Write Policy in a Multilevel Cache 3. The Data Our simulations use four sets of file system traces. The first data set was collected from all of the AFS servers in the ....

....instead of the actual data. Either the client or server could request that the actual data be sent at any point: the client might flush dirty data to free up cache space, while the server could request data to enforce consistency. This is similar to the Sprite [3] Spritely NFS [15] and DFS [16] protocols. 6.1. Simulations When using the write hit rate to evaluate client performance in a mass storage system, writes are considered to be hits. However, in low speed network scenarios, some writes must be performed at certain times, e.g. writes necessary to maintain consistency, degrading ....

M. Kazar, B. Leverett, O. Anderson, V. Apostolides, B. Bottos, S. Chutani, C. Everhart, W. Mason, S. Tu, and E. Zayas, "DEcorum File System Architectural Overview," pp. 151-163 in Summer 1990 USENIX Conference Proceedings, Anaheim (June, 1990).

....traffic, and thus cannot guarantee the integrity of data from file systems on which users do not have accounts. Though AFS can be compiled to encrypt network communications to servers on which users have accounts, the commercial binary distributions in widespread use do not offer any secrecy. DFS [14] is a second generation file system, based on AFS, in which a centrally maintained database determines all available file systems. To make the benefits of self certifying pathnames more concrete, consider the following security conundrum posed by AFS. AFS uses password authentication to guarantee ....

Michael L. Kazar, Bruce W. Leverett, Owen T. Anderson, Vasilis Apostolides, Beth A. Bottos, Sailesh Chutani, Craig F. Everhart, W. Anthony Mason, Shu-Tsui Tu, and Edward R. Zayas. DEcorum file system architectural overview. In Proceedings of the Summer 1990 USENIX, pages 151--163, Anaheim, CA, 1990. USENIX.

....tokens and requires a separate token mapping service to convert to and from a canonical over the wire format. We decided not to incorporate this work into NFS Version 3 because of instability in the POSIX ACL specification and the relative immaturity of extant implementations of TNFS. DCE DFS [Kazar90] is related to NFS Version 3 only in that it describes an amount of effort that we clearly did not want to undertake. Our primary goals were to improve NFS Version 2 and deploy a new version quickly. We preferred to retain the ease of server crash recovery, at the expense of not supporting some ....

Kazar, Michael Leon, Leverett et al., "DEcorum File System Architectural Overview," USENIX Conference Proceedings, USENIX Association, Berkeley, CA, Anaheim June 1990. Describes the DCE DFS file system.

No context found.

KAZ 90 Kazar, Leverett et al. DEcorum File System Architectural Overview. Usenix Conference Proceedings, June 1990.

No context found.

Kazar et al., "DEcorum File System Architectural Overview,. of USENIX Summer Conference, Anaheim, California, 1990.

No context found.

M. L. Kazar, B. W. Leverett, O. T. Anderson, V. Apostolides, B. A. Bottos, S. Chutani, C. F. Everhart, W. A. Mason, S. Tu, and R. Zayas. DEcorum file system architectural overview. In Proceedings of the Summer USENIX Conference, June 1990.

First 50 documents

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