John K. Ousterhout and Fred Douglis. Beating the I/O bottleneck: A case for log-structured file systems. Technical Report UCB/CSD 88/467, Computer Science Division (EECS), University of California, Berkeley, October 1988.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....(FFS) including mechanisms to increase locality within les. CARD95] and [OXMA95] explained the Extended 2 File System (E2FS) and its improvements over the FFS through minor changes to the layout strategy and introduction of block groups. Based on the claim that disk performance is write bound, [OUST89] and [ROSE92] designed and implemented the Log Structured File System (LFS) which optimized write operations by viewing the le system as an appendable log. CAO95] described some of the pitfalls of employing prefetching in a system with a cache, and outlined four properties that optimal ....

J. Ousterhout and F. Douglis, Beating the I/O Bottleneck: A Case for Log-Structured File Systems, in Operating Systems Review Vol. 23(1), pages 11-28, January 1989.

....1.1.1 The growing I O gap A significant trend faced by file server designers is the growing I O gap. CPU performance, network bandwidth, and primary and secondary storage density are increasing exponentially, but the access times and transfer rates of secondary storage are failing to keep pace [Ousterhout89, Wilkes90]. In fact, the access time to newer media such as magneto optical disk is longer than preceding technology. This I O gap is aggravated by other factors. As computer networks become increasingly common, file servers must handle the workloads of increasing numbers of systems. Also, growing use of ....

....that aggressively optimizes file system performance. Second, as the density of primary storage increases, designers can use larger file caches, both at the server and the client. Large file caches have already proven effective, and researchers are calling for even larger caches in the future [Ousterhout89]. 6 1.1.2 The proliferation of storage media Another trend faced by file system designers is the proliferation of secondary storage media types. Ten years ago, most files were stored on two media: magnetic disk and tape. Today, files are stored on more types of media, including flash RAM, ....

[Article contains additional citation context not shown here]

John Ousterhout and Fred Douglis. Beating the I/O bottleneck: a case for log-structured file systems. Operating Systems Review, 23(1):11--27, January 1989.

....one or more companion Stable Memories, plus a large array of disks (see Figures 6.4 and 6. 5) The Stable Disk is principally designed for a streaming environment, where data flows to and from disk in large blocks, such as wouldbe the case when using RAID 3 with a Log Structured Filesystem (LFS) Ousterhout et al. 88, Ousterhout et al. 89] It is also designed to be integrated into the FASST recovery protocol. Figure 6.4: Stable Disk : RAID Controller and Stable Memory Figure 6.5: Stable Disk : RAID Chassis and Corollary host 6.4 RAID Controller for the Stable Disk Figure 6.6 illustrates the low level ....

OUSTERHOUT, J.K., AND DOUGLIS, F. Beating the I/O Bottleneck: A Case for LogStructured FileSystems. Report No.UCB/CSD 88/467, University of California, 1988.

....disk reliability can be improved by using uniform encoding techniques to recover from device failures. Unfortunately, this approach does not work well with small random accesses, which occur when accessing many small files. A completely different approach is used by the log structured file system [84, 94]. This file system consists entirely of a database like log. In conjunction with a large cache, this approach offers high write performance because devices rarely seek and writes operate near device limits by writing large blocks. This approach improves write performance by (potentially) ....

J. Ousterhout and F. Douglis. Beating the I/O bottleneck: a case for log-structured file systems. ACM Operating Systems Review, 23(1):11--28, Jan. 1989.

....all seeks during write operations. Other advantages include faster crash recovery, file versioning and automatic clustering of files written at the same time. The main disadvantage is the performance overhead of traversing a log to replay a file during a read operation. A proposed solution in [Ousterhout84] relies on indexing different parts of the log with log map blocks to facilitate random access of the log and a large cache to satisfy most read operations. A file system must support one or more of the above file types. Often, only one type is made available to the user, but the use of more than ....

