John T. Kohl, Carl Staelin, and Michael Stonebraker. HighLight: Using a logstructured file system for tertiary storage management. In Proceedings of the USENIX Winter 1993.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....computing environments requiring many terabytes of storage. File migration to and from slower, cheaper media must be well integrated into the file system. RAMA s data layout on disk is designed to facilitate such migration. While a few other file systems were designed with tertiary storage in mind [11,20], they are not designed for parallel systems. This limits their performance, and makes them unsuitable for use in a scientific computing environment. Tertiary storage is integrated into RAMA via one or more user level storage managers. Whenever a block of data is not found on disk, a tertiary ....

J.T. Kohl, C. Staelin, M. Stonebraker, HighLight: using a log-structured file system for tertiary storage management, in: USENIX, Winter 1993.

....main memory performance and tertiary device access times. For more information on this area, we refer the reader to the proceedings of the IEEE Symposia on Mass Storage Systems and work elsewhere that touches on the integration of tertiary storage systems into an overall storage hierarchy (e.g. [34, 37, 47, 66]) In the next section we discuss the issues and problems in large scale storage. An important set of broad strategic goals are identified in Section 3, and relevant research directions are outlined in Section 4. We make some concluding remarks in Section 5. 2 Storage Challenges To what use is ....

KOHL, J. T., AND STAELIN, C. HighLight: using a log-structured file system for tertiary storage management. In Proceedings of the Winter USENIX Technical Conference (San Diego, CA, January 1993), Usenix Association, Berkeley, CA, pp. 435-447.

....user controlled management of data on tape, and fully integrated approaches in which the DBMS automatically manages data on tape. In this section, we briefly describe the various research projects and their relationship to our research. Tertiary Storage Management The focus of the Highlight [KSS93] and LTS [FM96] projects is the application of log structured file system techniques [RO92] to the management of tertiary storage. Highlight integrates LFS with tertiary storage by allowing the automatic migration of LFS file segments (containing user data, index nodes, and directory files) ....

J. Kohl, C. Staelin and M. Stonebraker. "Highlight: Using a Log-Structured Files System for Tertiary Storage management," Proc. Winter USENIX 1993, pages 435-447, San Diego, CA, January 1993.

....job at hiding multiple layers of storage hierarchy. Some use manual migration and or whole file migration. This is neither convenient nor efficient. Some offer ad hoc extensions to existing systems. This usually increases code complexity. While others have addressed some aspects of the problem [2, 5, 9, 11, 13], there is yet no system that handles both WANs and mass storage. While we do not pretend that we have reached the perfect solution of providing fast, cheap, and reliable wide area access to massive amounts of storage, we present the xFS prototype as a design point from which some of the issues ....

....among different levels of storage. The second is how to lay out data on media in an efficient manner. To solve the problem of locating data in multiple levels of storage, some existing systems extend the UFS data structures to incorporate tertiary devices. For example, a block address in Highlight [9] can belong to the disk farm, some tertiary store, or the disk cache for tertiary storage. Given an hinode number, offseti pair, locating data involves locating the inode and indexing the inode. If the block address is found to be on tertiary, a fetch is done to bring the missing data into the ....

[Article contains additional citation context not shown here]

J. Kohl and C. Staelin. HighLight: Using A Logstructured File System for Tertiary Storage Management. USENIX Association Winter 1993 Conference Proceedings, January 1993.

....one set of parcels is used for log based metadata, the rest are used for in place data update (this is very like Figure 13) LFS [Rosenblum92, Seltzer93] an LFS segment = a parcel; interleaved data and metadata in a log like fashion; parcel cleaning used for garbage collection. HighLight [Kohl93]: like LFS, except that parcels can migrate off to tape, and aggressive colocation cleaners are used to gather data and metadata into a parcel before it is migrated. Cray track based file system: this used sector sized allocation for small files, and track sized allocations for large ones. In ....

John T. Kohl, Carl Staelin, and Michael Stonebraker. HighLight: using a log-structured file system for tertiary storage management. Proceedings of Winter 1993 USENIX (San Diego, CA, 25--29 January 1993), pages 435--47, January 1993.

