M. Seltzer. Transaction support in a logstructured file system. In Proceedings of the Ninth International Conference on Data Engineering, 1990.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....object store [5] The storage managers in Texas and Grasshopper are page based, i.e. when an object has been modified, the whole page it resides on has to be written back. Similar to these approaches was Seltzer s implementation of transactional support in a log structured file sys3 tem [17]. In her system, locking and updates were performed at page granularity, and all dirty buffers were held in memory until commit. Seltzer s study also included a performance comparison between a conventional system and a log structured system. The results showed that the log structured approach ....

M. Seltzer. Transaction support in a logstructured file system. In Proceedings of the Ninth International Conference on Data Engineering, 1990.

....use of process groups as a form of coherently replicated cache to accelerate access to a database. The idea can be understood as a synthesis of Liskov s work on the Harp file system [LGGJ91] the author s work on Isis [BR94] and research by Seltzer and others on log structured database systems [Sel93]. However, this author is not aware of any publication in which the contributions of these disparate systems are unified. To understand the motivation for this work, it may help to briefly review the normal approach to replication in database systems. As was noted earlier, one can replicate a ....

....the state of the database could be constructed by loading the checkpoint and then applying the updates to it; if the log were to grow too long, it could be truncated by forming a new checkpoint. This isn t an unusual way to actually view database systems: Seltzer s work on log structured databases [Sel93] in fact implemented a database this way and demonstrated some performance benefits by doing so, and Liskov s research on Harp (a non transactional file store that was implemented using a log based architecture) employed a similar idea, albeit in a system with non volatile RAM memory. Indeed, ....

[Article contains additional citation context not shown here]

Margo Seltzer. Transaction Support in a Log-Structured File System. Proceedings 9th International Conference on Data Engineering. 1993.

....other remote Queue Managers for reliable agent transmission. The Queue Manager design goals centered on achieving optimal disk space utilization, fast write operations, and fast recovery from server failure. Its implementation borrowed some ideas from the log structured file systems research area [19,20] to employ a unique data architecture which ensures better overall performance over traditional message queuing systems [6,8,16] The preservation of Mitsubishi Electric ITA 4 02 28 97 an object s class specification on disk is handled by the Java object serialization facilities while Queue ....

M. Seltzer, "Transaction Support in a Log-Structured File System", In Proceedings of the Ninth International Conference on Data Engineering, February, 1993.

.... performance [2] Subsequent work re evaluated LFS and concluded that, with garbage collection, the performance of LFS on secondary storage is only comparable to conventional file systems [5, 6, 7] With transaction processing workloads, in particular, the throughput of LFS is lower than expected [8]. HighLight [9] a tertiary storage extension of BSD LFS, is a first attempt in combining LFS with tertiary storage. HighLight migrates segments of user data and meta data from secondary storage to tertiary storage. Read only copies of segments can be cached on secondary storage, and ....

Margo I. Seltzer. Transaction support in a logstructured file system. In Proc. IEEE Data Engineering, pages 503--510, Vienna, Austria, February 1993.

....the cleaner is part of the kernel and implements a single cleaning policy. There are three problems with this, in addition to the memory issues discussed in Section 3.1. First, there is no reason to believe that a single cleaning algorithm will work well on all workloads. In fact, measurements in [SELT93b] show that coalescing randomly updated files would improve sequential read performance dramatically. Second, placing the cleaner in kernelspace makes it difficult to experiment with alternate cleaning policies. Third, implementing the cleaner in the kernel forces the kernel to make policy ....

....pages 218 1993 Winter USENIX January 25 29, 1993 San Diego, CA Seltzer et al. An Implementation of a Log Structured File System for UNIX exist in the file system until they are reclaimed by the cleaner. An implementation that exploits these two characteristics is described and analyzed in [SELT93b] on Sprite LFS, and we plan on doing a prototype implementation of transactions in BSDLFS. The no overwrite characteristic of BSD LFS makes it ideal for supporting unrm which would undo a file deletion. Saving a single copy of a file is no more difficult than changing the cleaner policy to not ....

Seltzer, M., "Transaction Support in a Log-Structured File System," To appear in the Proceedings of the 1993 International Conference on Data Engineering, Vienna, Austria, April 1993.

....the cleaner is part of the kernel and implements a single cleaning policy. There are three problems with this, in addition to the memory issues discussed in Section 3.1. First, there is no reason to believe that a single cleaning algorithm will work well on all workloads. In fact, measurements in [SELT93] show that coalescing randomly updated files would improve sequential read performance dramatically. Second, placing the cleaner in kernel space makes it difficult to experiment with alternate cleaning policies. Third, implementing the cleaner in the kernel forces the kernel to make policy ....

....in multi user transaction applications, if sufficient disk space is available. Second, since data is never overwritten, before images of updated pages exist in the file system until reclaimed by the cleaner. An implementation that exploits these two characteristics is described and analyzed in [SELT93] on Sprite LFS, and we plan on doing a prototype implementation of transactions in BSD LFS. The no overwrite characteristic of BSD LFS makes it ideal for supporting unrm which would undo a file deletion. Saving a single copy of a file is no more difficult than changing the cleaner policy to not ....

Seltzer, M., "Transaction Support in a Log-Structured File System," To appear in the Proceedings of the 1993 International Conference on Data Engineering, April 1993, Vienna.

....the TPC B transaction processing benchmark. 4 Transaction Processing Performance Although LFS was designed for a UNIX time sharing workload, there has been speculation that the ability to convert small, random I Os into large sequential ones would make it ideal for transaction processing [11]. Seltzer et al. measured a modified TPC B implementation and found that the cleaning overhead severely limited its performance. The disk was 80 full in the benchmark configuration. In this section, we examine the performance of the same benchmark across a range of file system utilizations, since ....

Seltzer, M., "Transaction Support in a Log-Structured File System," Proceedings of the Ninth International Conference on Data Engineering, Vienna, Austria, April 1993.

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