DOCSLIB.ORG

Voyager: Complete Container State Migration

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Voyager: Complete Container State Migration 2017 IEEE 37th International Conference on Distributed Computing Systems Voyager: Complete Container State Migration Shripad Nadgowda, Sahil Suneja, Nilton Bila and Canturk Isci IBM T.J. Watson Research Center Abstract—Due to the small memory footprint and ternatives that either provide memory-only migration, or fast startup times offerred by container virtualization, rely on specific filesystems to migrate persistent storage made ever more popular by the Docker platform, con- (Section 2). Voyager performs just-in-time live container tainers are seeing rapid adoption as a foundational capability to build PaaS and SaaS clouds. For such migration with minimal downtime, by combining the data container clouds, which are fundamentally different federation capabilities of union mounts together with from VM clouds, various cloud management services CRIU-based memory migration. With a union view of data need to be revisited. In this paper, we present our between the source and target hosts, Voyager containers Voyager - just-in-time live container migration service, can resume operation instantly on the target host, while designed in accordance with the Open Container Ini- tiative (OCI) principles. Voyager is a novel filesystem- performing disk state transfer either on-demand (Copy- agnostic and vendor-agnostic migration service that on-Write) or through lazy replication. Our experiments provides consistent full-system migration.Voyager com- show Voyager’s federation framework imposes no overhead bines CRIU-based memory migration together with during data updates/writes, and ≈ 1% overheads for reads the data federation capabilities of union mounts to and upto 10% for scans. minimize migration downtime. With a union view of data between the source and target hosts, Voyager We have open-sourced an initial version of our data mi- containers can resume operation instantly on the target gration framework[8], although it works specifically with host, while performing disk state transfer lazily in the docker containers and does not support live migration. We background. intend to open-source the enhancements described in this I. Introduction paper as well, which include in-memory state migration, OCI compliance, and support for multiple data storage Container virtualization has existed since two decades types (rootfs, local and network attached data volumes). in the form of FreeBSD Jails[18], Solaris Zones[26], IBM AIX Workload Partitional WPAR[5], and LXC for II. Background and Related Work Linux, amongst others. But these have recently started gaining acceptance as a lightweight alternative to vir- The objective in this paper is not to compare and tual machines (VMs), owing to technology maturity and establish performance advantages between VM and con- popularization by platforms like Docker[14], CoreOS’s tainer migration techniques. Containers are fundamentally rocket[12], Cloud Foundry Warden[9]. Containers are be- different than VMs in terms of their system resource ing adopted as a foundational vitualization capability in requirements, high density and agility. We believe a more building Platform-as-a-Service (PaaS) and Software-as-a- optimal migration service can be designed for container Service (SaaS) cloud solutions, e.g. Amazon Container clouds than the prevalent ones in VM clouds. service[6], Google Container Engine [15] and IBM’s Con- tainer Cloud[17]. For such container clouds, which are A. VM Migration fundamentally different from VM clouds, various cloud Migration has extensively been studied primarily for management services need to be revisited. In this paper, VM Clouds[7][25][24][16][22]. Different vendors use differ- we target one such service- container migration. ent virtual disk (vDisk) formats to encapsulate a VM’s An efficient migration solution becomes essential as persistent state (e.g. vmdk, VHD, qcow2), which are containers start running production workloads. Borrowing migrated via proprietary hypervisor-assisted services like the scenarios from their VM counterparts, migrations are vMotion[29] and Hyper-V Live Migration[27], third party required during host maintenance, load balancing, server tools [7], [25], [13], or via explicit vDisk conversions[28][19] consolidation and movement between availability zones across hypervisors. Containers, on the other hand, are (e.g., a Silver zone with HDD storage and 100 IOPS vs. (being) standardised by the Open Container Initiative a Gold zone with SSD storage with 1000 IOPS). (OCI)[3] which specifies an industry standard for container In this paper, we present our Voyager container migra- image format- a filesystem bundle or rootfs, and multiple tion service, tailored specifically for containers in accor- data volumes (Section III). These being essentially direc- dance with OCI principles. Voyager is a novel filesystem- tories on the host filesystem, a generic file-based migration agnostic and vendor-agnostic migration service that pro- solution can be designed for containers. There also exist vides consistent full-system migration, unlike existing al- vendor-agnostic file-based migration solutions for VMs like 1063-6927/17 $31.00 © 2017 IEEE 2137986 DOI 10.1109/ICDCS.2017.91 I2Map[22] and racemi[4], but there require extra agents to Picocenter[30] on the other hand is a system that en- be installed inside the systems. ables swapping-out in-active containers in cloud to object Some container clouds[6][15] provision VMs to host con- store (Amazon S3) and swapping-in on-demand. It uses tainers, primarily to mitigate security and isolation con- CRIU to capture and migrate memory-state and btrfs cerns for containers, while others run containers directly filesystem snapshots for persistent state. It also proposes on cloud hosts [17]. This paper shows how to migrate the feature of ActiveSet for memory in which memory pages small execution state that is part of a container without are restored for container on-access and lazily. This is resorting to installing and migrating VMs that impose again a filesystem specific solution and not optimized for different constraints on their hosts. Installing VMs for container migration use-case. the purpose of migration defeats the advantages of using III. Design and Implementation containers for application deployment. As per OCI specifications, every container image is B. Container Migration stored in a filesystem bundle, which after unpacking be- Containers have been popular with the microservice comes just another directory– rootfs– on the host filesys- architecture. Although container migration may seem re- tem. On container instantiation, all runtime environment dundant for stateless containerized applications, but it changes (e.g., new package installations) and data changes is still pertinent to several stateful microservice applica- (e.g., application state and logs) are persisted in rootfs tions like databases (e.g. Mysql, cassandra), message bro- by default. Since runtime state changes actively, hosting kers (kafka), and state-coordination service (zookeeper), rootfs at the local filesystem also complies from a per- amongst others. This is being acknowledged and supported formance viewpoint. Additionally, any directory from the in standard frameworks like Kubernetes’ ‘StatefulSet’. host filesystem can also be bind mount inside a container Portability of stateful containers is also explored in exist- as data volumes. Such a volume can also be a network at- ing solutions like ClusterHQ’s Flocker[10], Virtuozzo[20] tached filesystem mounted on the host. Similarly, although and Picocenter[30]. rare, any block devices on the host can also be mapped Flocker[10] primarily is a data management solution inside container. As for volatile state, containers have their specifically for docker containers. It supports migration memory share from the host controlled via cgroups. for network-attached storage backends like Amazon EBS, Thus, migrating a container involves discovering all Openstack Cinder, VMware vSphere etc., by re-attaching data end-points of a container, and moving their states, these network storage for containers. Local attached vol- in addition to its memory state, consistently from the ume migration is supported only for ZFS filesystem. On source to the target host. Migration of in-memory state the other hand, Voyager is a generic, filesystem-agnostic can be achieved in userspace via CRIU. Also, any net- and vendor-agnostic migration solution. work attached storage can be migrated by un-mounting Virtuozzo is a bare-metal virtualization solution that it from source host and mounting it on target host. includes container virtualization. It facilitates Zero- In addition, Voyager provides userspace-level filesystem- downtime live migration for containers[23][20]. During this agnostic migration of locally persistent container state, migration it first transfer container’s filesystem and virtual while ensuring consistency across all these states, as memory to target host. Once transfer is finished, it freeze well as minimum application downtime. Fig.1 shows the all container processes and disable networking. It then complete orchestration framework of Voyager. Primarily, dump this memory state to file and copies these dump file we are migrating container state across three different to target host. Any changed memory and disk blocks since data stores, namely in-memory, local filesystem, and the last transfer are then migrated to target host and then network filesystem. We discuss each of these migration container is resumed. It has an underlying assumption capabilities
Load more

