DOCSLIB.ORG

Informed Prefetching and Caching

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Informed Prefetching and Caching Informed Prefetching and Caching Russel Hugo Patterson III December 1997 CMU-CS-97-204 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Submitted in partial fulfillment of the requirements for the degree Doctor of Philosphy in Electrical and Computer Engineering Thesis Committee: Garth A. Gibson, Chair Mahadev Satyanrayanan Daniel P. Siewiorek F. Roy Carlson, Quantum Corporation © 1997 by Russel Hugo Patterson III This research was supported in part by Advanced Research Projects Agency contracts DABT63-93- C-0054 and N00174-96-0002, in part by the Data Storage Systems Center under National Science Foundation grant number ECD-8907068, in part by an IBM Graduate Fellowship, and in part by generous contributions from the member companies of the Parallel Data Consortium: Hewlett- Packard Laboratories, Symbios Logic, Data General, Compaq, IBM Corporation, Seagate Technol- ogy, EMC Corporation, Storage Technology Corporation, and Digital Equipment Corporation. The views and conclusions contained in this document are my own and should not be interpreted as rep- resenting the official policies, either expressed or implied, of any supporting organization or the U.S. Government. Keywords: prefetching, caching, file systems, resource management, cache management, TIP, I/O, cost-benefit analysis, economic markets, disk arrays, RAID For Lee Ann v Abstract Disk arrays provide the raw storage throughput needed to balance rapidly increasing pro- cessor performance. Unfortunately, many important, I/O-intensive applications have serial I/O workloads that do not benefit from array parallelism. The performance of a single disk remains a bottleneck on overall performance for these applications. In this dissertation, I present aggressive, proactive mechanisms that tailor file-system resource management to the needs of I/O-intensive applications. In particular, I will show how to use application- disclosed access patterns (hints) to expose and exploit I/O parallelism, and to dynamically allocate file buffers among three competing demands: prefetching hinted blocks, caching hinted blocks for reuse, and caching recently used data for unhinted accesses. My approach estimates the impact of alternative buffer allocations on application elapsed time and applies run-time cost-benefit analysis to allocate buffers where they will have the greatest impact. I implemented TIP, an informed prefetching and caching manager, in the Digital UNIX operating system and measured its performance on a 175 MHz Digital Alpha workstation equipped with up to 10 disks running a range of applications. Informed prefetching on a ten-disk array reduces the wall-clock elapsed time of computational physics, text search, scientific visualization, relational database queries, speech recogni- tion, and object linking by 10-84% with an average of 63%. On a single disk, where stor- age parallelism is unavailable and avoiding disk accesses is most beneficial, informed caching reduces the elapsed time of these same applications by up to 36% with an average of 13% compared to informed prefetching alone. Moreover, applied to multiprogrammed, I/O-intensive workloads, TIP increases overall throughput. vi vii Acknowledgments First, I would like to thank my advisor, Garth Gibson, for all the help, guidance, and advice he has given me. He has spent many long hours teaching me how to do systems research. Throughout, he has been a tireless advocate of excellence, and this document is much better for it. He has also provided a huge amount of support. I am particularly grate- ful for the way he anticipated my needs as I started work on cost-benefit resource manage- ment and ensured that all the other components, including benchmark applications, programming assistance, and a hardware platform, were in place when I needed them. He let me focus on what I could do best and, by providing what I could not, guaranteed the success of the project. Beyond that specific support, in founding the Parallel Data Lab, Garth has created a wonderful environment for systems research, and pulled together an impressive group of staff and students. I feel lucky to have been a member of the Lab. For all of this, and for being such a good sport when I couldn’t resist teasing him, I thank him. I would like to thank Satya for his help and advice throughout. Recently, I had the opportunity to review some notes of our early meetings. I now realize that at the time I only understood a fraction of our discussions. Still, some if it sank in. I thank him for help- ing me understand the key problem and develop a solution to it. Thanks are also due to the other members of my thesis committee. I thank Rick Carl- son for his patience as I finished up. I look forward to continuing to work with him at Quantum as I make the transition to the real world. I am very grateful to Dan Siewiorek who gallantly joined the committee at the last minute and read the dissertation on short notice. viii I’d also like to thank the many faculty that provided early guidance and support including Dave Lambeth, Stan Charap, Onat Menzilcioglu, H.T. Kung, and Sandro Forin. They all patiently endured many long meetings with me and helped me find my way when I was a newcomer to the field of I/O systems research. I am particularly indebted to Jim Zelenka for his tireless efforts debugging and improving the raw TIP code I threw over the wall to him during the crush to produce the SOSP paper. He has an uncanny ability to track down kernel bugs which I gave him many opportunities to exercise. I am fortunate to have both benefited and learned from this skill. I am also deeply grateful to Danner Stodolsky who helped optimize both the first and sec- ond TIP prototypes, annotated Sphinx and Gnuld to give hints, and spent many a sleepless night running experiments and helping in other ways to get the SOSP paper out the door. Both Danner and Jim helped with many constructive conversations about the TIP design and implementation. Many thanks to them both. A number of other students also helped me in my research along the way and I would like to thank each of them. Eka Ginting annotated Postgres to give hints and helped with other aspects of the SOSP paper. Mark Holland set me up with RAIDSim which was the foundation of the simulation environment for TIPTOE. And, Jiawen Su investigated asyn- chronous name resolution in TIP and ported the first TIP prototype to Digital UNIX. I would like particularly to thank Andrew Tomkins for taking up the problem of deep prefetching and becoming such an energetic collaborator on the TIP project. His work developing TIPTOE extended TIP in a significant and exciting way. Without him, the OSDI and Sigmetrics papers would never have existed, and the TIP project would not have been nearly as complete. Writing a dissertation requires more than just research, and I am grateful to the many folks who helped me keep my senses of perspective and humor over the years. Peter Stout, besides answering my endless computer questions, provided a fine example of how it should be done. He also taught me how to drink coffee in large quantities. In the later years, David Steere and Brian Noble were always ready with a humorous diversion even when the slogging seemed slow and endless. Thanks too to Patty Mackiewicz who helped with many practical problems and always looked out for me. But, more importantly, she found a way to make me smile even in the face of adversity. ix None of this would have been possible without my parents. I thank them for the many years of love and support that first prepared me to undertake this work and then so eased my way during the long travail. Finally, I would like to thank Lee Ann who first encouraged me to go back to school and pursue an advanced degree. That pursuit turned into a task larger than either of us ever imagined and demanded sacrifices neither of us anticipated. Lee Ann generously made those sacrifices and supported me throughout. When times were good, she cheered and shared in my joy. When times were tough, she cheered me up and gave me strength. Lee Ann has been there for me in these and many other ways I’m sure I cannot even imagine. I am deeply and forever grateful. As a small sign of my appreciation, I dedicate this disser- tation to you. Hugo Patterson Pittsburgh, Pennsylvania December, 1997 x xi Table of Contents List of Figures . .xv List of Tables . xvii List of Equations . xix 1 Introduction . 1 2 Asynchrony + Throughput = Low Latency . 7 2.1 Disk drive performance characteristics. 9 2.2 ASAP: the four virtues for I/O workloads . 12 2.2.1 Avoiding accesses avoids latency . 13 2.2.2 Increasing sequentiality increases channel utilization . 16 2.2.3 Asynchrony masks latency . 21 2.2.4 Parallelizing I/O workloads increases array utilization . 24 2.2.5 ASAP summary . 26 2.3 Disclosure hints for aggressive prefetching and I/O parallelism . 27 2.4 Related work . 31 2.5 Conclusions. 34 3 Disclosing I/O Requests in Hints . 37 3.1 Hints that disclose. 38 3.2 The hint interface . 41 3.3 Annotation techniques . 44 3.3.1 In-line hinting. 45 3.3.2 Loop duplication . 45 3.3.3 Loop splitting. 46 3.4 Annotating applications to give hints . 47 3.4.1 Agrep . 47 3.4.2 Gnuld . 48 3.4.3 Postgres . 49 3.4.4 Davidson . 51 3.4.5 XDataSlice . 52 3.4.5.1 XDataSlice organization . 53 3.4.5.2 Extending HDF to disclose hints to TIP .
Load more

