I/O Workload Outsourcing for Boosting RAID Reconstruction Performance

Total Page:16

File Type:pdf, Size:1020Kb

I/O Workload Outsourcing for Boosting RAID Reconstruction Performance WorkOut: I/O Workload Outsourcing for Boosting RAID Reconstruction Performance Suzhen Wu1, Hong Jiang2, Dan Feng1∗, Lei Tian12, Bo Mao1 1Key Laboratory of Data Storage Systems, Ministry of Education of China 1School of Computer Science & Technology, Huazhong University of Science & Technology 2Department of Computer Science & Engineering, University of Nebraska-Lincoln ∗Corresponding author: [email protected] {suzhen66, maobo.hust}@gmail.com, {jiang, tian}@cse.unl.edu, [email protected] Abstract ing reconstruction without serving any I/O requests from User I/O intensity can significantly impact the perfor- user applications, and on-line reconstruction, when the mance of on-line RAID reconstruction due to contention RAID continues to service user I/O requests during re- for the shared disk bandwidth. Based on this observa- construction. tion, this paper proposes a novel scheme, called WorkOut Off-line reconstruction has the advantage that it’s (I/O Workload Outsourcing), to significantly boost RAID faster than on-line reconstruction, but it is not practical reconstruction performance. WorkOut effectively out- in environments with high availability requirements, as sources all write requests and popular read requests orig- the entire RAID set needs to be taken off-line during re- inally targeted at the degraded RAID set to a surrogate construction. RAID set during reconstruction. Our lightweight pro- On the other hand, on-line reconstruction allows fore- totype implementation of WorkOut and extensive trace- ground traffic to continue during reconstruction, but driven and benchmark-driven experiments demonstrate takes longer to complete than off-line reconstruction as that, compared with existing reconstruction approaches, the reconstruction process competes with the foreground WorkOut significantly speeds up both the total recon- workload for I/O bandwidth. In our experiments we find struction time and the average user response time. Im- that on-line reconstruction (with heavy user I/O work- portantly, WorkOut is orthogonal to and can be easily loads) can be as much as 70 times (70×) slower than incorporated into any existing reconstruction algorithms. off-line reconstruction (without user I/O workloads) (see Furthermore, it can be extended to improving the perfor- Section 2.2). Moreover, while on-line reconstruction al- mance of other background support RAID tasks, such as lows foreground workload to be served, the performance re-synchronization and disk scrubbing. of the foreground workload might be significantly re- duced. In our experiments, we see cases where the user 1 Introduction response time increases by a factor of 3 (3×) during on- As a fundamental technology for reliability and availabil- line reconstruction(see Section 2.2). ity, RAID [30] has been widely deployed in modern stor- Improving the performance of on-line RAID recon- age systems. A RAID-structured storage system ensures struction is becoming a growing concern in the light of that data will not be lost when disks fail. One of the key recent technology trends: reconstruction times are ex- responsibilities of RAID is to recover the data that was pected to increase in the future, as the capacity of drives on a failed disk, a process known as RAID reconstruc- grows at a much higher rate than other performance pa- tion. rameters, such as bandwidth, seek time and rotational la- The performance of RAID reconstruction techniques tency [10]. Moreover, with the ever growing number of depends on two factors. First, the time it takes to com- drives in data centers, reconstruction might soon become plete the reconstruction of a failed disk, since longer re- the common mode of operation in large-scale systems construction times translate to a longer “window of vul- rather than the exception [4, 9, 18, 32, 34]. nerability”, in which a second disk failure may cause per- A number of approaches have been proposed to im- sistent data loss. Second, the impact of the reconstruction prove the performance of RAID reconstruction, includ- process on the foreground workload, i.e., to what degree ing for example optimizing the reconstruction work- are user requests affected by the ongoing reconstruction. flow [12, 22], the reconstruction sequence [3, 41] or the Current approaches for RAID reconstruction fall into data layout [14, 49]. We note that all these approaches two different categories: [11, 12]: off-line reconstruction, focus on a single RAID set. In this paper we propose a when the RAID devotes all of its resources to perform- new approach to improving reconstruction performance, USENIX Association FAST ’09: 7th USENIX Conference on File and Storage Technologies 239 exploiting the fact that most data centers contain a large evaluations of WorkOut based on a prototype implemen- number of RAID sets. tation are presented in Section 4. We analyze the relia- Inspired by recent work on data migration [2, 24, 46] bility of WorkOut in Section 5 and present related work and write off loading [27], we propose WorkOut, a frame- in Section 6. We point out directions for future research work to significantly improve on-line reconstruction per- in Section 7 and summarize the main contributions of the formance by I/O Workload Outsourcing. The main idea paper in Section 8. behind WorkOut is to temporarily redirect all write re- quests and popular read requests originally targeted at 2 Background and Motivation the degraded RAID set to a surrogate RAID set. The sur- In this section, we provide some background and key ob- rogate RAID set can be free space on another live RAID servations that motivate our work and facilitate our pre- set or a set of spare disks. sentation of WorkOut in later sections. The benefits of WorkOut are two-fold. WorkOut re- duces the impact of reconstruction on foreground traffic 2.1 Disk failures in the real world because most user requests can be served from the surro- Recent studies of field data on partial or complete disk gate RAID set and hence no longer compete with the re- failures in large-scale storage systems indicate that disk construction process for disk bandwidth. WorkOut also failures happen at a significant rate [4, 9, 18, 32, 34]. speeds up the reconstruction process, since more band- Schroeder & Gibson [34] found that annual disk re- width on the degraded RAID set can be devoted to the placement rates in the real world exceed 1%, with 2%- reconstruction process. 4% on average and up to 13% in some systems, much In more detail, WorkOut has the following salient fea- higher than 0.88%, the annual failure rates (AFR) spec- tures: ified by the manufacturer’s datasheet. Bairavasundaram [4] observed that the probability of latent sector (1) WorkOut tackles one of the most important factors et al. errors, which can lead to disk replacement, is 3.45% in adversely affecting reconstruction performance, their study. Those failure rates, combined with the con- namely, I/O intensity, that, to the best of our knowl- tinuously increasing number of drives in large-scale stor- edge, has not been adequately addressed by the pre- age systems, raise concerns that in future storage sys- vious studies [3, 41]. tems, recovery mode might become the common mode (2) WorkOut has a distinctive advantage of improv- of operation [9]. ing both reconstruction time and user response time. It is a very effective reconstruction optimiza- Another concern arises from recent studies showing a tion scheme focusing on optimizing write-intensive significant amount of correlation in drive failures, indi- workloads, a roadblock for many of the existing re- cating that, after one disk fails, another disk failure will construction approaches [41]. likely occur soon [4, 9, 18]. Gibson [9] also points out (3) WorkOut is orthogonal and complementary to and that the probability of a second disk failure in a RAID can be easily incorporated into most existing RAID system during reconstruction increases along with the reconstruction approaches to further improve their reconstruction time: approximately 0.5% for one hour, performance. 1.0% for 3 hours and 1.4% for 6 hours. (4) In addition to boosting RAID reconstruction perfor- All the above trends make fast recovery from disk fail- mance, WorkOut is very lightweight and can be eas- ures an increasingly important factor in building storage ily extended to improve the performance of other systems. background tasks, such as re-synchronization [7] 2.2 Mutually adversary impact of reconstruc- and disk scrubbing [36], that are also becoming tion and user I/O requests more frequent and lengthier for the same reasons that reconstruction is becoming more frequent and During on-line RAID reconstruction, reconstruction re- lengthier. quests and user I/O requests compete for the bandwidth of the surviving disks and adversely affect each other. Extensive trace-driven and benchmark-driven exper- User I/O requests increase the reconstruction time while iments conducted on our lightweight prototype im- the reconstruction process increases the user response plementation of WorkOut show that WorkOut sig- time. nificantly outperforms the existing reconstruction ap- Figure 1 shows the reconstruction times and user re- proaches PR [22] and PRO [42] in both reconstruction sponse times of a 5-disk RAID5 set with a stripe unit size time and user response time. of 64KB in three cases: (1) off-line reconstruction, (2) The rest of this paper is organized as follows. Back- on-line reconstruction at the highest speed (when RAID ground and motivation are presented in Section 2. We de- favors the reconstruction process), and (3) on-line recon- scribe the design of WorkOut in Section 3. Performance struction at the lowest speed (when RAID favors user 240 FAST ’09: 7th USENIX Conference on File and Storage Technologies USENIX Association Reconstruction Time Response Time Reconstruction Time Response Time 180 60 180 60 150 150 45 45 120 120 90 30 90 30 60 (minute) 15 (minute) 60 30 15 30 Response Time (ms) Response Time (ms) Reconstruction Time 0 0 Off-Line On-line On-line Recoonstruction Time 0 0 fastest slowest 9 43 59 150 200 Reconstruction Option I/O Intensity (IOPS) Figure 1: Reconstruction and its performance impact.
Recommended publications
  • Disk Array Data Organizations and RAID
    Guest Lecture for 15-440 Disk Array Data Organizations and RAID October 2010, Greg Ganger © 1 Plan for today Why have multiple disks? Storage capacity, performance capacity, reliability Load distribution problem and approaches disk striping Fault tolerance replication parity-based protection “RAID” and the Disk Array Matrix Rebuild October 2010, Greg Ganger © 2 Why multi-disk systems? A single storage device may not provide enough storage capacity, performance capacity, reliability So, what is the simplest arrangement? October 2010, Greg Ganger © 3 Just a bunch of disks (JBOD) A0 B0 C0 D0 A1 B1 C1 D1 A2 B2 C2 D2 A3 B3 C3 D3 Yes, it’s a goofy name industry really does sell “JBOD enclosures” October 2010, Greg Ganger © 4 Disk Subsystem Load Balancing I/O requests are almost never evenly distributed Some data is requested more than other data Depends on the apps, usage, time, … October 2010, Greg Ganger © 5 Disk Subsystem Load Balancing I/O requests are almost never evenly distributed Some data is requested more than other data Depends on the apps, usage, time, … What is the right data-to-disk assignment policy? Common approach: Fixed data placement Your data is on disk X, period! For good reasons too: you bought it or you’re paying more … Fancy: Dynamic data placement If some of your files are accessed a lot, the admin (or even system) may separate the “hot” files across multiple disks In this scenario, entire files systems (or even files) are manually moved by the system admin to specific disks October 2010, Greg
    [Show full text]
  • Architectures and Algorithms for On-Line Failure Recovery in Redundant Disk Arrays
    Architectures and Algorithms for On-Line Failure Recovery in Redundant Disk Arrays Draft copy submitted to the Journal of Distributed and Parallel Databases. A revised copy is published in this journal, vol. 2 no. 3, July 1994.. Mark Holland Department of Electrical and Computer Engineering Carnegie Mellon University 5000 Forbes Ave. Pittsburgh, PA 15213-3890 (412) 268-5237 [email protected] Garth A. Gibson School of Computer Science Carnegie Mellon University 5000 Forbes Ave. Pittsburgh, PA 15213-3890 (412) 268-5890 [email protected] Daniel P. Siewiorek School of Computer Science Carnegie Mellon University 5000 Forbes Ave. Pittsburgh, PA 15213-3890 (412) 268-2570 [email protected] Architectures and Algorithms for On-Line Failure Recovery In Redundant Disk Arrays1 Abstract The performance of traditional RAID Level 5 arrays is, for many applications, unacceptably poor while one of its constituent disks is non-functional. This paper describes and evaluates mechanisms by which this disk array failure-recovery performance can be improved. The two key issues addressed are the data layout, the mapping by which data and parity blocks are assigned to physical disk blocks in an array, and the reconstruction algorithm, which is the technique used to recover data that is lost when a component disk fails. The data layout techniques this paper investigates are variations on the declustered parity organiza- tion, a derivative of RAID Level 5 that allows a system to trade some of its data capacity for improved failure-recovery performance. Parity declustering improves the failure-mode performance of an array significantly, and a parity-declustered architecture is preferable to an equivalent-size multiple-group RAID Level 5 organization in environments where failure-recovery performance is important.
    [Show full text]
  • Memory Systems : Cache, DRAM, Disk
    CHAPTER 24 Storage Subsystems Up to this point, the discussions in Part III of this with how multiple drives within a subsystem can be book have been on the disk drive as an individual organized together, cooperatively, for better reliabil- storage device and how it is directly connected to a ity and performance. This is discussed in Sections host system. This direct attach storage (DAS) para- 24.1–24.3. A second aspect deals with how a storage digm dates back to the early days of mainframe subsystem is connected to its clients and accessed. computing, when disk drives were located close to Some form of networking is usually involved. This is the CPU and cabled directly to the computer system discussed in Sections 24.4–24.6. A storage subsystem via some control circuits. This simple model of disk can be designed to have any organization and use any drive usage and confi guration remained unchanged of the connection methods discussed in this chapter. through the introduction of, fi rst, the mini computers Organization details are usually made transparent to and then the personal computers. Indeed, even today user applications by the storage subsystem presenting the majority of disk drives shipped in the industry are one or more virtual disk images, which logically look targeted for systems having such a confi guration. like disk drives to the users. This is easy to do because However, this simplistic view of the relationship logically a disk is no more than a drive ID and a logical between the disk drive and the host system does not address space associated with it.
    [Show full text]
  • Which RAID Level Is Right for Me?
    STORAGE SOLUTIONS WHITE PAPER Which RAID Level is Right for Me? Contents Introduction.....................................................................................1 RAID 10 (Striped RAID 1 sets) .................................................3 RAID Level Descriptions..................................................................1 RAID 50 (Striped RAID 5 sets) .................................................4 RAID 0 (Striping).......................................................................1 RAID 60 (Striped RAID 6 sets) .................................................4 RAID 1 (Mirroring).....................................................................2 RAID Level Comparison ..................................................................5 RAID 1E (Striped Mirror)...........................................................2 About Adaptec RAID .......................................................................5 RAID 5 (Striping with parity) .....................................................2 RAID 5EE (Hot Space).....................................................................3 RAID 6 (Striping with dual parity).............................................3 Data is the most valuable asset of any business today. Lost data of users. This white paper intends to give an overview on the means lost business. Even if you backup regularly, you need a performance and availability of various RAID levels in general fail-safe way to ensure that your data is protected and can be and may not be accurate in all user
    [Show full text]
  • Software-RAID-HOWTO.Pdf
    Software-RAID-HOWTO Software-RAID-HOWTO Table of Contents The Software-RAID HOWTO...........................................................................................................................1 Jakob Østergaard [email protected] and Emilio Bueso [email protected] 1. Introduction..........................................................................................................................................1 2. Why RAID?.........................................................................................................................................1 3. Devices.................................................................................................................................................1 4. Hardware issues...................................................................................................................................1 5. RAID setup..........................................................................................................................................1 6. Detecting, querying and testing...........................................................................................................2 7. Tweaking, tuning and troubleshooting................................................................................................2 8. Reconstruction.....................................................................................................................................2 9. Performance.........................................................................................................................................2
    [Show full text]
  • A Secure, Reliable and Performance-Enhancing Storage Architecture Integrating Local and Cloud-Based Storage
    Brigham Young University BYU ScholarsArchive Theses and Dissertations 2016-12-01 A Secure, Reliable and Performance-Enhancing Storage Architecture Integrating Local and Cloud-Based Storage Christopher Glenn Hansen Brigham Young University Follow this and additional works at: https://scholarsarchive.byu.edu/etd Part of the Electrical and Computer Engineering Commons BYU ScholarsArchive Citation Hansen, Christopher Glenn, "A Secure, Reliable and Performance-Enhancing Storage Architecture Integrating Local and Cloud-Based Storage" (2016). Theses and Dissertations. 6470. https://scholarsarchive.byu.edu/etd/6470 This Thesis is brought to you for free and open access by BYU ScholarsArchive. It has been accepted for inclusion in Theses and Dissertations by an authorized administrator of BYU ScholarsArchive. For more information, please contact [email protected], [email protected]. A Secure, Reliable and Performance-Enhancing Storage Architecture Integrating Local and Cloud-Based Storage Christopher Glenn Hansen A thesis submitted to the faculty of Brigham Young University in partial fulfillment of the requirements for the degree of Master of Science James Archibald, Chair Doran Wilde Michael Wirthlin Department of Electrical and Computer Engineering Brigham Young University Copyright © 2016 Christopher Glenn Hansen All Rights Reserved ABSTRACT A Secure, Reliable and Performance-Enhancing Storage Architecture Integrating Local and Cloud-Based Storage Christopher Glenn Hansen Department of Electrical and Computer Engineering, BYU Master of Science The constant evolution of new varieties of computing systems - cloud computing, mobile devices, and Internet of Things, to name a few - have necessitated a growing need for highly reliable, available, secure, and high-performing storage systems. While CPU performance has typically scaled with Moore’s Law, data storage is much less consistent in how quickly perfor- mance increases over time.
    [Show full text]
  • By Michail D. Flouris a Thesis Submitted in Conformity with The
    EXTENSIBLE NETWORKED-STORAGE VIRTUALIZATION WITH METADATA MANAGEMENT AT THE BLOCK LEVEL by Michail D. Flouris A thesis submitted in conformity with the requirements for the degree of Doctor of Philosophy Graduate Department of Computer Science University of Toronto Copyright c 2009 by Michail D. Flouris Abstract Extensible Networked-Storage Virtualization with Metadata Management at the Block Level Michail D. Flouris Doctor of Philosophy Graduate Department of Computer Science University of Toronto 2009 Increased scaling costs and lack of desired features is leading to the evolution of high-performance storage systems from centralized architectures and specialized hardware to decentralized, commodity storage clusters. Existing systems try to address storage cost and management issues at the filesystem level. Besides dictating the use of a specific filesystem, however, this approach leads to increased complexity and load imbalance towards the file-server side, which in turn increase costs to scale. In this thesis, we examine these problems at the block-level. This approach has several advantages, such as transparency, cost-efficiency, better resource utilization, simplicity and easier management. First of all, we explore the mechanisms, the merits, and the overheads associated with advanced metadata-intensive functionality at the block level, by providing versioning at the block level. We find that block-level versioning has low overhead and offers transparency and simplicity advantages over filesystem-based approaches. Secondly, we study the problem of providing extensibility required by diverse and changing appli- cation needs that may use a single storage system. We provide support for (i) adding desired functions as block-level extensions, and (ii) flexibly combining them to create modular I/O hierarchies.
    [Show full text]
  • On-Line Data Reconstruction in Redundant Disk Arrays
    On-Line Data Reconstruction In Redundant Disk Arrays A dissertation submitted to the Department of Electrical and Computer Engineering, Carnegie Mellon University, in partial fulfillment of the requirements for the degree of Doctor of Philosophy. Copyright © 1994 by Mark Calvin Holland ii Abstract There exists a wide variety of applications in which data availability must be continu- ous, that is, where the system is never taken off-line and any interruption in the accessibil- ity of stored data causes significant disruption in the service provided by the application. Examples include on-line transaction processing systems such as airline reservation sys- tems and automated teller networks in banking systems. In addition, there exist many applications for which a high degree of data availability is important, but continuous oper- ation is not required. An example is a research and development environment, where access to a centrally-stored CAD system is often necessary to make progress on a design project. These applications and many others mandate both high performance and high availability from their storage subsystems. Redundant disk arrays are systems in which a high level of I/O performance is obtained by grouping together a large number of small disks, rather than building one large, expensive drive. The high component count of such systems leads to unacceptably high rates of data loss due to component failure, and so they typically incorporate redun- dancy to achieve fault tolerance. This redundancy takes one of two forms: replication or encoding. In replication, the system maintains one or more duplicate copies of all data. In the encoding approach, the system maintains an error-correcting code (ECC) computed over the data.
    [Show full text]
  • Scalability of RAID Systems
    Scalability of RAID Systems Yan Li I V N E R U S E I T H Y T O H F G E R D I N B U Doctor of Philosophy Institute of Computing Systems Architecture School of Informatics University of Edinburgh 2010 Abstract RAID systems (Redundant Arrays of Inexpensive Disks) have dominated back- end storage systems for more than two decades and have grown continuously in size and complexity. Currently they face unprecedented challenges from data intensive applications such as image processing, transaction processing and data warehousing. As the size of RAID systems increases, designers are faced with both performance and reliability challenges. These challenges include limited back-end network bandwidth, physical interconnect failures, correlated disk failures and long disk reconstruction time. This thesis studies the scalability of RAID systems in terms of both performance and reliability through simulation, using a discrete event driven simulator for RAID systems (SIMRAID) developed as part of this project. SIMRAID incorporates two benchmark workload generators, based on the SPC-1 and Iometer benchmark specifi- cations. Each component of SIMRAID is highly parameterised, enabling it to explore a large design space. To improve the simulation speed, SIMRAID develops a set of abstraction techniques to extract the behaviour of the interconnection protocol without losing accuracy. Finally, to meet the technology trend toward heterogeneous storage architectures, SIMRAID develops a framework that allows easy modelling of different types of device and interconnection technique. Simulation experiments were first carried out on performance aspects of scalabil- ity. They were designed to answer two questions: (1) given a number of disks, which factors affect back-end network bandwidth requirements; (2) given an interconnec- tion network, how many disks can be connected to the system.
    [Show full text]
  • The Vinum Volume Manager
    The vinum Volume Manager Greg Lehey Table of Contents 1. Synopsis ................................................................................................................................ 1 2. Access Bottlenecks ................................................................................................................... 1 3. Data Integrity ......................................................................................................................... 3 4. vinum Objects ........................................................................................................................ 4 5. Some Examples ....................................................................................................................... 5 6. Object Naming ....................................................................................................................... 10 7. Configuring vinum ................................................................................................................ 11 8. Using vinum for the Root File System ........................................................................................ 12 1. Synopsis No matter the type of disks, there are always potential problems. The disks can be too small, too slow, or too unreliable to meet the system's requirements. While disks are getting bigger, so are data storage requirements. Often a le system is needed that is bigger than a disk's capacity. Various solutions to these problems have been proposed and implemented. One method is through
    [Show full text]
  • The Vinum Volume Manager Gr Eg Lehey LEMIS (SA) Pty Ltd PO Box 460 Echunga SA 5153
    The Vinum Volume Manager Gr eg Lehey LEMIS (SA) Pty Ltd PO Box 460 Echunga SA 5153. [email protected] [email protected] [email protected] ABSTRACT The Vinum Volume Manager is a device driver which implements virtual disk drives. It isolates disk hardwarefromthe device interface and maps data in ways which result in an incr ease in flexibility, perfor mance and reliability compared to the traditional slice view of disk storage. Vinum implements the RAID-0, RAID-1, RAID-4 and RAID-5 models, both in- dividually and in combination. Vinum is an open source volume manager which runs under FreeBSD and NetBSD. It was inspired by the VERITAS® volume manager and implements many of the concepts of VERITAS®. Its key features are: • Vinum implements many RAID levels: • RAID-0 (striping). • RAID-1 (mirroring). • RAID-4 (fixed parity). • RAID-5 (block-interleaved parity). • RAID-10 (mirroring and striping), a combination of RAID-0 and RAID-5. In addition, other combinations arepossible for which no formal RAID level definition exists. • Volume managers initially emphasized reliability and perfor mance rather than ease of use. The results arefrequently down time due to misconfiguration, with consequent reluctance on the part of operational personnel to attempt to use the moreunusual featur es of the product. Vinum attempts to provide an easier-to-use non-GUI inter- face. In place of conventional disk partitions, Vinum presents synthetic disks called volumes to 1 the user.These volumes arethe top level of a hierarchy of objects used to construct vol- umes with differ ent characteristics: • The top level is the virtual disk or volume.Volumes effectively replace disk drives.
    [Show full text]
  • The Title Title: Subtitle March 2007
    sub title The Title Title: Subtitle March 2007 Copyright c 2006-2007 BSD Certification Group, Inc. Permission to use, copy, modify, and distribute this documentation for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE DOCUMENTATION IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS DOCUMENTATION INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CON- SEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEG- LIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS DOCUMENTATION. NetBSD and pkgsrc are registered trademarks of the NetBSD Foundation, Inc. FreeBSD is a registered trademark of the FreeBSD Foundation. Contents Introduction v 1 Chapter Installing and Upgrading the OS and Software 1 1.1 Recognize the installation program used by each operating system . 2 1.2 Recognize which commands are available for upgrading the operating system 6 1.3 Understand the difference between a pre-compiled binary and compiling from source . 8 1.4 Understand when it is preferable to install a pre-compiled binary and how to doso ...................................... 9 1.5 Recognize the available methods for compiling a customized binary . 10 1.6 Determine what software is installed on a system . 10 1.7 Determine which software requires upgrading . 11 1.8 Upgrade installed software . 11 1.9 Determine which software have outstanding security advisories .
    [Show full text]