J. Ousterhout and F. Douglis, "Beating the I/O Bottleneck: A Case for LogStructured File Systems,", ACM Operating System Reviews, Vol. 23, No. 1, pp. 11-28, January 1989.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....of each approach, as well as providing the results of our benchmark measurements. Finally, Section 7 pulls together the major conclusions of the paper. 5 2 RVA and LSA The concept of organizing an entire file system in the form of a log was first proposed by Ousterhout and Douglis in 1989 [OUST89]. In large part, the concept was motivated by a desire to dramatically improve the throughput of I O writes. The authors of [OUST89] argued that traditional methods of performing I O write operations place an excessive, and unnecessary, burden on the physical disks of a storage subsystem. As an ....

....conclusions of the paper. 5 2 RVA and LSA The concept of organizing an entire file system in the form of a log was first proposed by Ousterhout and Douglis in 1989 [OUST89] In large part, the concept was motivated by a desire to dramatically improve the throughput of I O writes. The authors of [OUST89] argued that traditional methods of performing I O write operations place an excessive, and unnecessary, burden on the physical disks of a storage subsystem. As an alternative, Ousterhout and Douglis argued that all writes could be organized into a log, each entry of which is placed into the next ....

J. Ousterhout and F. Douglis, "Beating the I/O Bottleneck: A Case for LogStructured File Systems,", ACM Operating System Reviews, Vol. 23, No. 1, pp. 11-28, January 1989.