John Ousterhout and Fred Douglis. Beating the I/O Bottleneck: A Case for Log-Structured File Systems. Technical Report UCB/CSD 88/467, University of California at Berkeley, October 1984. (p 41)

....majority of files are written exactly once in their entirety, and that most files are fairly short lived. By implementing a file system where the only disk write operation permitted is to append to a log, a large fraction of the seek overheads of a block structured file system may be eliminated [Ousterhout89]. The addition of a cache allows most reads to be serviced from memory and in addition means than most short lived temporary files never need to hit the disk. The log is periodically compacted to remove old and deleted file data by a background process similar to a garbage collector. 4 The time ....

John Ousterhout and Fred Douglis. Beating the I/O bottleneck: A case for log-structured file systems. ACM Operating Systems Review, 23(1):11--28, January 1989. (p 95)

....of earlier UNIX file systems that places new file blocks to optimize for sequential file access. It attempts to optimize block placement by trying to place blocks of a file together so that they are in rotationally optimal positions on the same cylinder. Log structured file systems (LFS) [Ousterhout89, Rosenblum92] These types of file systems attempt to improve file system performance by storing all file system data in a single, continuous log. Because the data is written in a continuous log, there is no seek required between writes. Therefore, the file system is optimized 209 for writing. The log has an ....

John Ousterhout and Fred Douglis. Beating the I/O bottleneck: a case for log-structured file systems. Operating Systems Review, 23(1):11--27, January 1989.

....CA. 1 Introduction In many computing systems, the disk I O subsystem is often identified as the major bottleneck to system performance. During the past several years, CPU speeds have increased at a rate of 40 to 100 per year [1, 13] whereas disk seek times have only improved by 7 per year [11, 32]. This has led to a big gap between the speed of the CPU main memory and that of the disk I O subsystem [30] which is expected to increase further in the near future. Based on these observations, we predict that further increases in the processor speed will bring little gain to the overall system ....

....advantage of reducing seek times. Last, from the above studies, we observe that the main impact on the performance of RAID 5 is the high cost of the partial stripe write. Researchers have looked at different ways to reduce this cost. The most attractive way is the Log Structured File System [32, 9, 38, 39], in which many small writes are accumulated in cache and converted into a large full stripe write. Another way is called floating parity [24] where parity blocks are clustered into cylinders each containing a spare track. A new parity block, instead of being written in place, is written on the ....

Ousterhout, J. K. and Douglis, F. Beating the I/O bottleneck: A case for log-structured file systems. Operating System Rev., 23(1):11--28, Jan. 1989.

....typically access large files sequentially (Kotz, 1992) 2.1.2 Transaction System Store Typical transaction systems include automatic bank teller and airline reservation systems. The access in these systems usually comprises a large number of concurrent requests operating on small data items (Ousterhout Douglis, 1989). The operations are typically of short duration and require a fast response time (Yoo Rogers, 1993) The data involved in each operation is usually distinct from that in other, concurrent, operations. For example, in a bank teller system it would be unusual for two operations on the same ....

....et al. 1988; Tanenbaum et al. 1990; Leffler et al. 1989) As RAM becomes cheaper, large main memories will become commonplace. The resultant increase in cache size will enable the cache to satisfy a greater proportion of read requests as more of the hot 7 data can reside in the cache (see Ousterhout and Douglis (1989) for supporting evidence) Write performance will begin to dominate the I O system performance because dirty 8 data must be written to a permanent storage device to prevent the loss of data if the system crashes or the power fails. Block Replacement Policies Associated with a cache is a cache ....

[Article contains additional citation context not shown here]

Ousterhout, J.K, & Douglis, F. 1989. Beating the I/O Bottleneck: A Case for Log-Structured File Systems. ACM SIGOPS, 23(1), 11--28.

....with fast file insertion, disk directed I O [26] and application specific persistence. 1.1 Problem and Motivation CPU speed, network bandwidth, and primary and secondary storage capacities have increased rapidly over the last decade. At the same time, disk access times have only improved slowly [36, 38]. Disk I O now presents a major bottleneck in many computer systems and will most likely continue to do so [43] This gap between the performance of the main computer system and the speed of disk access is further exacerbated by changing computer usage in increasingly networked computing ....

