Native POSIX Threads Library (NPTL) Support for Uclibc

Total Page:16

File Type:pdf, Size:1020Kb

Native POSIX Threads Library (NPTL) Support for Uclibc Native POSIX Threads Library (NPTL) Support for uClibc. Steven J. Hill Reality Diluted, Inc. [email protected] Abstract calls for applications to execute. Linux is for- tunate in that there are a number of C libraries available for varying platforms and environ- Linux continues to gain market share in embed- ments. Whether an embedded system, high- ded systems. As embedded processing power performance computing, or a home PC, there increases and more demanding applications in is a C library to fit each need. need of multi-threading capabilities are devel- oped, Native POSIX Threads Library (NPTL) The GNU C library, known also as glibc [1], support becomes crucial. The GNU C library and uClibc [2] are the most common Linux C li- [1] has had NPTL support for a number of years braries in use today. There are other C libraries on multiple processor architectures. However, like Newlib [3], diet libc [4], and klibc [5] used the GNU C library is more suited for work- in embedded systems and small root file sys- station and server platforms and not embed- tems. We list them only for completeness, yet ded systems due to its size. uClibc [2] is a they are not considered in this paper. Our focus POSIX-compliant C library designed for size will be solely on uClibc and glibc. and speed, but currently lacking NPTL sup- port. This paper will present the design and implementation of NPTL support in uClibc. In 2 Comparing C Libraries addition to the design overview, benchmarks, limitations and comparisons between glibc and uClibc will be discussed. NPTL for uClibc is To understand the need for NPTL in uClibc, we currently only supported for the MIPS proces- first examine the goals of both the uClibc and sor architecture. glibc projects. We will quickly examine the strengths and weaknesses of both C implemen- tations. It will then become evident why NPTL is needed in uClibc. 1 The Contenders 2.1 GNU C Library Project Goals Every usable Linux system has applications built atop a C library run-time environment. To quote from the main GNU C Library web The C library is at the core of user space and page [1], “The GNU C library is primarily de- provides all the necessary functions and system signed to be a portable and high performance C 410 • Native POSIX Threads Library (NPTL) Support for uClibc. library. It follows all relevant standards (ISO C The last two features in the table warrant ad- 99, POSIX.1c, POSIX.1j, POSIX.1d, Unix98, ditional explanation. glibc recently removed Single Unix Specification). It is also interna- linuxthreads support from its main de- tionalized and has one of the most complete in- velopment tree. It was moved into a sepa- ternationalization interfaces known.” In short, rate ports tree. It is maintained on a volun- glibc, aims to be the most complete C library teer basis only. uClibc will maintain both the implementation available. It succeeds, but at linuxthreads and nptl thread models ac- the cost of size and complexity. tively. Secondly, glibc only supports a couple of primary processor architectures. The rest of the architectures were also recently moved into 2.2 uClibc Project Goals the ports tree. uClibc continues to actively sup- port many more architectures by default. For embedded systems, uClibc is clearly the win- Let us see what uClibc has to offer. Again, ner. quoting from the main page for uClibc [2], “uClibc (a.k.a. µClibc, pronounced yew-see- lib-see) is a C library for developing embed- ded Linux systems. It is much smaller than 3 Why NPTL for Embedded Sys- the GNU C Library, but nearly all applica- tems? tions supported by glibc also work perfectly with uClibc. Porting applications from glibc to uClibc typically involves just recompiling uClibc supports multiple thread library the source code. uClibc even supports shared models. What are the shortcomings of libraries and threading. It currently runs on linuxthreads? Why is nptl better, or standard Linux and MMU-less (also known as worse? The answer lies in the requirements, µClinux) systems. ” Sounds great for embed- software and hardware, of the embedded ded systems development. Obviously, uClibc is platform being developed. We need to first going to be missing some features since its goal compare linuxthreads and nptl to is to be small in size. However, uClibc has its choose the thread library that best meets the own strengths as well. needs of our platform. Table 2 lists the key features the two thread libraries have to offer. 2.3 Comparing Features Using the table above, the nptl model is use- ful in systems that do not have severe memory constraints, but need threads to respond quickly Table 1 shows the important differentiating fea- and efficiently. The linuxthreads model is tures between glibc and uClibc. useful mostly for resource constrained systems still needing basic thread support. As men- It should be obvious from the table above that tioned at the beginning of this paper, embed- glibc certainly has better POSIX compliance, ded systems with faster processors and greater backwards binary compatibility, and network- memory resources are being required to do ing services support. uClibc shines in that it is more, with less. Using NPTL in conjunction much smaller (how much smaller will be cov- with the already small C library provided by ered later), more configurable, supports more uClibc, creates a perfectly balanced embedded processor architectures and is easier to build Linux system that has size, speed and an high- and maintain. performance multi-threading. 2006 Linux Symposium, Volume One • 411 Feature glibc uClibc LGPL Y Y Complete POSIX compliance Y N Binary compatibility across releases Y N NSS Support Y N NIS Support Y N Locale support Y Y Small disk storage footprint N Y Small runtime memory footprint N Y Supports MMU-less systems N Y Highly configurable N Y Simple build system N Y Built-in configuration system N Y Easily maintained N Y NPTL Support Y Y Linuxthreads Support N (See below) Y Support many processor architectures N (See below) Y Table 1: Library Feature Comparison Feature Description LinuxThreads NPTL Storage Size The actual amount of storage space consumed Smallest Largest in the file system by the libraries. The actual amount of RAM consumed at run- Memory Usage time by the thread library code and data. In- Smallest Largest cludes both kernel and user space memory us- age. Number of Threads The maximum number of threads available in a Hard Coded Value Dynamic process. Thread Efficiency Rate at which threads are created, destroyed, Slowest Fastest managed, and run. Per-Thread Signals Signals are handled on a per-thread basis and No Yes not the process. Inter-Thread Threads can share synchronization primitives Synchronization like mutexes and semaphores. No Yes POSIX.1 Compliance Thread library is compliant No Table 2: Thread Library Features 412 • Native POSIX Threads Library (NPTL) Support for uClibc. 4 uClibc NPTL Implementation loader must detect any TLS sections, allocate initial memory blocks for any needed TLS data, perform initial TLS relocations, and later per- The following sections outline the major tech- form additional TLS symbol look-ups and re- nical components of the NPTL implementation locations during the execution of the process. for uClibc. For the most part, they should apply It must also deal with the loading of shared equally to glibc’s implementation except where objects containing TLS data during program noted. References to additional papers and in- execution and properly allocate and relocate formation are provided should the reader wish its data. The TLS paper [6] provides ample to delve deeper into the inner workings of vari- overview of how these mechanisms work. The ous components. document does not, however, currently cover the specifics of MIPS-specific TLS storage and 4.1 TLS—The Foundation of NPTL implementation. MIPS TLS information is available from the Linux/MIPS website [9]. The first major component needed for NPTL on Adding TLS relocation support into uClibc’s Linux systems is Thread Local Storage (TLS). dynamic loader required close to 2200 lines Threads in a process share the same virtual ad- of code to change. The only functionality not dress space. Usually, any static or global data available in the uClibc loader is the handling of declared in the process is visible to all threads TLS variables in the dynamic loader itself. It within that process. TLS allows threads to have should also be noted that statically linked bi- their own local static and global data. An ex- naries using TLS/NPTL are not currently sup- cellent paper, written by Ulrich Drepper, cov- ported by uClibc. Static binaries will not be ers the technical details for implementing TLS supported until all processor architectures ca- for the ELF binary format [6]. Supporting TLS pable of supporting NPTL have working shared required extensive changes to binutils [7], GCC library support. In reality, shared library sup- [8] and glibc [1]. We cover the changes made port of NPTL is a prerequisite for debugging in the C library necessary to support TLS data. static NPTL support. Thank you to Daniel Ja- cobowitz for pointing this out. 4.1.1 The Dynamic Loader The dynamic loader, also affectionately known as ld.so, is responsible for the run-time link- 4.1.2 TLS Variables in uClibc ing of dynamically linked applications. The loader is the first piece of code to execute be- fore the main function of the application is There are four TLS variables currently used in called. It is responsible for loading and map- uClibc. The noticeable difference that can be ping in all required shared objects for the appli- observed in the source code is that they have cation.
Recommended publications
  • Linux and Electronics
    Linux and Electronics Urs Lindegger Linux and Electronics Urs Lindegger Copyright © 2019-11-25 Urs Lindegger Table of Contents 1. Introduction .......................................................................................................... 1 Note ................................................................................................................ 1 2. Printed Circuits ...................................................................................................... 2 Printed Circuit Board design ................................................................................ 2 Kicad ....................................................................................................... 2 Eagle ..................................................................................................... 13 Simulation ...................................................................................................... 13 Spice ..................................................................................................... 13 Digital simulation .................................................................................... 18 Wings 3D ....................................................................................................... 18 User interface .......................................................................................... 19 Modeling ................................................................................................ 19 Making holes in Wings 3D .......................................................................
    [Show full text]
  • FUJITSU AI Zinrai Deep Learning System 200M/210H Software License Terms
    FUJITSU AI Zinrai Deep Learning System 200M/210H Software License Terms Copyright 2021 FUJITSU LIMITED P3KD-1962-01EN 1. NVIDIA Product License Terms This product uses the following NVIDIA products. Name Version Tesla Driver for Linux x64 460.73.01 cuDNN 8.2.2 These NVIDIA products can be downloaded from the NVIDIA home page. http://www.nvidia.com/page/home.html Regarding the terms and conditions of the license for Tesla Driver for Linux x64 460.73.01, see "END USER LICENSE AGREEMENTS (EULA)" in the Appendix. Regarding the terms and conditions of the license for cuDNN 8.2.2, see "NVIDIA SOFTWARE LICENSE AGREEMENT" in the Appendix. 2. NGC Software This product contains the open source software ("OSS") as described in this document. The license terms for each OSS are as described below. • PyTorch 1.9.0 From PyTorch: Copyright (c) 2016- Facebook, Inc (Adam Paszke) Copyright (c) 2014- Facebook, Inc (Soumith Chintala) Copyright (c) 2011-2014 Idiap Research Institute (Ronan Collobert) Copyright (c) 2012-2014 Deepmind Technologies (Koray Kavukcuoglu) Copyright (c) 2011-2012 NEC Laboratories America (Koray Kavukcuoglu) Copyright (c) 2011-2013 NYU (Clement Farabet) Copyright (c) 2006-2010 NEC Laboratories America (Ronan Collobert, Leon Bottou, Iain Melvin, Jason Weston) Copyright (c) 2006 Idiap Research Institute (Samy Bengio) Copyright (c) 2001-2004 Idiap Research Institute (Ronan Collobert, Samy Bengio, Johnny Mariethoz) From Caffe2: Copyright (c) 2016-present, Facebook Inc. All rights reserved. All contributions by Facebook: Copyright (c) 2016 Facebook Inc. All contributions by Google: Copyright (c) 2015 Google Inc. All rights reserved. All contributions by Yangqing Jia: Copyright (c) 2015 Yangqing Jia All rights reserved.
    [Show full text]
  • Also Includes Slides and Contents From
    The Compilation Toolchain Cross-Compilation for Embedded Systems Prof. Andrea Marongiu ([email protected]) Toolchain The toolchain is a set of development tools used in association with source code or binaries generated from the source code • Enables development in a programming language (e.g., C/C++) • It is used for a lot of operations such as a) Compilation b) Preparing Libraries Most common toolchain is the c) Reading a binary file (or part of it) GNU toolchain which is part of d) Debugging the GNU project • Normally it contains a) Compiler : Generate object files from source code files b) Linker: Link object files together to build a binary file c) Library Archiver: To group a set of object files into a library file d) Debugger: To debug the binary file while running e) And other tools The GNU Toolchain GNU (GNU’s Not Unix) The GNU toolchain has played a vital role in the development of the Linux kernel, BSD, and software for embedded systems. The GNU project produced a set of programming tools. Parts of the toolchain we will use are: -gcc: (GNU Compiler Collection): suite of compilers for many programming languages -binutils: Suite of tools including linker (ld), assembler (gas) -gdb: Code debugging tool -libc: Subset of standard C library (assuming a C compiler). -bash: free Unix shell (Bourne-again shell). Default shell on GNU/Linux systems and Mac OSX. Also ported to Microsoft Windows. -make: automation tool for compilation and build Program development tools The process of converting source code to an executable binary image requires several steps, each with its own tool.
    [Show full text]
  • FPGA BASED RECONFIGURABLE BODY AREA NETWORK USING Nios II and Uclinux
    FPGA BASED RECONFIGURABLE BODY AREA NETWORK USING Nios II AND uClinux A Thesis Submitted to the College of Graduate Studies and Research in Partial Fulfillment of the Requirements for the Degree of Master of Science in the Department of Electrical and Computer Engineering University of Saskatchewan by Anthony Voykin Saskatoon, Saskatchewan, Canada c Copyright Anthony Voykin, April 2013. All rights reserved. Permission to Use In presenting this thesis in partial fulfillment of the requirements for a Postgraduate degree from the University of Saskatchewan, it is agreed that the Libraries of this University may make it freely available for inspection. Permission for copying of this thesis in any manner, in whole or in part, for scholarly purposes may be granted by the professors who supervised this thesis work or, in their absence, by the Head of the Department of Electrical and Computer Engineering or the Dean of the College of Graduate Studies and Research at the University of Saskatchewan. Any copying, publication, or use of this thesis, or parts thereof, for financial gain without the written permission of the author is strictly prohibited. Proper recognition shall be given to the author and to the University of Saskatchewan in any scholarly use which may be made of any material in this thesis. Request for permission to copy or to make any other use of material in this thesis in whole or in part should be addressed to: Head of the Department of Electrical and Computer Engineering 57 Campus Drive University of Saskatchewan Saskatoon, Saskatchewan, Canada S7N 5A9 i Acknowledgments I would like to thank my advisors Professor Ron Bolton and Professor Francis Bui for providing me with guidance and support necessary to complete my thesis work.
    [Show full text]
  • Embedded Linux Systems with the Yocto Project™
    OPEN SOURCE SOFTWARE DEVELOPMENT SERIES Embedded Linux Systems with the Yocto Project" FREE SAMPLE CHAPTER SHARE WITH OTHERS �f, � � � � Embedded Linux Systems with the Yocto ProjectTM This page intentionally left blank Embedded Linux Systems with the Yocto ProjectTM Rudolf J. Streif Boston • Columbus • Indianapolis • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City São Paulo • Sidney • Hong Kong • Seoul • Singapore • Taipei • Tokyo Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales depart- ment at [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the U.S., please contact [email protected]. Visit us on the Web: informit.com Cataloging-in-Publication Data is on file with the Library of Congress.
    [Show full text]
  • Embedded System Setting up Development Environment
    Embedded System Setting up Development Environment Tool chain installation GCC tool chain includes gcc compiler,assembler, linker, and other related utilities. (root@host)#rpm –ivh armtools-2.95.3- 5.i386.rpm Add /usr/local/gnu-2.95.3/bin to the searching path. (root@host)# export PATH=/usr/local/gnu- 2.95.3/bin:$PATH Setting up Development Environment Installing uClibc (root@host)#rpm –ivh uClibc-0.9.5- 1.i386.rpm The uClibc will be installed in /usr/local/uClibc-0.9.5 Building busybox BusyBox: The Swiss Army Knife of Embedded Linux Official site: http://busybox.net Install the BusyBox Configure the function of busybox Modify Makefile make Configure the function of busybox Config.h // This file defines the feature set to be compiled into busybox. // When you turn things off here, they won’t be compiled in at all. // //// This file is parsed by sed. You MUST use single line comments. // i.e., //#define BB_BLAH // // BusyBox Applications //#define BB_ADJTIMEX //#define BB_AR #define BB_ASH … # If you are running a cross compiler, you may want to set this # to something more interesting, like “powerpc-linux-“. CROSS = arm-elf- CC = $(CROSS)gcc … CROSS_CFLAGS+= -nostdinc –I$(LIBCDIR)/include –I$(GCCINCDIR) #Add below LIBCDIR=/usr/local/uClibc-0.9.5/linux-2.0.x GCCINCDIR=/usr/local/gnu-2.95.3/lib/gcc-lib/arm-elf/2.95/include Modify Makefile # If you are running a cross compiler, you may want to set this # to something more interesting, like “powerpc-linux-“. CROSS = arm-elf- CC = $(CROSS)gcc … CROSS_CFLAGS+= -nostdinc –I$(LIBCDIR)/include
    [Show full text]
  • Smashing the Stack Protector for Fun and Profit
    Smashing the Stack Protector for Fun and Profit Bruno Bierbaumer1 ( ), Julian Kirsch1, Thomas Kittel1, Aurélien Francillon2, and Apostolis Zarras3 1 Technical University of Munich, Munich, Germany [email protected] 2 EURECOM, Sophia Antipolis, France 3 Maastricht University, Maastricht, Netherlands Abstract. Software exploitation has been proven to be a lucrative busi- ness for cybercriminals. Unfortunately, protecting software against attacks is a long-lasting endeavor that is still under active research. However, certain software-hardening schemes are already incorporated into current compilers and are actively used to make software exploitation a compli- cated procedure for the adversaries. Stack canaries are such a protection mechanism. Stack canaries aim to prevent control flow hijack by detecting corruption of a specific value on the program’s stack. Careful design and implementation of this conceptually straightforward mechanism is crucial to defeat stack-based control flow detours. In this paper, we examine 17 different stack canary implementations across multiple versions of the most popular Operating Systems running on various architectures. We systematically compare critical implementation details and introduce one new generic attack vector which allows bypassing stack canaries on current Linux systems running up-to-date multi-threaded software altogether. We release an open-source framework (CookieCrumbler) that identifies the characteristics of stack canaries on any platform it is compiled on and we propose mitigation techniques against stack-based attacks. Although stack canaries may appear obsolete, we show that when they are used correctly, they can prevent intrusions which even the more sophisticated solutions may potentially fail to block. 1 Introduction Buffer overflow vulnerabilities are as old as the Internet itself.
    [Show full text]
  • Operating Systems and Applications for Embedded Systems >>> Toolchains
    >>> Operating Systems And Applications For Embedded Systems >>> Toolchains Name: Mariusz Naumowicz Date: 31 sierpnia 2018 [~]$ _ [1/19] >>> Plan 1. Toolchain Toolchain Main component of GNU toolchain C library Finding a toolchain 2. crosstool-NG crosstool-NG Installing Anatomy of a toolchain Information about cross-compiler Configruation Most interesting features Sysroot Other tools POSIX functions AP [~]$ _ [2/19] >>> Toolchain A toolchain is the set of tools that compiles source code into executables that can run on your target device, and includes a compiler, a linker, and run-time libraries. [1. Toolchain]$ _ [3/19] >>> Main component of GNU toolchain * Binutils: A set of binary utilities including the assembler, and the linker, ld. It is available at http://www.gnu.org/software/binutils/. * GNU Compiler Collection (GCC): These are the compilers for C and other languages which, depending on the version of GCC, include C++, Objective-C, Objective-C++, Java, Fortran, Ada, and Go. They all use a common back-end which produces assembler code which is fed to the GNU assembler. It is available at http://gcc.gnu.org/. * C library: A standardized API based on the POSIX specification which is the principle interface to the operating system kernel from applications. There are several C libraries to consider, see the following section. [1. Toolchain]$ _ [4/19] >>> C library * glibc: Available at http://www.gnu.org/software/libc. It is the standard GNU C library. It is big and, until recently, not very configurable, but it is the most complete implementation of the POSIX API. * eglibc: Available at http://www.eglibc.org/home.
    [Show full text]
  • Rmox: a Raw-Metal Occam Experiment
    Communicating Process Architectures – 2003 269 Jan F. Broenink and Gerald H. Hilderink (Eds.) IOS Press, 2003 RMoX: A Raw-Metal occam Experiment Fred BARNES†, Christian JACOBSEN† and Brian VINTER‡ † Computing Laboratory, University of Kent, Canterbury, Kent, CT2 7NF, England. {frmb2,clj3}@kent.ac.uk ‡ Department of Mathematics and Computer Science, University of Southern Denmark, Odense, Denmark. [email protected] Abstract. Operating-systems are the core software component of many modern com- puter systems, ranging from small specialised embedded systems through to large distributed operating-systems. This paper presents RMoX: a highly concurrent CSP- based operating-system written in occam. The motivation for this stems from the overwhelming need for reliable, secure and scalable operating-systems. The major- ity of operating-systems are written in C, a language that easily offers the level of flexibility required (for example, interfacing with assembly routines). C compilers, however, provide little or no mechanism to guard against race-hazard and aliasing er- rors, that can lead to catastrophic run-time failure (as well as to more subtle errors, such as security loop-holes). The RMoX operating-system presents a novel approach to operating-system design (although this is not the first CSP-based operating-system). Concurrency is utilised at all levels, resulting in a system design that is well defined, easily understood and scalable. The implementation, using the KRoC extended oc- cam, provides guarantees of freedom from race-hazard and aliasing errors, and makes extensive use of the recently added support for dynamic process creation and channel mobility. Whilst targeted at mainstream computing, the ideas and methods presented are equally applicable for small-scale embedded systems — where advantage can be made of the lightweight nature of RMoX (providing fast interrupt responses, for ex- ample).
    [Show full text]
  • A Review on Elliptic Curve Cryptography for Embedded Systems
    International Journal of Computer Science & Information Technology (IJCSIT), Vol 3, No 3, June 2011 A REVIEW ON ELLIPTIC CURVE CRYPTOGRAPHY FOR EMBEDDED SYSTEMS Rahat Afreen 1 and S.C. Mehrotra 2 1Tom Patrick Institute of Computer & I.T, Dr. Rafiq Zakaria Campus, Rauza Bagh, Aurangabad. (Maharashtra) INDIA [email protected] 2Department of C.S. & I.T., Dr. B.A.M. University, Aurangabad. (Maharashtra) INDIA [email protected] ABSTRACT Importance of Elliptic Curves in Cryptography was independently proposed by Neal Koblitz and Victor Miller in 1985.Since then, Elliptic curve cryptography or ECC has evolved as a vast field for public key cryptography (PKC) systems. In PKC system, we use separate keys to encode and decode the data. Since one of the keys is distributed publicly in PKC systems, the strength of security depends on large key size. The mathematical problems of prime factorization and discrete logarithm are previously used in PKC systems. ECC has proved to provide same level of security with relatively small key sizes. The research in the field of ECC is mostly focused on its implementation on application specific systems. Such systems have restricted resources like storage, processing speed and domain specific CPU architecture. KEYWORDS Elliptic curve cryptography Public Key Cryptography, embedded systems, Elliptic Curve Digital Signature Algorithm ( ECDSA), Elliptic Curve Diffie Hellman Key Exchange (ECDH) 1. INTRODUCTION The changing global scenario shows an elegant merging of computing and communication in such a way that computers with wired communication are being rapidly replaced to smaller handheld embedded computers using wireless communication in almost every field. This has increased data privacy and security requirements.
    [Show full text]
  • Betrfs: a Right-Optimized Write-Optimized File System
    BetrFS: A Right-Optimized Write-Optimized File System William Jannen, Jun Yuan, Yang Zhan, Amogh Akshintala, Stony Brook University; John Esmet, Tokutek Inc.; Yizheng Jiao, Ankur Mittal, Prashant Pandey, and Phaneendra Reddy, Stony Brook University; Leif Walsh, Tokutek Inc.; Michael Bender, Stony Brook University; Martin Farach-Colton, Rutgers University; Rob Johnson, Stony Brook University; Bradley C. Kuszmaul, Massachusetts Institute of Technology; Donald E. Porter, Stony Brook University https://www.usenix.org/conference/fast15/technical-sessions/presentation/jannen This paper is included in the Proceedings of the 13th USENIX Conference on File and Storage Technologies (FAST ’15). February 16–19, 2015 • Santa Clara, CA, USA ISBN 978-1-931971-201 Open access to the Proceedings of the 13th USENIX Conference on File and Storage Technologies is sponsored by USENIX BetrFS: A Right-Optimized Write-Optimized File System William Jannen, Jun Yuan, Yang Zhan, Amogh Akshintala, John Esmet∗, Yizheng Jiao, Ankur Mittal, Prashant Pandey, Phaneendra Reddy, Leif Walsh∗, Michael Bender, Martin Farach-Colton†, Rob Johnson, Bradley C. Kuszmaul‡, and Donald E. Porter Stony Brook University, ∗Tokutek Inc., †Rutgers University, and ‡Massachusetts Institute of Technology Abstract (microwrites). Examples include email delivery, creat- The Bε -tree File System, or BetrFS, (pronounced ing lock files for an editing application, making small “better eff ess”) is the first in-kernel file system to use a updates to a large file, or updating a file’s atime. The un- write-optimized index. Write optimized indexes (WOIs) derlying problem is that many standard data structures in are promising building blocks for storage systems be- the file-system designer’s toolbox optimize for one case cause of their potential to implement both microwrites at the expense of another.
    [Show full text]
  • MC-1200 Series Linux Software User's Manual
    MC-1200 Series Linux Software User’s Manual Version 1.0, November 2020 www.moxa.com/product © 2020 Moxa Inc. All rights reserved. MC-1200 Series Linux Software User’s Manual The software described in this manual is furnished under a license agreement and may be used only in accordance with the terms of that agreement. Copyright Notice © 2020 Moxa Inc. All rights reserved. Trademarks The MOXA logo is a registered trademark of Moxa Inc. All other trademarks or registered marks in this manual belong to their respective manufacturers. Disclaimer Information in this document is subject to change without notice and does not represent a commitment on the part of Moxa. Moxa provides this document as is, without warranty of any kind, either expressed or implied, including, but not limited to, its particular purpose. Moxa reserves the right to make improvements and/or changes to this manual, or to the products and/or the programs described in this manual, at any time. Information provided in this manual is intended to be accurate and reliable. However, Moxa assumes no responsibility for its use, or for any infringements on the rights of third parties that may result from its use. This product might include unintentional technical or typographical errors. Changes are periodically made to the information herein to correct such errors, and these changes are incorporated into new editions of the publication. Technical Support Contact Information www.moxa.com/support Moxa Americas Moxa China (Shanghai office) Toll-free: 1-888-669-2872 Toll-free: 800-820-5036 Tel: +1-714-528-6777 Tel: +86-21-5258-9955 Fax: +1-714-528-6778 Fax: +86-21-5258-5505 Moxa Europe Moxa Asia-Pacific Tel: +49-89-3 70 03 99-0 Tel: +886-2-8919-1230 Fax: +49-89-3 70 03 99-99 Fax: +886-2-8919-1231 Moxa India Tel: +91-80-4172-9088 Fax: +91-80-4132-1045 Table of Contents 1.
    [Show full text]