....for reducing access latency. Modern file systems generally use large RAM caches to speed up disk accesses. Such caches more effectively reduce read traffic than write traffic, since write requests must be frequently written into disks to protect them from data loss or damage due to system failures [2, 3, 4]. As the RAM size increases rapidly and absorbs more read requests, the proportion of write traffic seen by disk systems will dominate disk traffic and may potentially become a system bottleneck [4] While it is possible to improve the write performance by using Non volatile RAM (NVRAM) cache [2, ....

.... frequently written into disks to protect them from data loss or damage due to system failures [2, 3, 4] As the RAM size increases rapidly and absorbs more read requests, the proportion of write traffic seen by disk systems will dominate disk traffic and may potentially become a system bottleneck [4]. While it is possible to improve the write performance by using Non volatile RAM (NVRAM) cache [2, 5] the write buffer size is usually very small compared to disk capacity because of the high cost of NVRAM 1 . Such a small buffer gets filled up very quickly and can hardly catch the locality of ....

[Article contains additional citation context not shown here]

J. Ousterhout and F. Douglis, "Beating the I/O bottleneck: A case for log-structured file systems," tech. rep., Computer Science Division, Electrical Engineering and Computer Sciences, University of California at Berkeley, Oct. 1988.

....synchronous This research is supported in part by National Science Foundation under Grants MIP 9505601 and MIP 9714370. writes significantly limit the overall system performance. Many techniques have been proposed to speed up synchronous writes. Among them the Log structured File System (LFS) [5, 4, 6] and metadata logging [7] are two well known examples. In LFS, the only data structure on the disk is a log. All writes are first buffered in a RAM segment and logged to the disk when the segment is full. Since LFS converts many small writes into a few large log writes, the overhead associated ....

J. Ousterhout and F. Douglis, "Beating the I/O bottleneck: A case for log-structured file systems, " tech. rep., Computer Science Division, Electrical Engineering and Computer Sciences, University of California at Berkeley, Oct. 1988.

....would show whether users were 43 maintaining their export files adequately, in the case of msh, and whether the filter factor in History was set to the proper value. One problem that has plagued development of this project from the start is the unreliability of the Sprite log file system (LFS) [38]. When we started our final series of tests, we began to experience failures in the file system. The source code for the kernel was not always available because of the file system failures, and therefore, recompilations took an excessive amount of time. Because of this, we have not been able to ....

F. Douglis and J. Ousterhout, "Beating the I/O bottleneck: A case for logstructured files systems," Tech. Rep. UCB/CSD 88/467, Univ. California Berkeley, October 1988. 56

....is constrained by its relatively high cost compared to secondary storage. The second approach is to amalgamate several I O operations into one to amortize the mechanical disk delays over a large transfer. This requires possibly substantial modifications to the file or virtual memory system (e.g. [Ousterhout89]) and can result in less effective utilization of the primary memory cache unless done with care [McVoy91] Furthermore, it is usually not possible to amalgamate synchronous I O operations without impacting I O latency and hence application performance. Although larger main memory caches will ....

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.

....out all nodes with value of count at most i, the resulting number of nodes is less than M . Our implementation used this strategy. There are certain 106 CHAPTER 11. ALPHANUMERIC SELECTIVITY WITH WILDCARDS enhancements to this strategy suggested by cleaning policies in log structured file systems [OuD] that can be used, especially if we observe during the tree building phase that the pruning process is occurring too often; we could prune out more nodes and ensure that a fraction of total memory is unused. In the context of data compression, least recently used based strategies for deciding ....

J. Ousterhout and F. Douglis, "Beating the I/O Bottleneck: A Case for LogStructured File Systems," U. C. Berkeley, UCB/CSD 88/467, October 1988.

....yet little seems to have changed. Although database systems have been using logging to provide atomic updates and fast recovery for decades [Gray78] it is only in the last five years that we have seen the file system community accept logging as an approach for high performance and fast recovery [Ouster89, Kazar90, Chutani92]. Similarly, database management systems have long addressed the problems of distributed access to shared data [Bern81] Operating systems have faced the same problem in providing support for distributed file systems and distributed shared memory. Unfortunately, much of the operating system ....

Ousterhout, J., Douglis, F., "Beating the I/O Bottleneck: A Case for Log-structured File Systems," Operating Systems Review 23, 1, January 1989, 11--27.

....I O other UFS Ficus physical Ficus logical UFS Ficus physical NFS replicas Figure 4.1: The Ficus stack of layers. The left stack provides access to a local replica. The right stack shows the addition of a transport layer to allow remote replica access. 43 systems appears promising [OD88] Because of its interactions with other kernel mechanisms, porting a physical file system from one machine or Unix variant to another can be difficult. If file system layering is used, high level file system features (such as replication, encryption, and compression) can be developed independent ....

John Ousterhout and Fred Douglis. "Beating the I/O Bottleneck: A Case for Log-Structured File Systems." Technical Report UCB/CSD 88/467, Unviversity of California, Berkeley, October 1988.

....remain the same over time, the I O transfer rates of disks are increasing due to more dense information storage on the disk surface. A software system that makes frequent read or write head movements (seeks) when accessing small files on the disk will experience the bottleneck described above [1]. The number of disk transfers needed to complete a transaction is fairly small (e.g. two disk accesses to read a page from a file) but the amount of time spent seeking will dominate the execution time of the whole transaction. Therefore, the data transfer rate of the application is not nearly as ....

....for fast availability. The scheme described above makes all writes sequential while retaining the ability to perform random retrieval. 2 Internal Organization of an LFS 2. 1 Structure of an LFS The structure of an LFS is described by a superblock which is similar to a UNIX Fast File System (FFS, [1]) superblock in that it contains the file system parameters like segment size, number of segments, data block size, etc. The disk is statically partitioned into fixed size segments, typically half a megabyte each. The logical ordering of these segments creates a single, circular log. LFS collects ....

Ousterhout, J., and Douglis, F. "Beating the I/O Bottleneck: A Case for Log-Structured File Systems", ACM SIGOPS, January 1989, pp. 11-28.

....or connecting multiple disks in parallel, as in RAID systems [6] will achieve limited performance improvements, since two of the significant delays the seek and rotational latencies are not improved by such techniques. 3. Synchronous File System Design Requirements As identified by Ousterhout [7], file system write performance can be dramatically improved by re organising the file system so that seeks between data and meta data are not required, and the 5 effect of rotational latencies can be minimised by writing very large amounts of data at a time. In the Sprite log structured file ....

J. Ousterhout and F. Douglis, "Beating the I/O Bottleneck: The Case for Log-Structured File Systems", Operating Systems Review, Jan. 1989.

....logging software [KAZA90] In a UNIX environment, where the vast majority of files are small [OUST85] BAKE91] the seek times between I O requests for different files can dominate. No solutions to this problem currently exist in the context of FFS. The log structured file system, as proposed in [OUST89], attempts to address both of these problems. The fundamental idea of LFS is to improve file system performance by storing all file system data in a single, continuous log. Such a file system is optimized for writing, because no seek is required between writes. It is also optimized for reading ....