John Ousterhout and Fred Douglis. Beating the I/O bottleneck: A case for logstructured file systems. Operating Systems Review, 23(1):11--28, January 1989.

....of buffering writes in memory before batching them together to send to the server. Here, the reliability of writes can be improved by 12 using either of the mechanisms. For infrequent writes, flush( may be more suitable while for a rapid sequence of writes, log( may be more appropriate [Ousterhout, 88] Now consider a client that needs the extra reliability not provided by the default implementation. A client can implement a different policy like persistence upon return from write or log before write using the subsystem provided mechanisms. Such policies can be obtained by a client through ....

J. Ousterhout & F. Douglis, Beating the I/O Bottleneck: A Case for LogStructured File Systems, Technical Report No. UCB/CSD 88/467, Computer Sciences Division, University of California, Bekeley, CA.

....owning the parcel could be supported. One reason for supporting variable sized slots is to allow data compression as chunks are written into parcels. In this case, slot sizes will be determined by the size and compressibility of the contents of the associated chunk. Log structured like techniques [Ousterhout89, Rosenblum92, Burrows92a] will have to be used to handle data overwrites, since a chunk with new data may be larger than the slot originally assigned to it. 3.3.4 Hierarchy managers Parcels can be moved between cartons in order to implement a storage management policy. Typically, the goal of such a policy is to maximize ....

John Ousterhout and Fred Douglis. Beating the I/O bottleneck: a case for logstructured file systems. Operating Systems Review, 23(1):11--27, January 1989.

....of the some of the performance aspects of the system. In Section 5, we discuss garbage collection strategies. In Section 6, we examine write and read performance. 2 Related Work The idea of a log structured file system (LFS) for secondary storage was first suggested by Ousterhout and Douglis [1]. They observed that large mainmemory caches tended to reduce the number of reads more than writes, causing I O traffic to become write dominated. The log organization, found in database management systems, inspired a technique for implementing a write optimized file system that would compensate ....

John K. Ousterhout and F. Douglis. Beating the I/O bottleneck: A case for log-structured file systems. Oper. Syst. Rev., 23(1):11--27, January 1989.

....the majority of files are written exactly once in their entirety and that most files are fairly short lived. By implementing a file system where the only disk write operation permitted is to append to a log, a large fraction of the seek overheads of a block structured filesystem may be eliminated [9]. It cannot be stressed enough that the above observations are highly unix specific. The addition of a cache allows most reads to be serviced from memory and in addition means than most short lived temporary files never need to hit the disk. The log is periodically compacted to remove old and ....

John Ousterhout and Fred Douglis. Beating the I/O Bottleneck: A Case for Log-Structured File Systems. ACM Operating Systems Review, 23(1):11--28, January 1989.

....implement finegranularity locking for concurrent transactions, media recovery, and a number of other desired features. Shadow paging has recently become more competitive due to development in disk and main memory technologies. By combining several techniques, such as log structured file systems [9, 11, 12], striping [12, 15] mirroring [10] shadow updates [1] and group commit [5] the performance of shadow paging can now be made to compete with the best log based systems. New algorithms have been developed to implement other desired features, such as fast snapshots (transaction consistent copies ....

....sequential writes. Sequential writes are only possible if there is sufficient contiguous free space on disk. Without any countermeasures, free space will quickly get fragmented, and no large contiguous regions will exist. We do space management much in the same way as log structured file systems [9, 11]: we divide the disk space into fixed size segments, and have a separate thread actively cleaning up segments. Any pages that the cleanup thread wishes to move are made part of the next page table level transaction (i.e. copied to new locations without actually changing them) and they will be ....

J. Ousterhout and F. Douglis. Beating the I/O bottleneck: A case for log-structured file systems. ACM Operating Systems Review, 23(1):11--28, 1989.

....by Crockett [2] Although he did not study an actual workload, he related file access patterns to possible storage techniques. Many of his basic file access patterns are reflected in our workload model. We concentrate on scientific workloads, characterized by sequential access to large files [13, 11]. Despite the lack of any parallel file access study, we expect there to be enough sequential access in the parallel file access patterns of scientific applications for prefetching policies that assume sequential access to be successful. 3 Models and Methods Our methodology is experimental, ....

John Ousterhout and Fred Douglis. Beating the I/O bottleneck: A case for log-structured file systems. ACM Operating Systems Review, 23(1):11-- 28, January 1989.

....suggest that neither accuracy nor modeling ease need be sacrificed. The Log structured File System is a file system whose performance characterization has evolved as more detailed models and simulations have been developed. We use it here as an example of how this process works. The earliest study[14] predicted a ten fold improvement in performance based on a simple model that was based on micro benchmarks. A subsequent study[16] using synthetic workloads provided improved accuracy, but over estimated the cost of the segment cleaner by comparison with later measurements using a more realistic ....

John K. Ousterhout and Fred Douglis. Beating the I/O bottleneck: A case for log-structured file systems. Operating System Review, 23(1):11--27, January 1989.

.... 6 Procedure to Build a Syntax Tree PROCEDURE BuildQuery ; VAR n: Queries.Node; BEGIN n : Query.Intersection(PubPapers, LatexDocs) n : Query.RR(writes, n) n : Query.Domain(n) END BuildQuery; 5 Overview of the Implementation The persistent store is implemented using the log principle [3]. Each time an object is written to the store, a new space is allocated and the object is written in this new space. In other words, an object is never changed in place but always completely rewritten. With this mechanism, the system is very robust because every operation can be undone allowing ....

J. Ousterhout and F. Douglis. Beating the I/O bottleneck: A case for log-structured file systems. ACM Operating Systems Review, 23(1):11--28, January 1989. Also appears as University of California, Berkeley, Technical Report UCB/CSD 88/467.

....of standard UNIX shell commands without requiring any changes to them. Another extension was the implementation of a log structured file system by two sets of students in an operating systems class. 1 Both sets of students demonstrated working prototypes of the file system proposed in [OD89] The file system framework allowed them to concentrate 1 The class, CS323, was taught at the University of Illinois in the Fall of 1989 by Professor Ralph Johnson. on the novel aspects of the proposed system and to reuse much of the code that normally would need to be rewritten in ....

John Ousterhout and Fred Douglis. Beating the I/O Bottleneck: A Case for LogStructured File Systems. Operating Systems Review, 23(1):11--28, January 1989.

No context found.

John K. Ousterhout and Fred Douglis. Beating the I/O bottleneck: A case for log-structured file systems. Technical Report UCB/CSD 88/467, Computer Science Division (EECS), University of California, Berkeley, October 1988.

No context found.

OUSTERHOUT, J., AND DOUGLIS, F. Beating the I/O bottleneck: A case for log-structured file systems. Tech. Rep. UCB/CSD 88/467, Computer Science Division, Electrical Engineering and Computer Sciences, University of California at Berkeley, Berkeley, CA 94720, Oct. 1988.

No context found.

John Ousterhout, Fred Douglis. Beating the I/O Bottleneck: A case for Log-Structured File Systems. Operating Systems Review, 23(1), pp. 11-28, 1989.

No context found.

John Ousterhout and Fred Douglis. Beating the I/O bottleneck: a case for log-structured file systems. Operating Systems Review 23(1):11-- 27, January 1989.

No context found.

Ousterhout, J. and Douglis, F. Beating the I/O Bottleneck: A Case for Log-structured File Systems. Technical Report UCB/CSD 88/467 (Oct. 1988).

No context found.

John Ousterhout and Fred Douglis. Beating the I/O bottleneck: A case for logstructured file systems. Operating Systems Review, 23(1):11--27, January 1989.

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