PLAN 9 from BELL LABS PROGRAMMER's MANUAL

Total Page:16

File Type:pdf, Size:1020Kb

PLAN 9 from BELL LABS PROGRAMMER's MANUAL PLAN 9 from BELL LABS PROGRAMMER’S MANUAL First Edition Computing Science Research Center AT&T Bell Laboratories Murray Hill, New Jersey -- Copyright © 1993 AT&T Unpublished and not for publication All Rights Reserved PostScript and ThinkJet are registered trademarks. PERMUTED INDEX Manual pages for all sections are accessible on line through m a n(1). To save space, neighboring references to the same page have been collapsed into a single reference. This should cause no difficulty in cases like ‘atan’ and ‘atan2’, but is somewhat obscure in the case of ‘strcat’ and ‘strchr’. Disclabel – / . home, 40meg, 80meg, 100meg, newkernel, personalize, update, . home(8) floyd, halftone, hysteresis – create 1-bit images by dithering . floyd(9.1) hp – emulate an HP 2621 terminal . hp(1) 2a, 6a, 8a, ka, va, za – assemblers . 2a(1) 2c, 6c, 8c, kc, vc, zc – C compilers . 2c(1) 2l, 6l, 8l, kl, vl, zl – loaders . 2l(1) c++/2c, c++/kc, c++/vc, c++/8c, c++/zc, c++/ 2l, c++/kl, c++/vl, c++/8l, c++/zl – C++/ . c++(1) picture color compression . 3to1, mcut, improve, quantize, dither – . quantize(9.1) update, Disclabel – administration for/ . home, 40meg, 80meg, 100meg, newkernel, personalize, . home(8) smiley, life, fsim, clock, catclock,/ . 4s, 5s, ana, gnuchess, juggle, mandel, plumb, quiz, . games(1) 2a, 6a, 8a, ka, va, za – assemblers . 2a(1) 2c, 6c, 8c, kc, vc, zc – C compilers . 2c(1) 2l, 6l, 8l, kl, vl, zl – loaders . 2l(1) 8½ – window system files . 8½(4) 8½, label, window, wloc – window system . 8½(1) Disclabel – administration for/ . home, 40meg, 80meg, 100meg, newkernel, personalize, update, . home(8) 2a, 6a, 8a, ka, va, za – assemblers . 2a(1) 2c, 6c, 8c, kc, vc, zc – C compilers . 2c(1) /c++/8c, c++/zc, c++/2l, c++/kl, c++/vl, c++/ 8l, c++/zl – C++ compilers and loaders . c++(1) 2l, 6l, 8l, kl, vl, zl – loaders . 2l(1) intro – introduction to Plan 9 . intro(1) intro – introduction to the Plan 9 devices . intro(3) dirconv, dirmodeconv – interface to Plan 9 File protocol . /convM2D, getS, fcallconv, fcall(2) intro – introduction to the Plan 9 File Protocol, 9P . intro(5) mk9660, pump – create and write ISO- 9660 CD-ROM images . mk9660(8) dossrv, 9660srv, eject – DOS and ISO9660 file systems . dossrv(4) service . srv, 9fs, dk232, dkmodem – start network file . srv(4) – introduction to the Plan 9 File Protocol, 9P . intro intro(5) u9fs – serve 9P from Unix . u9fs(4) mnt – attach to 9P servers . mnt(3) abort – generate a fault . abort(2) flush – abort a message . flush(5) abs, labs – integer absolute values . abs(2) functions . fabs, fmod, floor, ceil – absolute value, remainder, floor, ceiling . floor(2) access – determine accessibility of file . access(2) getenv, putenv – access environment variables . getenv(2) /filesym, fileline, symerror – symbol table access functions) syminit, getsym, symbase,/ . symbol(findsym, access – determine accessibility of file . access(2) test – set status according to condition . test(1) acid – debugger . acid(1) sin, cos, tan, asin, acos, atan, atan2 – trigonometric functions . sin(2) attach, session, nop – messages to initiate activity . attach(5) sysmon, stats – display graphs of system activity . sysmon(8) edge3, extremum, median, nonoise, smooth,/ . adapt, ahe, crispen, laplace, edge, edge2, . filters(9.1) rshift, inset, rcanon, eqpt, eqrect, ptinrect,/ . add, sub, mul, div, raddp, rsubp, rmul, rdiv, . add(2) newuser – adding a new user . newuser(8) arp – Internet Address Resolution Protocol . arp(3) removeuser, enable, disable, expire, status,/ . adduser, changeuser, printnetkey, renameuser, . auth(8) xpand, picnegate – adjust dynamic range . xpand(9.1) intro – introduction to system administration . intro(8) kfscmd, ksync – kfs administration . kfscmd(8) newkernel, personalize, update, Disclabel – administration for local file systems . /100meg, home(8) font utilities . cachechars, agefont, loadchar, Subfont, Fontchar, Font – . cachechars(2) ahd – American Heritage Dictionary . ahd(7) extremum, median, nonoise, smooth,/ . adapt, ahe, crispen, laplace, edge, edge2, edge3, . filters(9.1) Plan 9 1 Permuted Index sleep, alarm – delay, ask for delayed note . sleep(2) val, kal – ALEF compilers . alef(1) movie – algorithm animation . movie(1) dpic, twb – anti- aliased troff output to picture files . twb(9.1) – mail/ . mail, edmail, sendmail, seemail, aliasmail, smtp, smtpd, uk2uk, vwhois, vismon . mail(1) /wrbitmap, rdbitmapfile, wrbitmapfile – allocating, freeing, reading, writing bitmaps . balloc(2) brk, sbrk – change memory allocation . brk(2) segbrk – change memory allocation . segbrk(2) malloc, free, realloc, calloc, mstats – memory allocator . malloc(2) ahd – American Heritage Dictionary . ahd(7) smiley, life, fsim, clock, catclock,/ . 4s, 5s, ana, gnuchess, juggle, mandel, plumb, quiz, . games(1) lex – generator of lexical analysis programs . lex(1) movie – algorithm animation . movie(1) moto − create animation scripts . moto(9.1) make and break network/ . dial, hangup, announce, listen, accept, reject, netmkaddr – . dial(2) dpic, twb – anti-aliased troff output to picture files . twb(9.1) a.out – object file format . a(6) pcc – APE C compiler driver . pcc(1) aplot – isometric plots of data arrays . aplot(9.1) ar – archive and library maintainer . ar(1) ar – archive (library) file format . ar(6) string,/ . /clipline, point, segment, polysegment, arc, circle, disc, ellipse, texture, border, . bitblt(2) tapefs − mount archival file systems . tapefs(1) ar – archive and library maintainer . ar(1) ar – archive (library) file format . ar(6) mkfs, mkext, flio – archive or update a file system . mkfs(8) tar – archiver . tar(1) ARG − process option letters from argv . arg(2) echo – print arguments . echo(1) getflags, usage – process flag arguments in argv . getflags(9.2) bc – arbitrary-precision arithmetic language . bc(1) /rectXrect, rectclip, Dx, Dy, Pt, Rect, Rpt – arithmetic on points and rectangles . add(2) arp – Internet Address Resolution Protocol . arp(3) ipconfig, arpd – Internet configuration . ipconfig(8) aplot – isometric plots of data arrays . aplot(9.1) art, art2pic – edit line-art . art(1) _toupper, _tolower, toupper, tolower – ASCII character classification . /toascii, ctype(2) xd – hex, octal, decimal, or ASCII dump . xd(1) UTF, Unicode, ASCII, rune – character set and format . utf(6) ascii, unicode – interpret ASCII, Unicode characters . ascii(1) ctime, localtime, gmtime, asctime, timezone – convert date and time to . ctime(2) functions . sin, cos, tan, asin, acos, atan, atan2 – trigonometric . sin(2) sleep, alarm – delay, ask for delayed note . sleep(2) 2a, 6a, 8a, ka, va, za – assemblers . 2a(1) qer – queue a request and associated data . qer(8) astro – print astronomical information . astro(7) async – framing for a serial line to Datakit . async(3) notify, noted, atnotify – handle asynchronous process notification . notify(2) sin, cos, tan, asin, acos, atan, atan2 – trigonometric functions . sin(2) cleanup . exits, atexit, atexitdont – terminate process, process . exits(2) notification . notify, noted, atnotify – handle asynchronous process . notify(2) – convert text to numbers . atof, atoi, atol, charstod, strtod, strtol, strtoul . atof(2) logo – convert image into an AT&T logo . logo(9.1) activity . attach, session, nop – messages to initiate . attach(5) mnt – attach to 9P servers . mnt(3) stat, wstat – inquire or change file attributes . stat(5) auth – file system authentication . auth(5) auth, srvauth, getchall, challreply, newns, authdial, passtokey, nvcsum – network/ . auth(2) Digital Pathways SecureNet Key – remote authentication box . securenet(8) keyfs – authentication database files . keyfs(4) expire, status, convkeys, wrkey – maintain authentication databases . /enable, disable, auth(8) fsauth, rexauth, chal, changekey – authentication services . auth(6) aux/mouse – configure a mouse to a port . mouse(8) aux/vga – setup VGA card . ..
Recommended publications
  • Java Implementation of the Graphical User Interface of the Octopus Distributed Operating System
    Java implementation of the graphical user interface of the Octopus distributed operating system Submitted by Aram Sadogidis Advisor Prof. Spyros Lalis University of Thessaly Volos, Greece October 2012 Acknowledgements I am sincerely grateful for all the people that supported me during my Uni- versity studies. Special thanks to professor Spyros Lalis, my mentor, who had decisive influence in shaping my character as an engineer. Also many thanks to my family and friends, whose support all these years, encouraged me to keep moving forward. 1 Contents 1 Introduction 4 2 System software technologies 6 2.1 Inferno OS . 6 2.2 JavaSE and Android framework . 8 2.3 Synthetic file systems . 10 2.3.1 Styx . 10 2.3.2 Op . 12 3 Octopus OS 14 3.1 UpperWare architecture . 14 3.2 Omero, a filesystem based window system . 16 3.3 Olive, the Omero viewer . 19 3.4 Ox, the Octopus shell . 21 4 Java Octopus Terminal 23 4.1 JOlive . 24 4.2 Desktop version . 25 4.2.1 Omero package . 26 4.2.2 ui package . 27 4.3 Android version . 28 4.3.1 com.jolive.Omero . 28 4.3.2 com.jolive.ui . 29 4.3.3 Pull application's UI . 30 5 Future perspective 33 5.1 GPS resources . 33 5.2 JOp . 34 5.3 Authentication device . 34 5.4 Remote Voice commander . 34 5.5 Conclusion . 35 6 Thesis preview in Greek 38 2 List of Figures 2.1 An application operates on a synthetic file as if it is a disk file, effectively communicating with a synthetic file system server.
    [Show full text]
  • Protocols: 0-9, A
    Protocols: 0-9, A • 3COM-AMP3, on page 4 • 3COM-TSMUX, on page 5 • 3PC, on page 6 • 4CHAN, on page 7 • 58-CITY, on page 8 • 914C G, on page 9 • 9PFS, on page 10 • ABC-NEWS, on page 11 • ACAP, on page 12 • ACAS, on page 13 • ACCESSBUILDER, on page 14 • ACCESSNETWORK, on page 15 • ACCUWEATHER, on page 16 • ACP, on page 17 • ACR-NEMA, on page 18 • ACTIVE-DIRECTORY, on page 19 • ACTIVESYNC, on page 20 • ADCASH, on page 21 • ADDTHIS, on page 22 • ADOBE-CONNECT, on page 23 • ADWEEK, on page 24 • AED-512, on page 25 • AFPOVERTCP, on page 26 • AGENTX, on page 27 • AIRBNB, on page 28 • AIRPLAY, on page 29 • ALIWANGWANG, on page 30 • ALLRECIPES, on page 31 • ALPES, on page 32 • AMANDA, on page 33 • AMAZON, on page 34 • AMEBA, on page 35 • AMAZON-INSTANT-VIDEO, on page 36 Protocols: 0-9, A 1 Protocols: 0-9, A • AMAZON-WEB-SERVICES, on page 37 • AMERICAN-EXPRESS, on page 38 • AMINET, on page 39 • AN, on page 40 • ANCESTRY-COM, on page 41 • ANDROID-UPDATES, on page 42 • ANET, on page 43 • ANSANOTIFY, on page 44 • ANSATRADER, on page 45 • ANY-HOST-INTERNAL, on page 46 • AODV, on page 47 • AOL-MESSENGER, on page 48 • AOL-MESSENGER-AUDIO, on page 49 • AOL-MESSENGER-FT, on page 50 • AOL-MESSENGER-VIDEO, on page 51 • AOL-PROTOCOL, on page 52 • APC-POWERCHUTE, on page 53 • APERTUS-LDP, on page 54 • APPLEJUICE, on page 55 • APPLE-APP-STORE, on page 56 • APPLE-IOS-UPDATES, on page 57 • APPLE-REMOTE-DESKTOP, on page 58 • APPLE-SERVICES, on page 59 • APPLE-TV-UPDATES, on page 60 • APPLEQTC, on page 61 • APPLEQTCSRVR, on page 62 • APPLIX, on page 63 • ARCISDMS,
    [Show full text]
  • Persistent 9P Sessions for Plan 9
    Persistent 9P Sessions for Plan 9 Gorka Guardiola, [email protected] Russ Cox, [email protected] Eric Van Hensbergen, [email protected] ABSTRACT Traditionally, Plan 9 [5] runs mainly on local networks, where lost connections are rare. As a result, most programs, including the kernel, do not bother to plan for their file server connections to fail. These programs must be restarted when a connection does fail. If the kernel’s connection to the root file server fails, the machine must be rebooted. This approach suffices only because lost connections are rare. Across long distance networks, where connection failures are more common, it becomes woefully inadequate. To address this problem, we wrote a program called recover, which proxies a 9P session on behalf of a client and takes care of redialing the remote server and reestablishing con- nection state as necessary, hiding network failures from the client. This paper presents the design and implementation of recover, along with performance benchmarks on Plan 9 and on Linux. 1. Introduction Plan 9 is a distributed system developed at Bell Labs [5]. Resources in Plan 9 are presented as synthetic file systems served to clients via 9P, a simple file protocol. Unlike file protocols such as NFS, 9P is stateful: per-connection state such as which files are opened by which clients is maintained by servers. Maintaining per-connection state allows 9P to be used for resources with sophisticated access control poli- cies, such as exclusive-use lock files and chat session multiplexers. It also makes servers easier to imple- ment, since they can forget about file ids once a connection is lost.
    [Show full text]
  • Bell Labs, the Innovation Engine of Lucent
    INTERNSHIPS FOR RESEARCH ENGINEERS/COMPUTER SCIENTISTS BELL LABS DUBLIN (IRELAND) – BELL LABS STUTTGART (GERMANY) Background Candidates are expected to have some experience related to the following topics: Bell Laboratories is a leading end-to-end systems and • Operating systems, virtualisation and computer solutions research lab working in the areas of cloud architectures. and distributed computing, platforms for real-time • big-data streaming and analytics, wireless networks, Software development skills (C/C++, Python). • semantic data access, services-centric operations and Computer networks and distributed systems. thermal management. The lab is embedded in the • Optimisation techniques and algorithms. great traditions of the Bell Labs systems research, in- • Probabilistic modelling of systems performance. ternationally renowned as the birthplace of modern The following skills or interests are also desirable: information theory, UNIX, the C/C++ programming • languages, Awk, Plan 9 from Bell Labs, Inferno, the Experience with OpenStack or OpenNebula or Spin formal verification tool, and many other sys- other cloud infrastructure management software. • tems, languages, and tools. Kernel-level programming (drivers, scheduler,...). • Xen, KVM and Linux scripting/administration. We offer summer internships in our Cloud • Parallel and distributed systems programming Computing team, spread across the facilities in Dublin (Ireland) and Stuttgart (Germany), focusing (MPI, OpenMP, CUDA, MapReduce, StarSs, …). • on research enabling future cloud
    [Show full text]
  • Concurrent Cilk: Lazy Promotion from Tasks to Threads in C/C++
    Concurrent Cilk: Lazy Promotion from Tasks to Threads in C/C++ Christopher S. Zakian, Timothy A. K. Zakian Abhishek Kulkarni, Buddhika Chamith, and Ryan R. Newton Indiana University - Bloomington, fczakian, tzakian, adkulkar, budkahaw, [email protected] Abstract. Library and language support for scheduling non-blocking tasks has greatly improved, as have lightweight (user) threading packages. How- ever, there is a significant gap between the two developments. In previous work|and in today's software packages|lightweight thread creation incurs much larger overheads than tasking libraries, even on tasks that end up never blocking. This limitation can be removed. To that end, we describe an extension to the Intel Cilk Plus runtime system, Concurrent Cilk, where tasks are lazily promoted to threads. Concurrent Cilk removes the overhead of thread creation on threads which end up calling no blocking operations, and is the first system to do so for C/C++ with legacy support (standard calling conventions and stack representations). We demonstrate that Concurrent Cilk adds negligible overhead to existing Cilk programs, while its promoted threads remain more efficient than OS threads in terms of context-switch overhead and blocking communication. Further, it enables development of blocking data structures that create non-fork-join dependence graphs|which can expose more parallelism, and better supports data-driven computations waiting on results from remote devices. 1 Introduction Both task-parallelism [1, 11, 13, 15] and lightweight threading [20] libraries have become popular for different kinds of applications. The key difference between a task and a thread is that threads may block|for example when performing IO|and then resume again.
    [Show full text]
  • Virtfs—A Virtualization Aware File System Pass-Through
    VirtFS—A virtualization aware File System pass-through Venkateswararao Jujjuri Eric Van Hensbergen Anthony Liguori IBM Linux Technology Center IBM Research Austin IBM Linux Technology Center [email protected] [email protected] [email protected] Badari Pulavarty IBM Linux Technology Center [email protected] Abstract operations into block device operations and then again into host file system operations. This paper describes the design and implementation of In addition to performance improvements over a tradi- a paravirtualized file system interface for Linux in the tional virtual block device, exposing guest file system KVM environment. Today’s solution of sharing host activity to the hypervisor provides greater insight to the files on the guest through generic network file systems hypervisor about the workload the guest is running. This like NFS and CIFS suffer from major performance and allows the hypervisor to make more intelligent decisions feature deficiencies as these protocols are not designed with respect to I/O caching and creates new opportuni- or optimized for virtualization. To address the needs of ties for hypervisor-based services like de-duplification. the virtualization paradigm, in this paper we are intro- ducing a new paravirtualized file system called VirtFS. In Section 2 of this paper, we explore more details about This new file system is currently under development and the motivating factors for paravirtualizing the file sys- is being built using QEMU, KVM, VirtIO technologies tem layer. In Section 3, we introduce the VirtFS design and 9P2000.L protocol. including an overview of the 9P protocol, which VirtFS is based on, along with a set of extensions introduced for greater Linux guest compatibility.
    [Show full text]
  • User's Manual
    rBOX610 Linux Software User’s Manual Disclaimers This manual has been carefully checked and believed to contain accurate information. Axiomtek Co., Ltd. assumes no responsibility for any infringements of patents or any third party’s rights, and any liability arising from such use. Axiomtek does not warrant or assume any legal liability or responsibility for the accuracy, completeness or usefulness of any information in this document. Axiomtek does not make any commitment to update the information in this manual. Axiomtek reserves the right to change or revise this document and/or product at any time without notice. No part of this document may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Axiomtek Co., Ltd. Trademarks Acknowledgments Axiomtek is a trademark of Axiomtek Co., Ltd. ® Windows is a trademark of Microsoft Corporation. Other brand names and trademarks are the properties and registered brands of their respective owners. Copyright 2014 Axiomtek Co., Ltd. All Rights Reserved February 2014, Version A2 Printed in Taiwan ii Table of Contents Disclaimers ..................................................................................................... ii Chapter 1 Introduction ............................................. 1 1.1 Specifications ...................................................................................... 2 Chapter 2 Getting Started ......................................
    [Show full text]
  • Looking to the Future by JOHN BALDWIN
    1 of 3 Looking to the Future BY JOHN BALDWIN FreeBSD’s 13.0 release delivers new features to users and refines the workflow for new contri- butions. FreeBSD contributors have been busy fixing bugs and adding new features since 12.0’s release in December of 2018. In addition, FreeBSD developers have refined their vision to focus on FreeBSD’s future users. An abbreviated list of some of the changes in 13.0 is given below. A more detailed list can be found in the release notes. Shifting Tools Not all of the changes in the FreeBSD Project over the last two years have taken the form of patches. Some of the largest changes have been made in the tools used to contribute to FreeBSD. The first major change is that FreeBSD has switched from Subversion to Git for storing source code, documentation, and ports. Git is widely used in the software industry and is more familiar to new contribu- tors than Subversion. Git’s distributed nature also more easily facilitates contributions from individuals who are Not all of the changes in the not committers. FreeBSD had been providing Git mir- rors of the Subversion repositories for several years, and FreeBSD Project over the last many developers had used Git to manage in-progress patches. The Git mirrors have now become the offi- two years have taken the form cial repositories and changes are now pushed directly of patches. to Git instead of Subversion. FreeBSD 13.0 is the first release whose sources are only available via Git rather than Subversion.
    [Show full text]
  • Plan 9 from Bell Labs
    Plan 9 from Bell Labs “UNIX++ Anyone?” Anant Narayanan Malaviya National Institute of Technology FOSS.IN 2007 What is it? Advanced technology transferred via mind-control from aliens in outer space Humans are not expected to understand it (Due apologies to lisperati.com) Yeah Right • More realistically, a distributed operating system • Designed by the creators of C, UNIX, AWK, UTF-8, TROFF etc. etc. • Widely acknowledged as UNIX’s true successor • Distributed under terms of the Lucent Public License, which appears on the OSI’s list of approved licenses, also considered free software by the FSF What For? “Not only is UNIX dead, it’s starting to smell really bad.” -- Rob Pike (circa 1991) • UNIX was a fantastic idea... • ...in it’s time - 1970’s • Designed primarily as a “time-sharing” system, before the PC era A closer look at Unix TODAY It Works! But that doesn’t mean we don’t develop superior alternates GNU/Linux • GNU’s not UNIX, but it is! • Linux was inspired by Minix, which was in turn inspired by UNIX • GNU/Linux (mostly) conforms to ANSI and POSIX requirements • GNU/Linux, on the desktop, is playing “catch-up” with Windows or Mac OS X, offering little in terms of technological innovation Ok, and... • Most of the “modern ideas” we use today were “bolted” on an ancient underlying system • Don’t believe me? A “modern” UNIX Terminal Where did it go wrong? • Early UNIX, “everything is a file” • Brilliant! • Only until people started adding “features” to the system... Why you shouldn’t be working with GNU/Linux • The Socket API • POSIX • X11 • The Bindings “rat-race” • 300 system calls and counting..
    [Show full text]
  • Virtualization Best Practices
    SUSE Linux Enterprise Server 15 SP1 Virtualization Best Practices SUSE Linux Enterprise Server 15 SP1 Publication Date: September 24, 2021 Contents 1 Virtualization Scenarios 2 2 Before You Apply Modifications 2 3 Recommendations 3 4 VM Host Server Configuration and Resource Allocation 3 5 VM Guest Images 25 6 VM Guest Configuration 36 7 VM Guest-Specific Configurations and Settings 42 8 Xen: Converting a Paravirtual (PV) Guest to a Fully Virtual (FV/HVM) Guest 45 9 External References 49 1 SLES 15 SP1 1 Virtualization Scenarios Virtualization oers a lot of capabilities to your environment. It can be used in multiple scenarios. To get more details about it, refer to the Book “Virtualization Guide” and in particular, to the following sections: Book “Virtualization Guide”, Chapter 1 “Virtualization Technology”, Section 1.2 “Virtualization Capabilities” Book “Virtualization Guide”, Chapter 1 “Virtualization Technology”, Section 1.3 “Virtualization Benefits” This best practice guide will provide advice for making the right choice in your environment. It will recommend or discourage the usage of options depending on your workload. Fixing conguration issues and performing tuning tasks will increase the performance of VM Guest's near to bare metal. 2 Before You Apply Modifications 2.1 Back Up First Changing the conguration of the VM Guest or the VM Host Server can lead to data loss or an unstable state. It is really important that you do backups of les, data, images, etc. before making any changes. Without backups you cannot restore the original state after a data loss or a misconguration. Do not perform tests or experiments on production systems.
    [Show full text]
  • Cg 2015 Huong Vu Thanh
    c 2015 Huong Vu Thanh Luu OPTIMIZING I/O PERFORMANCE FOR HIGH PERFORMANCE COMPUTING APPLICATIONS: FROM AUTO-TUNING TO A FEEDBACK-DRIVEN APPROACH BY HUONG VU THANH LUU DISSERTATION Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate College of the University of Illinois at Urbana-Champaign, 2015 Urbana, Illinois Doctoral Committee: Professor Marianne Winslett, Chair Professor William Gropp, Director of Research Professor Marc Snir Dr Robert Ross, Argonne National Laboratory ABSTRACT The 2014 TOP500 supercomputer list includes over 40 deployed petascale systems, and the high performance computing (HPC) community is working toward developing the first exaflop system by 2023. Scientific applications on such large-scale computers often read and write a lot of data. With such rapid growth in computing power and data intensity, I/O continues to be a challenging factor in determining the overall performance of HPC applications. We address the problem of optimizing I/O performance for HPC applica- tions by firstly examining the I/O behavior of thousands of supercomputing applications. We analyzed the high-level I/O logs of over a million jobs rep- resenting a combined total of six years of I/O behavior across three leading high-performance computing platforms. Our analysis provides a broad por- trait of the state of HPC I/O usage. We proposed a simple and e↵ective analysis and visualization procedure to help scientists who do not have I/O expertise to quickly locate the bottlenecks and inefficiencies in their I/O ap- proach. We proposed several filtering criteria for system administrators to find application candidates that are consuming system I/O resources ineffi- ciently.
    [Show full text]
  • Security of OS-Level Virtualization Technologies: Technical Report
    Security of OS-level virtualization technologies Elena Reshetova1, Janne Karhunen2, Thomas Nyman3, N. Asokan4 1 Intel OTC, Finland 2 Ericsson, Finland 3 University of Helsinki, Finland 4 Aalto University and University of Helsinki, Finland Abstract. The need for flexible, low-overhead virtualization is evident on many fronts ranging from high-density cloud servers to mobile devices. During the past decade OS-level virtualization has emerged as a new, efficient approach for virtualization, with implementations in multiple different Unix-based systems. Despite its popularity, there has been no systematic study of OS-level virtualization from the point of view of security. In this report, we conduct a comparative study of several OS- level virtualization systems, discuss their security and identify some gaps in current solutions. 1 Introduction During the past couple of decades the use of different virtualization technolo- gies has been on a steady rise. Since IBM CP-40 [19], the first virtual machine prototype in 1966, many different types of virtualization and their uses have been actively explored both by the research community and by the industry. A relatively recent approach, which is becoming increasingly popular due to its light-weight nature, is Operating System-Level Virtualization, where a number of distinct user space instances, often referred to as containers, are run on top of a shared operating system kernel. A fundamental difference between OS-level virtualization and more established competitors, such as Xen hypervisor [24], VMWare [48] and Linux Kernel Virtual Machine [29] (KVM), is that in OS-level virtualization, the virtualized artifacts are global kernel resources, as opposed to hardware.
    [Show full text]