Recommended publications
  • A Novel Scheduling Framework Leveraging Hardware Cache Partitioning for Cache-Side-Channel Elimination in Clouds
    A Novel Scheduling Framework Leveraging Hardware Cache Partitioning for Cache-Side-Channel Elimination in Clouds Read Sprabery Konstantin Evchenko Abhilash Raj University of Illinois, University of Illinois, Oregon State University Urbana-Champaign Urbana-Champaign [email protected] [email protected] [email protected] Rakesh B. Bobba Sibin Mohan Roy H. Campbell Oregon State University University of Illinois, University of Illinois, [email protected] Urbana-Champaign Urbana-Champaign [email protected] [email protected] ABSTRACT on the Last-Level-Cache (LLC) that is shared across multiple cores While there exist many isolation mechanisms that are available [18, 23, 43, 44, 48] – these make defenses much harder. to cloud service providers, including virtual machines, containers, Many defenses against cache-side-channel attacks in cloud envi- etc. , the problem of side-channel increases in importance as a re- ronments have also been proposed (e.g., [6, 19, 21, 22, 24, 25, 28, 31, maining security vulnerability – particularly in the presence of 32, 37–40, 45, 51]). However, the proposed solutions suer from a shared caches and multicore processors. In this paper we present variety of drawbacks: (a) some are probabilistic [25, 37, 51]; (b) oth- a hardware-software mechanism that improves the isolation of ers do not protect applications when SMT is enabled [51]; (c) some cloud processes in the presence of shared caches on multicore require developers to re-write applications [19, 22, 31], (d) while chips. Combining the Intel CAT architecture that enables cache others require hardware changes [39, 40] impacting deployability; partitioning on the y with novel scheduling techniques and state (e) some depend on violating x86 semantics by modifying the reso- cleansing mechanisms, we enable cache-side-channel free comput- lution, accuracy or availability of timing instructions [21, 24, 38] ing for Linux-based containers and virtual machines, in particular, and consequently require signicant changes to the applications.
    [Show full text]
  • Implementing a Parallel World Model Using Linux Containers for Efficient System Administration
    Implementing a parallel world model using Linux containers for efficient system administration (Paper) Yasushi Shinjo and Wataru Ishida Jinpeng Wei Department of Computer Science School of Computing and Information Sciences University of Tsukuba Florida International University 1-1-1 Tennoudai, Tsukuba, Ibaraki 305-8573, Japan Miami, Florida, USA Email: [email protected] Abstract—This paper describes the implementation of a par- software updates. However, this method does not help to run allel world model using Linux containers. A parallel world the production environment while testing. (or parallel universe) model allows a user to create multiple To address these problems, we propose providing a parallel execution environments, called worlds, in a single operating system and to manipulate these worlds. This model enables world model at the operating system level. A parallel world or a system administrator to create a new test world that looks parallel universe model is a model to describe time machines like a production world. The system administrator upgrades in science fiction (SF) and to interpret observations in quantum fundamental software and tests applications in the new test physics. In our parallel world model at the operating system world while running the production world. If the applications level, a world is a container of files and an execution environ- do not pass the tests, the administrator deletes the new world. If the applications pass the tests, the administrator merges the ment of processes. Using this parallel world model, a system test world into the production world. Prior to the merge, the administrator can upgrade fundamental software, as follows.
    [Show full text]
  • The Virtual Filesystem Interface in 4.4BSDI
    The Virtual Filesystem Interface in 4.4BSDI Marshall Kirk McKusick Consultant and Author Berkeley, California ABSTRACT: This paper describes the virtual filesys- tem interface found in 4.4BSD. This interface is de- signed around an object oriented virtual file node or "vnode" data structure. The vnode structure is de- scribed along with its method for dynamically expand- ing its set of operations. These operations have been divided into two groups: those to manage the hierarchi- cal filesystem name space and those to manage the flat filestore. The translation of pathnames is described, as it requires a tight coupling between the virtual filesys- tem layer and the underþing filesystems through which the path traverses. This paper describes the filesystem services that are exported from the vnode interface to its clients, both local and remote. It also describes the set of services provided by the vnode layer to its client filesystems. The vnode interface has been generalized to allow multiple filesystems to be stacked together. After describing the stacking functionality, several examples of stacking filesystems are shown. t To appear in The Design and Implementation of the 4.4BSD Operating System, by Marshall Kirk McKusick, publisher. et al., @1995 by Addison-Wesley Publishing Companf Inc. Reprinted with the permission of the o 1995 The USENIX Association, Computing Systems, Vol. 8 ' No. 1 ' Winter 1995 I. The Virtual Filesystem Interface In early UNIX systems, the file entries directly referenced the local filesystem inode, see Figure I [Leffler et al. 1989]. This approach worked fine when there was a single filesystem implementation. However, with the advent of multþle filesystem types, the architecture had to be generalized.
    [Show full text]
  • A NAS Integrated File System for On-Site Iot Data Storage
    A NAS Integrated File System for On-site IoT Data Storage Yuki Okamoto1 Kenichi Arai2 Toru Kobayashi2 Takuya Fujihashi1 Takashi Watanabe1 Shunsuke Saruwatari1 1Graduate School of Information Science and Technology, Osaka University, Japan 2Graduate School of Engineering, Nagasaki University, Japan Abstract—In the case of IoT data acquisition, long-term storage SDFS, multiple NAS can be handled as one file system and of large amounts of sensor data is a significant challenge. When a users can easily add new NAS. cloud service is used, fixed costs such as a communication line for The remainder of this paper is organized as follows. In uploading and a monthly fee are unavoidable. In addition, the use of large-capacity storage servers incurs high initial installation section 2, we discuss the issues associated with the sensor data costs. In this paper, we propose a Network Attached Storage storage. Section 3 describes the overview and implementation (NAS) integrated file system called the “Sensor Data File System of the proposed file system, SDFS. In section 4, we evaluate (SDFS)”, which has advantages of being on-site, low-cost, and the performance of SDFS and existing file systems. Section 5 highly scalable. We developed the SDFS using FUSE, which introduces related work, and Section 6 summarizes the main is an interface for implementing file systems in user-space. In this work, we compared SDFS with existing integrated storage findings of this paper. modalities such as aufs and unionfs-fuse. The results indicate that II. ISSUES ASSOCIATED WITH THE SENSOR DATA STORAGE SDFS achieves an equivalent throughput compared with existing file systems in terms of read/write performance.
    [Show full text]
  • A BRIEF HISTORY of the BSD FAST FILE SYSTEM 9 June07login Press.Qxd:Login June 06 Volume 31 5/27/07 10:22 AM Page 10
    June07login_press.qxd:login June 06 Volume 31 5/27/07 10:22 AM Page 9 I FIRST STARTED WORKING ON THE UNIX file system with Bill Joy in the late MARSHALL KIRK MCKUSICK 1970s. I wrote the Fast File System, now called UFS, in the early 1980s. In this a brief history of article, I have written a survey of the work that I and others have done to the BSD Fast File improve the BSD file systems. Much of System this research has been incorporated into other file systems. Dr. Marshall Kirk McKusick writes books and articles, teaches classes on UNIX- and BSD-related subjects, and provides expert-witness testimony on software patent, trade secret, and copyright issues, particu - 1979: Early Filesystem Work larly those related to operating systems and file sys - tems. While at the University of California at Berke - The first work on the UNIX file system at Berke - ley, he implemented the 4.2BSD Fast File System and was the Research Computer Scientist at the Berkeley ley attempted to improve both the reliability and Computer Systems Research Group (CSRG) oversee - the throughput of the file system. The developers ing the development and release of 4.3BSD and improved reliability by staging modifications to 4.4BSD. critical filesystem information so that the modifi - [email protected] cations could be either completed or repaired cleanly by a program after a crash [14]. Doubling the block size of the file system improved the per - formance of the 4.0BSD file system by a factor of more than 2 when compared with the 3BSD file system.
    [Show full text]
  • Upgrade Without Bricking
    Upgrade without Bricking Arnout Vandecappelle http://mind.be/content/Presentation_Upgrade-without-Bricking.pdf or .odp © 2012 Essensium N.V. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License You never know where your product will be used High-precision GNSS receiver You never know where your product will be used What if you install new firmware on remote systems? What if you install new firmware on remote systems? Murphy's Law What if you install new firmware on remote systems? Murphy's Law Upgrade without Bricking Arnout Vandecappelle http://mind.be/content/Presentation_Upgrade-without-Bricking.pdf or .odp © 2012 Essensium N.V. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License Overview 1 Failure mechanisms ● Power failure ● Bad firmware ● Communication errors 2 Boot loader upgrade 3 Package-based upgrade Overview 1 Failure mechanisms ● Power failure ● Bad firmware ● Communication errors 2 Boot loader upgrade 3 Package-based upgrade Power failure Power fails during upgrade ⇒ new firmware only partially written Solutions: Add fail-safe firmware Detect failed power Atomic update of firmware images Use journalling filesystem for writable data Detecting power failure: Switch to fail-safe firmware 1. Boot current firmware fail- boot current config safe loader firmware files FW Detecting power failure: Switch to fail-safe firmware 2. Switch to fail-safe fail- boot current config safe loader firmware files FW Detecting power failure: Switch to fail-safe firmware fail- boot new config safe loader firmware files FW 3. Overwrite firmware Detecting power failure: Switch to fail-safe firmware 4. Fail-safe restarts upgrade fail- boot new config safe loader firmware files FW Detecting power failure: Switch to fail-safe firmware 5.
    [Show full text]
  • A Method of Merging Vmware Disk Images Through File System Unification by Sarah X
    A Method of Merging VMware Disk Images MASSACHUSETTS INSTITUTE through File System Unification OF TECHN4OLOGY by DEC 16 2010 Sarah X. Cheng LIBRARIES S.B., Computer Science and Engineering, Massachusetts Institute of Technology (2004) Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degree of Master of Engineering in Electrical Engineering and Computer Science at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY ACHIVES February 2011 © Massachusetts Institute of Technology 2011. All rights reserved. -7--) Author ...... ...... Department of Electrical Enginer' d Computer Science October 5, 2010 ... s ..... Certified by............. Stephen A. Ward Professor Thesis Supervisor Accepted by........ Dr. Christopher J. Terman Chairman, Master of Engineering Thesis Committee 2 A Method of Merging VMware Disk Images through File System Unification by Sarah X. Cheng Submitted to the Department of Electrical Engineering and Computer Science on October 5, 2010, in partial fulfillment of the requirements for the degree of Master of Engineering in Electrical Engineering and Computer Science Abstract This thesis describes a method of merging the contents of two VMware disk images by merging the file systems therein. Thus, two initially disparate file systems are joined to appear and behave as a single file system. The problem of file system namespace unification is not a new one, with predecessors dating as far back as 1988 to present-day descendants such as UnionFS and union mounts. All deal with the same major issues - merging directory contents of source branches and handling any naming conflicts (namespace de-duplication), and allowing top-level edits of file system unions in presence of read-only source branches (copy-on-write).
    [Show full text]
  • Use the Overlayfs Storage Driver | Docker Documentation
    Use the OverlayFS storage driver Estimated reading time: 18 minutes OverlayFS is a modern union filesystem that is similar to AUFS, but faster and with a simpler implementation. Docker provides two storage drivers for OverlayFS: the original overlay , and the newer and more stable overlay2 . This topic refers to the Linux kernel driver as OverlayFS and to the Docker storage driver as overlay or overlay2 . ! Note:: IfIf youyou useuse OverlayFS,OverlayFS, useuse thethe overlay2 driverdriver ratherrather thanthan thethe overlay driver,driver, becausebecause itit isis moremore eefficient in terms of inode utilization. To use the new driver, you need version 4.0 or higher of thethe LinuxLinux kernel,kernel, oror RHELRHEL oror CentOSCentOS usingusing versionversion 3.10.0-5143.10.0-514 andand above. For more information about differences between overlay vs overlay2 , check Docker storage drivers (https://docs.docker.com/storage/storagedriver/select-storage-driver/). Prerequisites OverlayFS is supported if you meet the following prerequisites: The overlay2 driver is supported on Docker CE, and Docker EE 17.06.02-ee5 and up, and is the recommended storage driver. Version 4.0 or higher of the Linux kernel, or RHEL or CentOS using version 3.10.0-514 of the kernel or higher. If you use an older kernel, you need to use the overlay driver, which is not recommended. The overlay and overlay2 drivers are supported on xfs backing filesystems, but only with d_type=true enabled. Use xfs_info to verify that the ftype option is set to 1 . To format an xfs filesystem correctly, use the flag -n ftype=1 .
    [Show full text]
  • Docker Containers for HEP - first Steps
    docker containers for HEP - first steps Sébastien Binet LAL/IN2P3 2014-05-21 S. Binet (LAL) docker 2014-05-21 1 / 19 Outline What ? Why ? How ? (When ?) S. Binet (LAL) docker 2014-05-21 2 / 19 Docker: what is it ? http://www.docker.io/ an open source project to pack, ship and run any application as a lightweight container High level description kind of like a lightweightVM runs in its own process space has its own network interface can run stuff as root Low level description chroot on steroids container = isolated process(es) share kernel with host no device emulation S. Binet (LAL) docker 2014-05-21 3 / 19 Docker: why ? same use cases than for VMs speed: boots in (milli)seconds footprint: 100-1000 containers on a single machine/laptop. small disk requirements Containers vs. VMs S. Binet (LAL) docker 2014-05-21 4 / 19 Docker: why ? Efficiency: almost no overhead processes are isolated but run straight on the host CPU performance = native performance memory performance = a few % shaved off for (optional) accounting network perfomace = small overhead Efficiency: storage friendly unioning filesystems snapshotting filesystems copy-on-write provisionning takes a few milliseconds . and a few kilobytes creating a new container/base-image takes a few seconds S. Binet (LAL) docker 2014-05-21 5 / 19 Docker: how ? LinuX Containers (LXC) Control Groups and Namepsaces AUFS (overlaying filesystem), or BTRFS, or DeviceMapper Client-Server with an http/REST API LXC Let’s your run a Linux system within another Linux system A container is a group of processes on a Linux box, put together is an isolated environment From the inside, it looks like a VM.
    [Show full text]
  • State of the Union When You Don’T Need Union Mounts
    State of the Union When you don't need Union Mounts Jan Blunck Novell [email protected] 30. October 2009 What Union? I Not the European Union ... this is Dresden not Brussels I This is about Filesystems I In particular about Filesystem Namespace Unification What Union? I Not the European Union ... this is Dresden not Brussels I This is about Filesystems I In particular about Filesystem Namespace Unification What Union? I Not the European Union ... this is Dresden not Brussels I This is about Filesystems I In particular about Filesystem Namespace Unification Outline Introduction Where is the Problem? Unioning Filesystems UnionFS Another UnionFS UnionFS-FUSE mini fo Union Mount You probably don't need Union Mounts Device-Mapper Snapshot Delta Filesystem CLIC Filesystem SquashFS Fake Write Support Shared root filessytem - NFS Root Shared root filessytem - XIP Whats left to do than? Thanks Disclaimer I'm the author of the VFS based Union Mount patches. That somehow makes me biased. I'll try my very best though ... Where is the Problem? POSIX Requirements I seek to cookie POSIX is missing I whiteout filetype DT WHITEOUT I topology of mount tree I open (directories) by inode number Where is the Problem? POSIX Requirements I seek to cookie POSIX is missing I whiteout filetype DT WHITEOUT I topology of mount tree I open (directories) by inode number Where is the Problem? I NFS Sucks ftp://ftp.lst.de/pub/people/okir/papers/2006-OLS/ nfs-sucks-slides.pdf Where is the Problem? I NFS Sucks ftp://ftp.lst.de/pub/people/okir/papers/2006-OLS/ nfs-sucks-slides.pdf
    [Show full text]
  • Liveng Documentation Release 1.0
    liveng Documentation Release 1.0 LumIT Labs Feb 04, 2019 Contents 1 Why liveng 3 2 More features 5 3 Table of contents 7 3.1 Standard Debian live...........................................7 3.2 Set up a standard Debian live......................................8 3.3 liveng structure..............................................9 3.4 UEFI Secure Boot............................................ 14 3.5 Persistence................................................ 16 3.6 Kernel update............................................... 21 3.7 Kernel update, the Debian way...................................... 23 3.8 Kernel update improvements....................................... 24 3.9 About liveng............................................... 25 3.10 liveng-based operating systems and tools................................ 25 3.11 License.................................................. 25 i ii liveng Documentation, Release 1.0 Next Generation Linux live distributions concepts A live operating system allows booting from a removable medium, such a USB key, without the need of being installed to the hard drive. Contents 1 liveng Documentation, Release 1.0 2 Contents CHAPTER 1 Why liveng None of the existing ISO9660-based live operating systems provide a kernel update feature: the kernel and the initrd are the only components that a live operating system cannot update, because they lay outside of the data persistence partition and the system partition is ISO9660-formatted, so not writeable - which is the best option for a live, because of its strength
    [Show full text]
  • Linux - Hard Drives, Partitions and Filesystems Naming Convention
    Linux - Hard Drives, Partitions and Filesystems Naming Convention IDE drives are referred to as hda for the first drive, hdb for the second etc. Serial ATA and SCSI drives are referenced as sda, sdb etc. Hard drive partitions are represented by an additional number. The partitions on each drive are referred numerically. The first partition on the first drive is referred to as hda1, the second as hda2, the third as hda3 etc. Linux IDE naming conventions: Device Description Configuration /dev/(s)hda 1st (Primary) IDE controller Master /dev/(s)hdb 1st (Primary) IDE controller Slave /dev/(s)hdc 2nd (Secondary) IDE controller Master /dev/(s)hdd 2nd (Secondary) IDE controller Slave Linux SATA/SCSI naming conventions: /dev/sda 1st SATA /dev/sdb 2nd SATA Partitioning A computer system may have multiple drives with primary partitions but only one primary partition may be active on one drive only. The active primary partition is used for booting the system and is referenced by the Master Boot Record (MBR). Each hard drive may only have a maximum of four primary partitions. You must an OS from a primary partition. Extended partitions allow one to place up to 24 partitions on a single drive. The first partition on the first drive is referred to as hda1, the second as hda2, the third as hda3 etc. Use the fdisk command under LINUX to partition a hardrive. Implicit in the fdisk command is the mkdev command that creates the device file for the partition. On sime UNIX systems, the mkdev command is explicitly used to create the device file.
    [Show full text]