....that it is optimized for accessing files that were created or modified at approximately the same time. The write optimization of LFS has the potential for dramatically improving system throughput, as large main memory file caches effectively cache reads, but do little to improve write performance [OUST89]. The goal of the Sprite log structured file system (Sprite LFS) ROSE91] was to design and implement an LFS that would provide acceptable read performance as well as improved write performance. Our goal is to build on the Sprite LFS work, implementing a new version of LFS that provides the same ....

Ousterhout, J., Douglis, F., "Beating the I/O Bottleneck: A Case for Log-structured File Systems, " Operating Systems Review 23, 1, January 1989, 11-27. Also available as Technical Report UCB/CSD 88/467.

....it forces the updates to be processed at disk speeds rather than processor memory speeds [2] As a result, synchronous writes significantly limit the overall system performance. Many techniques have been proposed to speed up synchronous writes. Among them the Log structured File System (LFS) [4, 3, 5] and metadata logging [6] are two well known examples. In LFS, the only data structure on the disk is a log. All writes are first buffered in a RAM segment and logged to the disk when the segment is full. Since LFS converts many small writes into a few large log writes, the overhead associated ....

J. Ousterhout and F. Douglis, "Beating the I/O bottleneck: A case for log-structured file systems," tech. rep., Computer Science Division, Electrical Engineering and Computer Sciences, University of California at Berkeley, Oct. 1988.

....mostly from changing the method of computing mean time to failure and is not expected to continue improving as quickly [Gibson91] Innovation is also taking place in the file system. A good example of how file systems have improved I O system performance is the Log Structured File System (LFS) [Rosenblum91, Ousterhout89]. LFS writes data on the disk in the same order that it is written. This leads to highly sequentialized disk writes and so improves the sustainable disk write throughput. Although the raw performance in storage technology has improved much slower than processor technology, innovation such as file ....

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

....level. As a result, it can be applied directly to current file systems without the need of changing the operating system. 1 Introduction Current disk systems generally use caches to speed up disk accesses. Such disk caches reduce read traffic more effectively than write traffic as shown in [1, 2, 3, 4]. As the RAM size increases rapidly and more read requests are absorbed, the proportion of write traffic seen by disk systems will dominate disk traffic and could potentially become a system bottleneck. In addition, small write performance dominates the performance of many current file systems ....

....for large I O systems. Since attempts in improving the disk subsystem architecture have so far met with limited success for write performance, extensive research has been reported in improving the file systems. The most important work in file systems is the Log structured File System (LFS) [4, 3, 9]. The central idea of an LFS is to improve write performance by buffering a sequence of file changes in a cache and then writing all the modifications to the disk sequentially in one disk operation. As a result, many small and random writes of the traditional file system are converted into a large ....

[Article contains additional citation context not shown here]

J. Ousterhout and F. Douglis, "Beating the I/O bottleneck: A case for log-structured file systems," tech. rep., Computer Science Division, Electrial Engineering and Computer Sciences, University of California at Berkeley, Oct. 1988.