Recommended publications
  • Memory Deduplication: An
    1 Memory Deduplication: An Effective Approach to Improve the Memory System Yuhui Deng1,2, Xinyu Huang1, Liangshan Song1, Yongtao Zhou1, Frank Wang3 1Department of Computer Science, Jinan University, Guangzhou, 510632, P. R. China {[email protected]；[email protected]；[email protected]；[email protected]} 2Key Laboratory of Computer System and Architecture, Chinese Academy of Sciences Beijing, 100190, PR China 3 School of Computing，University of Kent, CT27NF, UK [email protected] Abstract— Programs now have more aggressive demands of memory to hold their data than before. This paper analyzes the characteristics of memory data by using seven real memory traces. It observes that there are a large volume of memory pages with identical contents contained in the traces. Furthermore, the unique memory content accessed are much less than the unique memory address accessed. This is incurred by the traditional address-based cache replacement algorithms that replace memory pages by checking the addresses rather than the contents of those pages, thus resulting in many identical memory contents with different addresses stored in the memory. For example, in the same file system, opening two identical files stored in different directories, or opening two similar files that share a certain amount of contents in the same directory, will result in identical data blocks stored in the cache due to the traditional address-based cache replacement algorithms. Based on the observations, this paper evaluates memory compression and memory deduplication. As expected, memory deduplication greatly outperforms memory compression. For example, the best deduplication ratio is 4.6 times higher than the best compression ratio.
    [Show full text]
  • Oracle® Linux Administrator's Solutions Guide for Release 6
    Oracle® Linux Administrator's Solutions Guide for Release 6 E37355-64 August 2017 Oracle Legal Notices Copyright © 2012, 2017, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S.
    [Show full text]
  • Murciano Soto, Joan; Rexachs Del Rosario, Dolores Isabel, Dir
    This is the published version of the bachelor thesis: Murciano Soto, Joan; Rexachs del Rosario, Dolores Isabel, dir. Anàlisi de presta- cions de sistemes d’emmagatzematge per IA. 2021. (958 Enginyeria Informàtica) This version is available at https://ddd.uab.cat/record/248510 under the terms of the license TFG EN ENGINYERIA INFORMATICA,` ESCOLA D’ENGINYERIA (EE), UNIVERSITAT AUTONOMA` DE BARCELONA (UAB) Analisi` de prestacions de sistemes d’emmagatzematge per IA Joan Murciano Soto Resum– Els programes d’Intel·ligencia` Artificial (IA) son´ programes que fan moltes lectures de fitxers per la seva naturalesa. Aquestes lectures requereixen moltes crides a dispositius d’emmagatzematge, i aquestes poden comportar endarreriments en l’execucio´ del programa. L’ample de banda per transportar dades de disc a memoria` o viceversa pot esdevenir en un bottleneck, incrementant el temps d’execucio.´ De manera que es´ important saber detectar en aquest tipus de programes, si les entrades/sortides (E/S) del nostre sistema se saturen. En aquest treball s’estudien diferents programes amb altes quantitats de lectures a disc. S’utilitzen eines de monitoritzacio,´ les quals ens informen amb metriques` relacionades amb E/S a disc. Tambe´ veiem l’impacte que te´ el swap, el qual tambe´ provoca un increment d’operacions d’E/S. Aquest document preten´ mostrar la metodologia utilitzada per a realitzar l’analisi` descrivint les eines i els resultats obtinguts amb l’objectiu de que serveixi de guia per a entendre el comportament i l’efecte de les E/S i el swap. Paraules clau– E/S, swap, IA, monitoritzacio.´ Abstract– Artificial Intelligence (IA) programs make many file readings by nature.
    [Show full text]
  • Strict Memory Protection for Microcontrollers
    Master Thesis Spring 2019 Strict Memory Protection for Microcontrollers Erlend Sveen Supervisor: Jingyue Li Co-supervisor: Magnus Själander Sunday 17th February, 2019 Abstract Modern desktop systems protect processes from each other with memory protection. Microcontroller systems, which lack support for memory virtualization, typically only uses memory protection for areas that the programmer deems necessary and does not separate processes completely. As a result the application still appears monolithic and only a handful of errors may be detected. This thesis presents a set of solutions for complete separation of processes, unleash- ing the full potential of the memory protection unit embedded in modern ARM-based microcontrollers. The operating system loads multiple programs from disk into indepen- dently protected portions of memory. These programs may then be started, stopped, modified, crashed etc. without affecting other running programs. When loading pro- grams, a new allocation algorithm is used that automatically aligns the memories for use with the protection hardware. A pager is written to satisfy additional run-time demands of applications, and communication primitives for inter-process communication is made available. Since every running process is unable to get access to other running processes, not only reliability but also security is improved. An application may be split so that unsafe or error-prone code is separated from mission-critical code, allowing it to be independently restarted when an error occurs. With executable and writeable memory access rights being mutually exclusive, code injection is made harder to perform. The solution is all transparent to the programmer. All that is required is to split an application into sub-programs that operates largely independently.
    [Show full text]
  • Hiding Process Memory Via Anti-Forensic Techniques
    DIGITAL FORENSIC RESEARCH CONFERENCE Hiding Process Memory via Anti-Forensic Techniques By: Frank Block (Friedrich-Alexander Universität Erlangen-Nürnberg (FAU) and ERNW Research GmbH) and Ralph Palutke (Friedrich-Alexander Universität Erlangen-Nürnberg) From the proceedings of The Digital Forensic Research Conference DFRWS USA 2020 July 20 - 24, 2020 DFRWS is dedicated to the sharing of knowledge and ideas about digital forensics research. Ever since it organized the first open workshop devoted to digital forensics in 2001, DFRWS continues to bring academics and practitioners together in an informal environment. As a non-profit, volunteer organization, DFRWS sponsors technical working groups, annual conferences and challenges to help drive the direction of research and development. https://dfrws.org Forensic Science International: Digital Investigation 33 (2020) 301012 Contents lists available at ScienceDirect Forensic Science International: Digital Investigation journal homepage: www.elsevier.com/locate/fsidi DFRWS 2020 USA d Proceedings of the Twentieth Annual DFRWS USA Hiding Process Memory Via Anti-Forensic Techniques Ralph Palutke a, **, 1, Frank Block a, b, *, 1, Patrick Reichenberger a, Dominik Stripeika a a Friedrich-Alexander Universitat€ Erlangen-Nürnberg (FAU), Germany b ERNW Research GmbH, Heidelberg, Germany article info abstract Article history: Nowadays, security practitioners typically use memory acquisition or live forensics to detect and analyze sophisticated malware samples. Subsequently, malware authors began to incorporate anti-forensic techniques that subvert the analysis process by hiding malicious memory areas. Those techniques Keywords: typically modify characteristics, such as access permissions, or place malicious data near legitimate one, Memory subversion in order to prevent the memory from being identified by analysis tools while still remaining accessible.
    [Show full text]
  • Virtual Memory - Paging
    Virtual memory - Paging Johan Montelius KTH 2020 1 / 32 The process code heap (.text) data stack kernel 0x00000000 0xC0000000 0xffffffff Memory layout for a 32-bit Linux process 2 / 32 Segments - a could be solution Processes in virtual space Address translation by MMU (base and bounds) Physical memory 3 / 32 one problem Physical memory External fragmentation: free areas of free space that is hard to utilize. Solution: allocate larger segments ... internal fragmentation. 4 / 32 another problem virtual space used code We’re reserving physical memory that is not used. physical memory not used? 5 / 32 Let’s try again It’s easier to handle fixed size memory blocks. Can we map a process virtual space to a set of equal size blocks? An address is interpreted as a virtual page number (VPN) and an offset. 6 / 32 Remember the segmented MMU MMU exception no virtual addr. offset yes // < within bounds index + physical address segment table 7 / 32 The paging MMU MMU exception virtual addr. offset // VPN available ? + physical address page table 8 / 32 the MMU exception exception virtual address within bounds page available Segmentation Paging linear address physical address 9 / 32 a note on the x86 architecture The x86-32 architecture supports both segmentation and paging. A virtual address is translated to a linear address using a segmentation table. The linear address is then translated to a physical address by paging. Linux and Windows do not use use segmentation to separate code, data nor stack. The x86-64 (the 64-bit version of the x86 architecture) has dropped many features for segmentation.
    [Show full text]
  • Chapter 4 Memory Management and Virtual Memory Asst.Prof.Dr
    Chapter 4 Memory management and Virtual Memory Asst.Prof.Dr. Supakit Nootyaskool IT-KMITL Object • To discuss the principle of memory management. • To understand the reason that memory partitions are importance for system organization. • To describe the concept of Paging and Segmentation. 4.1 Difference in main memory in the system • The uniprogramming system (example in DOS) allows only a program to be present in memory at a time. All resources are provided to a program at a time. Example in a memory has a program and an OS running 1) Operating system (on Kernel space) 2) A running program (on User space) • The multiprogramming system is difference from the mentioned above by allowing programs to be present in memory at a time. All resource must be organize and sharing to programs. Example by two programs are in the memory . 1) Operating system (on Kernel space) 2) Running programs (on User space + running) 3) Programs are waiting signals to execute in CPU (on User space). The multiprogramming system uses memory management to organize location to the programs 4.2 Memory management terms Frame Page Segment 4.2 Memory management terms Frame Page A fixed-lengthSegment block of main memory. 4.2 Memory management terms Frame Page A fixed-length block of data that resides in secondary memory. A page of data may temporarily beSegment copied into a frame of main memory. A variable-lengthMemory management block of data that residesterms in secondary memory. A segment may temporarily be copied into an available region of main memory or the segment may be divided into pages which can be individuallyFrame copied into mainPage memory.
    [Show full text]
  • Oracle® Linux 7 Working with LXC
    Oracle® Linux 7 Working With LXC F32445-02 October 2020 Oracle Legal Notices Copyright © 2020, Oracle and/or its affiliates. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract.
    [Show full text]
  • Module 4: Memory Management the Von Neumann Principle for the Design and Operation of Computers Requires That a Program Has to Be Primary Memory Resident to Execute
    Operating Systems/Memory management Lecture Notes Module 4: Memory Management The von Neumann principle for the design and operation of computers requires that a program has to be primary memory resident to execute. Also, a user requires to revisit his programs often during its evolution. However, due to the fact that primary memory is volatile, a user needs to store his program in some non-volatile store. All computers provide a non-volatile secondary memory available as an online storage. Programs and files may be disk resident and downloaded whenever their execution is required. Therefore, some form of memory management is needed at both primary and secondary memory levels. Secondary memory may store program scripts, executable process images and data files. It may store applications, as well as, system programs. In fact, a good part of all OS, the system programs which provide services (the utilities for instance) are stored in the secondary memory. These are requisitioned as needed. The main motivation for management of main memory comes from the support for multi- programming. Several executables processes reside in main memory at any given time. In other words, there are several programs using the main memory as their address space. Also, programs move into, and out of, the main memory as they terminate, or get suspended for some IO, or new executables are required to be loaded in main memory. So, the OS has to have some strategy for main memory management. In this chapter we shall discuss the management issues and strategies for both main memory and secondary memory.
    [Show full text]
  • OS Paging and Buffer Management
    OS Paging and Bu↵er Management Using the Virtual-Memory Paging Mechanism to Balance Hot/Cold Data in Memory and HDD Jana Lampe TU Kaiserslautern LGIS Seminar SS 2014 Optimizing Data Management on New Hardware 1 Introduction 1.1 Motivation Traditional database systems follow the design principle that all data is stored on hard disk where records are accessible via indexing structures and loaded into main-memory as soon as they are requested. Since memory prices have dropped significantly during the last three decades, new database systems have been designed that allow faster access to the data by storing all data inside the main-memory, e.g. H-Store [9]. Notwithstanding the above, also durable storage technologies have made con- siderable progress towards larger capacity, more input/output operations per second as well as reduced cost per storage unit at the same time. Solid-state drives (SSDs) have entered the market and, using the non-volatile NAND-flash technology, convince by their reading and writing speed, although they are still about ten times more expensive than common HDDs. Another promising tech- nology is phase-change memory (PCM), but it is still in research state. Now one could ask, why all the data is stored in memory. If there are records that are not accessed that frequently, would it not be cheaper to store them on a secondary storage device such as HDD or SSD? Moreover, energy consump- tion would decrease and more space would be available to temporarily store intermediate results thereby accelerating query processing. To answer this question, Gray and Putzolu proposed in [5] the 5-minute rule, which says, that a record should be kept in memory if it has accessed at least every 5 minutes (the break-even interval).
    [Show full text]
  • Readahead: Time-Travel Techniques for Desktop and Embedded Systems
    Readahead: time-travel techniques for desktop and embedded systems Michael Opdenacker Free Electrons [email protected] Abstract 1.2 Reading ahead Readahead techniques have successfully been used to The idea of reading ahead is to speed up the access to reduce boot time in recent GNU/Linux distributions like a file by preloading at least parts of its contents in page Fedora Core or Ubuntu. However, in embedded sys- cache ahead of time. This can be done when spare I/O tems with scarce RAM, starting a parallel thread read- resources are available, typically when tasks keep the ing ahead all the files used in system startup is no longer processor busy. Of course, this requires the ability to appropriate. The cached pages could be reclaimed even predict the future! before accessing the corresponding files. Fortunately, the systems we are dealing with are pre- This paper will first guide you through the heuristics dictable or even totally predictable in some situations! implemented in kernelspace, as well as through the userspace interface for preloading files or just announc- ing file access patterns. Desktop implementations will • Predictions by watching file read patterns. If pages be explained and benchmarked. We will then detail Free are read from a file in a sequential manner, it makes Electrons’ attempts to implement an easy to integrate sense to go on reading the next blocks in the file, helper program reading ahead files at the most appropri- even before these blocks are actually requested. ate time in the execution flow. • System startup. The system init sequence doesn’t This paper and the corresponding presentation target change.
    [Show full text]
  • Beyond Init: Systemd Linux Plumbers Conference 2010
    Beyond Init: systemd Linux Plumbers Conference 2010 Kay Sievers Lennart Poettering November 2010 Kay Sievers, Lennart Poettering Beyond Init: systemd Triggers: Boot, Socket, Bus, Device, Path, Timers, More Kay Sievers, Lennart Poettering Beyond Init: systemd Kay Sievers, Lennart Poettering Beyond Init: systemd Substantial coverage of basic OS boot-up tasks, including fsck, mount, quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots. Status: almost made Fedora 14. Kay Sievers, Lennart Poettering Beyond Init: systemd including fsck, mount, quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots. Status: almost made Fedora 14. Substantial coverage of basic OS boot-up tasks, Kay Sievers, Lennart Poettering Beyond Init: systemd mount, quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots. Status: almost made Fedora 14. Substantial coverage of basic OS boot-up tasks, including fsck, Kay Sievers, Lennart Poettering Beyond Init: systemd quota, hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots. Status: almost made Fedora 14. Substantial coverage of basic OS boot-up tasks, including fsck, mount, Kay Sievers, Lennart Poettering Beyond Init: systemd hwclock, readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots. Status: almost made Fedora 14. Substantial coverage of basic OS boot-up tasks, including fsck, mount, quota, Kay Sievers, Lennart Poettering Beyond Init: systemd readahead, tmpfiles, random-seed, console, static module loading, early syslog, plymouth, shutdown, kexec, SELinux, initrd+initrd-less boots.
    [Show full text]