.... [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 tertiary resident segments ....

John T. Kohl, Carl Staelin, and Michael Stonebraker. HighLight: Using a log-structured file system for tertiary storage management. In Proc. Winter USENIX 1993, pages 435--447, San Diego, CA, January 1993.

....design and implementation of query preexecution and query batching inside Paradise. Section 5 contains a performance evaluation of these techniques. Our conclusions and future research directions are contained in Section 6. 2. Related Work Tertiary Storage Management The focus of the Highlight [14] and LTS [15] projects is the application of log structured file system techniques [16] to the management of tertiary storage. Highlight integrates LFS with tertiary storage by allowing the automatic migration of LFS file segments (containing user data, index nodes, and directory files) between ....

J. Kohl, C. Staelin and M. Stonebraker. "Highlight: Using a Log-Structured Files System for Tertiary Storage management, " Proc. Winter USENIX 1993, pages 435-447, San Diego, CA, January 1993.

....main memory performance and tertiary device access times. For more information on this area, we refer the reader to the proceedings of the IEEE Symposia on Mass Storage Systems and work elsewhere that touches on the integration of tertiary storage systems into an overall storage hierarchy (e.g. [34, 37, 47, 66]) In the next section we discuss the issues and problems in large scale storage. An important set of broad strategic goals are identified in Section 3, and relevant research directions are outlined in Section 4. We make some concluding remarks in Section 5. 2 Storage Challenges To what use is ....

Kohl, J. T., and Staelin, C. HighLight: using a log-structured file system for tertiary storage management. In Proceedings of the Winter USENIX Technical Conference (San Diego, CA, January 1993), Usenix Association, Berkeley, CA, pp. 435--447.

....as a cache for data on tertiary storage. In HP AutoRAID, however, the mirrored storage is not a cache: instead data are moved between the storage classes, residing in precisely one class at a time. This method maximizes the overall storage capacity of a given number of disks. The Highlight system [Kohl et al. 1993] extended LFS to two level storage hierarchies (disk and tape) and also used fixed size segments. Highlight s segments were around 1MB in size, however, and therefore were much better suited for tertiary storage mappings than for two secondary storage levels. Schemes in which inactive data are ....

KOHL, J. T., STAELIN, C., AND STONEBRAKER, M. 1993. HighLight: using a log-structured file system for tertiary storage management. In Proceedings of Winter 1993 USENIX. USENIX Association, Berkeley, Calif., 435--447.

....two levels. Several hierarchical storage systems have used front end disks to act as a cache for data on tertiary storage. In HP AutoRAID, however, the mirrored storage is not a cache: instead data move between the storage classes, residing in precisely one of them at a time. The Highlight system [Kohl93] extended LFS to two level storage hierarchies (disk and tape) and also used fixed size segments. Highlight s segments were around 1MB in size, however, and therefore were much better suited for tertiary storage mappings than for two secondary storage levels. Schemes in which inactive data are ....

....norm, and looking into the issues involved in replaying the current ones we have in a manner that allows us to experiment better with workload variations. Finally, we are also considering how best to extend some of the HP AutoRAID ideas into tertiary storage systems (perhaps in the style of [Kohl93]) Acknowledgments We would like to thank our colleagues in HP s Storage Systems Division, who developed the product version of the HP AutoRAID controller, and were the customers for our performance and algorithmic studies. Many more people put enormous amounts of effort into making this program ....

John T. Kohl, Carl Staelin, and Michael Stonebraker. HighLight: using a log-structured file system for tertiary storage management. Proceedings of Winter 1993 USENIX (San Diego, CA), pages 435--47, 25--29 January 1993.

....main memory performance and tertiary device access times. For more information on this area, we refer the reader to the proceedings of the IEEE Symposia on Mass Storage Systems and work elsewhere that touches on the integration of tertiary storage systems into an overall storage hierarchy (e.g. [34, 37, 47, 66]) In the next section we discuss the issues and problems in large scale storage. An important set of broad strategic goals are identified in Section 3, and relevant research directions are outlined in Section 4. We make some concluding remarks in Section 5. 2 Storage Challenges To what use is ....

Kohl, J. T., and Staelin, C. HighLight: using a log-structured file system for tertiary storage management. In Proceedings of the Winter USENIX Technical Conference (San Diego, CA, January 1993), Usenix Association, Berkeley, CA, pp. 435--447.

....in a number of ways. For example, Burrows et al. describe a method for adding automatic compression that benefits from the large writes [13] The sequential nature and large size of the writes also makes log structured file systems attractive for automatic migration of data to tertiary storage [64]. Finally, the Zebra file system combines ideas from log structured file system and RAID 5 to maintain the file data for a distributed system in a fault tolerant fashion [51] 11 There has been a great deal of work in recent years to improve the flexibility of file systems in order to make it ....

J. Kohl, C. Staelin, and M. Stonebraker. Highlight: Using a log-structured file system for tertiary storage management. In USENIX Winter Conference, pages 435--447. USENIX Association, Jan 1993.

....strategy used. Log structured file systems was introduced by Rosenblum and Ousterhout [11] an idea which has been further developed through the BSD LFS [12] and Spiralog [6, 17] file systems. LFS has also been used as a basis for a high performance RAID [13] and for tertiary storage management [7]. LFS has been used as the basis for two other object managers: the Texas persistent store [14] and as a part of the Grasshopper operating system[5] Both object stores are page based. To our knowledge, there have been no publications on other object based log onlyOODB, based on LFS principles. ....

J. T. Kohl and C. S. M. Stonebraker. HighLight: Using a Log-structured File System for Tertiary Storage Management. In Proceedings of the USENIX Winter 1993 Conference, 1993.

.... I O is used (while mapped file I O results in better performance than Unix I O if the file is on a local disk) We expect this problem to become more extreme in the future as systems become available that transparently provide access to files stored remotely [CH93] and stored in tertiary storage [KSS93] It will be important that the application level library be able to query the source of a file to be able to optimize performance. Finally, our implementation of the stdio putc and getc macros is limited in that they only work correctly if the stream is already in the mode required for the ....

J. Kohl, C. Staelin, and M. Stonebraker. Highlight: Using a log-structured file system for tertiary storage management. In USENIX Winter Conference, pages 435--447. USENIX Association, Jan 1993.

....cleaner policy to not reclaim space from the last version of a file, and the only challenge is finding the old inode. More sophisticated versioning should be only marginally more complicated. Also, the sequential nature of BSD LFS write patterns makes it nearly ideal for tertiary storage devices [KOHL93]. LFS may be extended to include multiple devices in a single file system. If one or more of these devices is a robotic storage device, such as a tape stacker, then the file system may have tremendous storage capacity. Such a file system would be particularly suitable for on line archival or ....

Kohl, J., Staelin, C., Stonebraker, M., "Highlight: Using a Log-structured File System for Tertiary Storage Management," Proceedings 1993 Winter Usenix, San Diego, CA, January 1993.

....cleaner policy to not reclaim space from the last version of a file, and the only challenge is finding the old inode. More sophisticated versioning should be only marginally more complicated. Also, the sequential nature of BSD LFS write patterns makes it nearly ideal for tertiary storage devices [KOHL93]. LFS may be extended to include multiple devices in a single file system. If one or more of these devices is a robotic storage device, such as a tape stacker, then the file system may have tremendous storage capacity. Such a file system would be particularly suitable for on line archival or ....

Kohl, J., Staelin, C., Stonebraker, M., "Highlight: Using a Log-structured File System for Tertiary Storage Management," Proceedings 1993 Winter Usenix, San Diego, CA, January 1993.

....that will manage data in the Bigfoot multi level storage hierarchy. Two of these file systems are academic prototypes, written by Sequoia 2000 researchers, and two are commercial products. All file systems will support a standard UNIX file system interface. The first file system is Highlight [Kohl93]. It is an extension of the Logstructured File System (LFS) pioneered for disk devices by Rosenblum and Ousterhout [Ros92] LFS treats a disk device as a single continuous log onto which newly written disk blocks are appended. Blocks are never overwritten, so a disk device can always be written ....

J. T. Kohl, C. Staelin, and M. Stonebraker. Highlight: using a logstructured file system for tertiary storage management. In USENIX Association Winter 1993 Conference Proceedings, San Diego, January 1993.

No context found.

John T. Kohl, Carl Staelin, and Michael Stonebraker. HighLight: Using a logstructured file system for tertiary storage management. In Proceedings of the USENIX Winter 1993.

No context found.

J. Kohl, C. Staelin, and M. Stonebraker, "HighLight: Using a Log-structured File System for Tertiary Storage Management," Proceedings of the USENIX Winter 1993 Technical Conference (Winter 1993).

No context found.

J. Kohl, "Highlight: Using a Log-structured File System for Tertiary Storage Management," USENIX Association Conference Proceedings (January 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