Deceit: A flexible distributed file system

Deceit, a distributed file system (DFS) being developed at Cornell, focuses on flexible file semantics in relation to efficiency, scalability, and reliability. Deceit servers are interchangeable and collectively provide the illusion of a single, large server machine to any clients of the Deceit service. Non-volatile replicas of each file are stored on a subset of the file servers. The user is able to set parameters on a file to achieve different levels of availability, performance, and one-copy serializability. Deceit also supports a file version control mechanism. In contrast with many recent DFS efforts, Deceit can behave like a plain Sun Network File System (NFS) server and can be used by any NFS client without modifying any client software. The current Deceit prototype uses the ISIS Distributed Programming Environment for all communication and process group management, an approach that reduces system complexity and increases system robustness

Distributed operating systems

In the past five years, distributed operating systems research has gone through a consolidation phase. On a large number of design issues there is now considerable consensus between different research groups.\ud \ud In this paper, an overview of recent research in distributed systems is given. In turn, the paper discusses overall system structure, protection issues, file system designs, problems and solutions for fault tolerance and a mechanism that is rapidly becoming very important for efficient distributed systems design: hints.\ud \ud An attempt was made to provide sufficient references to interesting research projects for the reader to find material for more detailed study

Efficient Synchronous Byzantine Consensus

We present new protocols for Byzantine state machine replication and Byzantine agreement in the synchronous and authenticated setting. The celebrated PBFT state machine replication protocol tolerates $f$ Byzantine faults in an asynchronous setting using $3f+1$ replicas, and has since been studied or deployed by numerous works. In this work, we improve the Byzantine fault tolerance threshold to $n=2f+1$ by utilizing a relaxed synchrony assumption. We present a synchronous state machine replication protocol that commits a decision every 3 rounds in the common case. The key challenge is to ensure quorum intersection at one honest replica. Our solution is to rely on the synchrony assumption to form a post-commit quorum of size $2f+1$, which intersects at $f+1$ replicas with any pre-commit quorums of size $f+1$. Our protocol also solves synchronous authenticated Byzantine agreement in expected 8 rounds. The best previous solution (Katz and Koo, 2006) requires expected 24 rounds. Our protocols may be applied to build Byzantine fault tolerant systems or improve cryptographic protocols such as cryptocurrencies when synchrony can be assumed

You and I are Past Our Dancing Days

Operating systems have grown in size and functionality. Today's many flavours of Unix provide a multi-user environment with protection, address spaces, and attempts to allocate resources fairly to users competing for them, They provide processes and threads, mechanisms for synchronization and memory sharing, blocking and nonblocking system calls, and a complex file system. Since it was first introduced, Unix has grown more then a factor twenty in size. Several operating systems now consist of a microkernel, surrounded by user-space services [Accetta et al., 1986; Mullender et al., 1990; Rozier et al., 1988]. Together they provide the functionality of the operating system. This operating system structure provides an opportunity to make operating systems even larger. The trend for operating systems to grow more and more baroque was signalled more than a decade ago [Feldman, 1980], but has continued unabated until, today, we have OSF/1, the most baroque Unix system ever. And we have Windows/NT as a demonstration that MS-DOS also needed to be replaced by something much bigger and a little better.\ud In this position paper, I am asking what community we serve with our operating systems research. Should we continue doing this, or can we make ourselves more useful to society and industry by using our experience in operating systems in new environments.\ud I argue that there is very little need for bigger and better operating systems; that, in fact, most cPus will never run an operating system at all; and that our experience in operating systems will be better applied to designing new generations of distributed and ubiquitous applications