....Trends 2.1 The I O Bottleneck In recent years, systems researchers have begun to highlight the need for improved I O performance. The speed of computations using only primary memory is increasing five to ten times faster than the speed with which blocks on magnetic disk can be accessed [Patterson88, Ousterhout89]. In addition, 2 some new technologies further increase the gap between processor and I O performance. Distributed and wide area [Cate92] file systems slow I O with substantial network transmission and server delays. Portable computers, which frequently spin down their disks and are only weakly ....

Ousterhout, J., Douglis, F., "Beating the I/O Bottleneck: A Case for Log-Structured File Systems," ACM Operating Systems Review, V 23 (1), January 1989, pp. 11-28.

....support in file systems. Historic file system designs have optimized for reading, as read throughput was the I O performance bottleneck. Since increasing main memory cache sizes effectively reduce disk read traffic [BAKER91] disk write performance has become the I O performance bottleneck [OUST89]. This thesis presents both simulation and implementation analysis of the performance of read optimized and write optimized file systems. An example of a file system with a disk layout optimized for writing is a log structured file system, where writes are bundled and written sequentially. ....

....wisdom has been that data is read far more often than it is written, and therefore, files should be allocated sequentially on disk so that they can be read sequentially. However, today s large main memory caches effectively reduce disk read traffic, but do little to reduce write traffic [OUST89]. Anticipating the growing importance of write performance on I O performance and overall system performance, a great deal of file system research is focused on improving write performance. Evidence suggests that as systems become faster and disks and memories become larger, the need to write data ....

[Article contains additional citation context not shown here]

Ousterhout, J., Douglis, F., "Beating the I/O Bottleneck: A Case for Log-structured File Systems," Operating Systems Review 23, 1, January 1989, 11-27. Also published as UCB. technical report UCB/CSD 88/467.

....disk performance and use the disks much more efficiently to reduce the I O bottleneck. This paper describes a disk storage manager designed to use disks as efficiently as possible to support write dominated workloads. The storage manager, called LFS, uses the concepts of log structured file systems[1] to increase the performance of the UNIX file system. In a log structured file system, all modifications to the file system including data, directories, and metadata blocks are written to disk in large, sequential transfers that proceed at maximum disk bandwidth. Small file creation and deletion ....

John K. Ousterhout and Fred Douglis, "Beating the I/O Bottleneck: A Case for Log-structured File Systems," UCB/CSD 88/467, Computer Science Division (EECS), University of California, Berkeley, Berkeley, CA (October 1988).

....flexible. Different implementations of LD can be tailored for different access patterns and different disks can run under different implementations of LD. Similarly, different file systems can all share a particular LD implementation. Third, it allows for efficient solutions to the I O bottleneck [Ousterhout and Douglis 1989; Ousterhout 1990] LD can transparently reorganize the layout of blocks on the disk to reduce access time, similar to other systems that use logical block numbers [Vongsathorn and Carson 1990; Solworth and Orji 1991; English and Stepanov 1992; Aky rek and Salem 1993] Until recently these ....

Ousterhout, J., and Douglis, F., "Beating the I/O Bottleneck: A Case for Log-structured File Systems," Operating Systems Review, Vol. 23, No. 1, pp. 11-28, Jan. 1989.

No context found.

J. Ousterhout and F. Douglis, "Beating the I/O Bottleneck: The Case for Log-Structured File Systems," Operating Systems Review (January 1989).

No context found.

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

No context found.

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

No context found.

Ousterhout, J., and Douglis, F., "Beating the I/O Bottleneck: A Case for Log-Structured File Systems", Operating Systems Review, Vol. 23, No. 1, pp 11-28, 1989.

No context found.

Ousterhout89a. J. Ousterhout and F. Douglis, "Beating the I/O bottleneck: A Case for Log-Structured File Systems", Operating Systems Review 23, 1 (Jan. 1989), 11-28.

No context found.

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

No context found.

Ousterhout, J., Douglis, F., "Beating the I/O Bottleneck: A Case for Log Structured File Systems ", Computer Science Division (EECS), University of California, Berkeley, UCB/CSD 88/467, October 1988.

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