DOCSLIB.ORG

Betriebssysteme Operating Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Betriebssysteme Operating Systems HTBLVA FÜR EDV UND ORGANISATION SPENGERGASSE Betriebssysteme Operating Systems Bernhard Friedreich, 4AHDVK 23.11.2008 Dieses Dokument beschreibt den Grundaufbau von Betriebssystemen und vergleicht, anhand vielfacher Aspekte, die wichtigsten Betriebssysteme miteinander. Fachbegriffe, die aus dem Englischen kommen, werden im Original verwendet, um der Eindeutschung von Fachbegriffen entgegen zu wirken. Inhaltsverzeichnis 1. Einführung ............................................................................................................................... 4 1.1. Grundlagen ...................................................................................................................... 4 1.1.1. Was ist ein Betriebssystem? ........................................................................................ 4 1.1.2. Grundlegende Aufgaben ............................................................................................. 4 1.1.3. Geschichte ................................................................................................................... 5 1.1.4. Häufig genutzte Betriebssysteme ................................................................................ 6 1.1.5. Sonstige Betriebssysteme............................................................................................ 7 2. Kernel ...................................................................................................................................... 8 2.1. Grundlagen ...................................................................................................................... 8 2.2. Architekturen................................................................................................................... 8 2.2.1. Microkernel ................................................................................................................. 9 2.2.2. Monolithic kernel ........................................................................................................ 9 2.2.3. Hybrid Kernel ............................................................................................................. 10 2.2.4. Monolithic vs. Micro vs. Hybrid ................................................................................. 10 2.2.5. Exokernel ................................................................................................................... 10 2.3. Inter‐Process Communication (IPC) .............................................................................. 11 2.4. Sicherheit und Design .................................................................................................... 11 2.4.1. Virtual Memory/Paging ............................................................................................. 12 2.5. Scheduler ....................................................................................................................... 12 2.5.1. Auswahl an Strategien/Scheduler ............................................................................. 13 2.6. Treiber ........................................................................................................................... 13 2.7. Hardware Abstraction Layer (HAL) ................................................................................ 13 2.8. Dateisysteme ................................................................................................................. 14 2.8.1. Arten .......................................................................................................................... 14 2.9. Interrupts ....................................................................................................................... 15 2.10. Windows NT .................................................................................................................. 16 2.11. Linux .............................................................................................................................. 16 2.12. Mac OS X ........................................................................................................................ 17 2.13. GNU Hurd ...................................................................................................................... 17 3. Startup ................................................................................................................................... 18 3.1. Grundlagen .................................................................................................................... 18 3.2. Bootloader ..................................................................................................................... 18 3.2.1. Multistage Boot‐Loader ............................................................................................. 18 3.2.2. Chain‐Loader ............................................................................................................. 18 Seite 2 von 28 3.3. Linux .............................................................................................................................. 19 3.4. Mac OS X ........................................................................................................................ 20 3.5. Frühere Windows Versionen ......................................................................................... 20 3.6. Windows Vista ............................................................................................................... 20 4. Graphische Oberfläche .......................................................................................................... 21 4.1. Graphische Subsystems ................................................................................................. 21 4.1.1. Linux (X Server) .......................................................................................................... 21 4.1.2. Mac OS X (Quartz) ..................................................................................................... 22 4.2. Linux Desktop Environments ......................................................................................... 22 4.2.1. Gnome ....................................................................................................................... 23 4.2.2. KDE 3 .......................................................................................................................... 24 4.2.3. KDE 4 .......................................................................................................................... 25 4.3. Window Manager .......................................................................................................... 26 4.3.1. Grundlagen ................................................................................................................ 26 5. Quellen .................................................................................................................................. 28 Seite 3 von 28 1. Einführung 1.1. Grundlagen 1.1.1. Was ist ein Betriebssystem? Ein Betriebssystem ist eine Software, welche die Verwendung eines PCs ermöglicht, indem sie eine Schnittstelle zur Hardware darstellt, sie verwaltet, und andere Aufgaben durchführt, ohne denen es nicht möglich wäre die PC‐ Hardware zu verwenden. Weiters zählt zu den Aufgaben eines Betriebssystems die Verwaltung von Ein‐ und Ausgabegeräte, die korrekte Zuteilung von Speicherbereichen und die Ausführung von Programmen. 1.1.1.1. Begriffserklärung Für den Begriff Betriebssystem existiert keine eindeutige Definition und er kann sehr weitläufig verwendet werden. Der englische Stammbegriff hatte eine spezielle Bedeutung, auf die später näher eingegangen wird. Der Kernel ist die einzige Komponente, die in allen Definitionen des Wortes Betriebssystems enthalten ist. Im engeren Sinne ist der Kernel das Betriebssystem. Daher würde man, wenn man von Linux spricht eigentlich korrekterweise vom Kernel sprechen. Meist ist damit jedoch das ganze System gemeint. Wenn man vom kompletten System spricht, so sollte man es als Distribution (Zusammenstellung von Tools und Komponenten) bezeichnen. Diese klare Trennung ist jedoch bei proprietären System nicht möglich, weshalb der Begriff Betriebssystem sich nicht klar definieren lässt. Weitere Komponenten, die in einigen Definitionen enthalten sind, umfassen folgende Themen: • Hardware Verwaltung • Treiber • Schnittstelle für Systemfunktionen • Teile einer Grafischen Oberfläche • System‐ Dienste, ‐Programme • Interprocess Communication (IPC) • Dateisysteme • Datentransfer über Netzwerke • Skriptsprache für das System • Bootloader • Programmbibliotheken 1.1.2. Grundlegende Aufgaben Ein Betriebssystem hat vielerlei Aufgabengebiete. An vorderster Stelle ermöglicht es uns die Arbeit mit einem Computer. Weitere Aufgabengebiete sind: • Verwaltung der Prozessorzeit • Verwaltung des Speicherplatzes für Anwendungen • Verwaltung der (angeschlossenen) Geräte • Laden und Unterbrechen von Programmen • Bereitstellung von Schnittstellen für Programme Seite 4 von 28 1.1.3. Geschichte Betriebssysteme in der Form, wie wir sie nun kennen existieren vergleichsweise kurz, zu den Systemen, die es früher gab. Es waren keine Systeme, wie Windows oder Linux, wie wir sie derzeit kennen mit einem Terminal oder einer Grafischen Oberfläche sondern Systeme, die man per Hand bedienen musste. Eines davon waren die Lochkartensysteme. 1.1.3.1. Lochkartensysteme Beim Einsatz von Lochkartensystemen brauchte man eine Person dazu, das System mit Lochkarten zu „füttern“. Dies war der sogenannte „Operator“,
Load more

Recommended publications
  • Provenance-Based Computing
    UCAM-CL-TR-930 Technical Report ISSN 1476-2986 Number 930 Computer Laboratory Provenance-based computing Lucian Carata December 2018 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 https://www.cl.cam.ac.uk/ c 2018 Lucian Carata This technical report is based on a dissertation submitted July 2016 by the author for the degree of Doctor of Philosophy to the University of Cambridge, Wolfson College. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: https://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 Provenance-based computing Lucian Carata Summary Relying on computing systems that become increasingly complex is difficult: with many factors potentially affecting the result of a computation or its properties, understanding where problems appear and fixing them is a challenging proposition. Typically, the process of finding solutions is driven by trial and error or by experience-based insights. In this dissertation, I examine the idea of using provenance metadata (the set of elements that have contributed to the existence of a piece of data, together with their relationships) instead. I show that considering provenance a primitive of computation enables the ex- ploration of system behaviour, targeting both retrospective analysis (root cause analysis, performance tuning) and hypothetical scenarios (what-if questions). In this context, prove- nance can be used as part of feedback loops, with a double purpose: building software that is able to adapt for meeting certain quality and performance targets (semi-automated tun- ing) and enabling human operators to exert high-level runtime control with limited previous knowledge of a system’s internal architecture.
    [Show full text]
  • Arhitectura Sistemelui De Fisiere FAT
    Facultatea de Electronica, Telecomunicatii si Tehnologia Informatiei Universitatea „Politehnica” , Bucuresti Arhitectura sistemelui de fisiere FAT Profesor Coordonator : Student: Conf.dr.ing. Stefan Stancescu Patriche Nicolae - Cristian Cuprins : Introducere …………………………………………………………………pg2 Utilizari, evolutie tehnica ………………………………………………… pg3 Sectorizare logica FAT …………………………………………………pg5 Extensii…………………………………………………………..…............pg7 Derivate.................………………………………………………………….pg8 Proiectare si design tehnic ………………………………………………....pg9 Sectorul de boot……………………………………………………….........pg10 BIOS Parameter Block ……………………………………………………pg19 Extended BIOS Parameter Block …………………………………………pg22 FAT32 Extended BIOS Parameter Block............................……………pg23 Exceptii……………………………………………………….…..............pg25 Sectorul de informatii FS……………………………………………….……pg27 Numele lung al fisierelor VFAT…………………………………………...pg28 Comparatii intre sisteme de fisiere……………………………………… pg30 Concluzii……………………………………………………......................pg45 Referinte ……………………………………………………....................pg45-46 1 Introducere 1.Privire de ansamblu File Allocation Table (FAT) este numele unei arhitecturi pentru fisiere de sistem și in momentul de fata o intreaga familie din industria de lucru a fișierelor folosesc aceasta arhitectura. Sistemul de fișiere FAT este un sistem de fișiere simplu și robust. Oferă performanțe bune chiar și în implementările mai laborioase , dar nu poate oferi aceeași performanță, fiabilitate și scalabilitate ca unele sisteme moderne de fișiere. Totuși,
    [Show full text]
  • Einführung in Die Informatik Inf, SAT, Wing, Mi
    Einführung in die Informatik Inf, SAT, Wing, Mi Dipl.-Inf., Dipl.-Ing. (FH) Michael Wilhelm Hochschule Harz FB Automatisierung und Informatik [email protected] http://www.miwilhelm.de Raum 2.202 Tel. 03943 / 659 338 FB Automatisierung und Informatik: Einführung in die Informatik 1 Inhalt 1. Grundlagen der Informatik Zahlensysteme, Nachkommazahlen, Single-Format 2. Rechnerarchitekturen (Hard- und Softwaresysteme) Rechnerarchitekturen, Betriebssysteme, 3. Programmierung Sprachen, Datentypen, Datenstrukturen, Programmiermodelle, Compiler, Programmierparadigmen, Domänenspezifische Sprachen, Algorithmen 4. Verteilte Systeme (Netzwerke) 5. Themenfelder der Informatik Datenbanken, Big Data, Multimediaverarbeitung, Software Engineering, KI, Human Computing Interface, Robotics, VR/AR FB Automatisierung und Informatik: Einführung in die Informatik 2 1 Klassifizierung von Rechnerarchitekturen: . Einprozessorsysteme John v. Neumann – Eine CPU – Ein Bus Havard-Rechnerarchitekturen – Mehrere CPU‘s – Mindestens zwei Bussysteme (North- und SouthBridge) – Aufteilen der Geräte in Bezug auf die Geschwindigkeit FB Automatisierung und Informatik: Einführung in die Informatik 3 Von-Neumann Architektur nach John von Neumann Steuerwerk Befehlszähler Befehl Ein-/ Akumulator Speicher Ausgabe Prozessor = Daten Rechenwerk + Arithmetic-Logical-Unit (ALU) + Daten Steuerwerk Speicher ALU Module FB Automatisierung und Informatik: Einführung in die Informatik 4 2 Rechenwerk: ALU MDU BITP SFT ALU: Arithmetisch-Logische-Einheit MDU: Mupliplikation / Division
    [Show full text]
  • Failsafe Filesystem for Linux
    Tux2 Failsafe Filesystem for Linux Daniel Phillips, innominate AG [email protected] What is Tux2? Failsafe like a journalling filesystem But doesn't have a journal No recovery procedure needed No journal replay needed Instant off/Instant on Based on Ext2 - convert on mount (.1 sec/gig) Full data and metadata protection less overhead than metadata-only journalling Uses phase tree algorithm Atomic update, single/multiple transactions Checkpointing is a simple extension Background defrag is a simple extension Failed write? Try again somewhere else Tux2's Phase Tree algorithm Started life in a database 1989 - Nirvana db persistent objects crash proof Other failsafe approaches Journalling Soft Updates (needs fsck) Logging file system Other atomic update algorithms Shadow blocks Auragen WAFL (see: Evil Patents) Phase Tree algorithm Filesystem must be structured as tree metadata tree, not directory tree Ext2 *not* structured as a tree Create branches of new tree in freespace of old Atomic update single write of the filesystem metaroot actually a set of locations phase counter to find current detect crash by metaroots not same instant revert to last consistent state Allocation maps are part of tree Phase Tree algorithm Phase start: copy the metaroot Update a block: Make changes in copy of block Update parent to point at copy recurse up to metaroot stop if already updated Original block onto defree list Applies to allocation bitmaps too Free a block: Put it onto defree list Phase end: Free all defreed blocks Schedule updated blocks for writing Phases Two priority relationships Write phase blocks before metaroot Write metaroot before next phase blocks Gives partial ordering of writes phase, root, phase, root..
    [Show full text]
  • 99" GET MISS from HOME FLASH US 8,732,386 B2 Page 2
    US008732386B2 (12) United States Patent (10) Patent N0.: US 8,732,386 B2 O’Krafka et al. (45) Date of Patent: May 20, 2014 (54) SHARING DATA FABRIC FOR (56) References Cited COHERENT-DISTRIBUTED CACHING OF U.S. PATENT DOCUMENTS MULTI-NODE SHARED-DISTRIBUTED FLASH MEMORY 4,916,605 A 4/1990 Beardsley et a1. 5,046,002 A 9/1991 Takashi et a1. (75) Inventors: Brian Walter O’Krafka, Austin, CA 5,057,996 A 10/1991 Cutler et a1. (US); Michael John Koster, Bridgeville, 5,117,350 A 5/1992 Parrish et a1. 5,212,789 A 5/1993 Rago CA (US); Darpan Dinker, Union City, 5,287,496 A 2/1994 Chen et a1. CA (US); Earl T. Cohen, Oakland, CA 5,297,258 A 3/1994 Hale et a1. (US); Thomas M. McWilliams, Oakland, CA (US) (Continued) FOREIGN PATENT DOCUMENTS (73) Assignee: Sandisk Enterprise IP LLC., Milpitas, CA (US) EP 1548600 Bl 1/2007 EP 1746510 Al 1/2007 (*) Notice: Subject to any disclaimer, the term of this OTHER PUBLICATIONS patent is extended or adjusted under 35 U.S.C. 154(b) by 929 days. Bsn-modulestore, Versioning Concept, Oct. 13, 2010, 2 pgs. Btrfs, http://en.wikipedia.0rg, Oct. 3, 2011, 9 pgs. (21) Appl. N0.: 12/197,s99 (Continued) (22) Filed: Aug. 25, 2008 Primary Examiner * Larry Mackall (74) Attorney, Agent, or Firm * Morgan, LeWis & Bockius Prior Publication Data (65) LLP US 2009/0240869 A1 Sep. 24, 2009 (57) ABSTRACT A Sharing Data Fabric (SDF) causes ?ash memory attached Related US. Application Data to multiple compute nodes to appear to be a single large memory space that is global yet shared by many applications (63) Continuation-in-part of application No.
    [Show full text]
  • Ausarbeitung •fi Seminar Â
    Linux-Dateisysteme Seminar »Speicher- und Dateisysteme« Arbeitsbereich Wissenschaftliches Rechnen Fachbereich Informatik Fakultät für Mathematik, Informatik und Naturwissenschaften Universität Hamburg Autor: Lars Thoms <[email protected]> Betreuer: Dr. Julian Kunkel Version: 2016-05-02 Lars Thoms Vorwort Dateisysteme: Jeder braucht sie – wenige wissen, dass es sie gibt – kaum jemand weiß, wie sie funktion- ieren. Diese Ausarbeitung zum Vortrag »Linux-Dateisysteme« im Rahmen des Seminars »Speicher- und Dateisysteme« erläutert Schritt für Schritt den Aufbau und die Funktionsweise eines Dateisystems und deren Komponenten. Zu Beginn werden Partitionen, deren Verwaltung und Funktionsweise erläutert. Als Beispiel herangezo- gen werden sowohl das weit verbreitete MBR und das neuere GPT. Abschließend werden spezielle Konfig- urationen, wie LVM und RAID betrachtet. Mit diesen Grundlagen beginnt das eigentliche Thema. Die Definition, Semantik und das Konzept eines Dateisystems, gefolgt von einer Übersicht der bekannten Dateisysteme und deren Einordnung. Die Funktionsweisen von Dateisystemen werden anhand von zwei bekannteren Beispielen erläutert: EXT4 und BTRFS. Garniert mit Code- und Befehlsschnippseln, welche die Erstellung, Administration und Funktionsweise der beiden Vertreter verdeutlichen sollen. 2 Lars Thoms Inhaltsverzeichnis 1 Partition(stabellen) 4 1.1 Definition »Partition« . .4 1.2 Partitionstabelle . .4 1.3 MBR (eine Partitionstabelle) . .4 1.3.1 Aufbau des MBR . .5 1.4 Primäre/Logische Partition . .6 1.5 GPT (eine bessere Partitionstabelle) . .6 1.5.1 Aufbau der GPT . .6 1.5.2 GPT mit zwei Partitionen erstellen . .7 1.6 RAID . .9 1.7 LVM.............................................. 10 2 Konzept eines Dateisystems 11 2.1 Definition »Dateisystem« . 11 2.2 Aufbau eines Dateisystems . 11 2.3 Semantik eines Dateisystems . 11 2.3.1 POSIX .
    [Show full text]
  • Kernel Development: How Things Go Wrong
    Kernel development: How things go wrong (And why you should participate anyway) Jonathan Corbet LWN.net [email protected] Kernel development is a success ~5 releases/year > 10,000 changes/release > 1000 developers/release Linux is showing up in everything ...it works! Kernel development is a success ~5 releases/year > 10,000 changes/release > 1000 developers/release Linux is showing up in everything ...it works! So why talk about failure? High profile failures give the kernel a bad name. “A key Linux contributor has admitted the the developer community can be intimidating and hard to break into.” “A key Linux contributor has admitted the the developer community can be intimidating and hard to break into.” (Seen on slashdot - must be true) Failure can teach us things “It's fine to celebrate success, but it is more important to heed the lessons of failure.” “It's fine to celebrate success, but it is more important to heed the lessons of failure.” --Bill Gates “A bridge, under its usual conditions of service, behaves simply as a relatively smooth level surface on which vehicles can move. Only when it has been overloaded do we learn the physical properties of the materials from which it is built.” -- Herbert Simon One note The kernel community does not lack for clowns. One note The kernel community does not lack for clowns. I am not talking about them. This talk will be naming names Every developer I name has my respect! “Hey, all my other theories made sense too. They just didn't work. But as Edison said: I didn't fail, I just found three other ways not to fix your bug.” -- Linus Torvalds Photo: fireflythegreat Tux3 A next-generation filesystem by Daniel Phillips 2008-07-23 Initial announcement 2008-11-25 Booting as root filesystem 2009-08-16 Last commit “Do NOT fall into the trap of adding more and more stuff to an out-of-tree project.
    [Show full text]
  • TCSS 422: Operating Systems [Fall 2016] 12/7/2016 Institute of Technology, UW-Tacoma
    TCSS 422: Operating Systems [Fall 2016] 12/7/2016 Institute of Technology, UW-Tacoma TCSS 422: OPERATING SYSTEMS OBJECTIVES ° Introduction to RAID File Systems and ° File systems – structure RAID ° File systems – inodes Wes J. Lloyd ° File systems - indexing Institute of Technology University of Washington - Tacoma TCSS422: Operating Systems [Fall 2016] December 7, 2016 L22.2 Institute of Technology, University of Washington - Tacoma RAID RAID CONTROLLER ° Redundant array of inexpensive disks (RAID) ° Special hardware RAID controllers offer ° Enable multiple disks to be grouped together to: ° Microcontroller ° Provides firmware to direct RAID operation ° Provide the illusion of one giant disk ° Volatile memory ° For performance improvements ° Striping: For mirrored disks we can increase read speeds splitting ° Non-volatile memory read transactions to run in parallel across two physical disks ° Buffers writes in case of power loss ° For redundancy ° Specialized logic to perform parity calculations ° Mirroring: duplication of data TCSS422: Operating Systems [Fall 2016] TCSS422: Operating Systems [Fall 2016] December 7, 2016 L22.3 December 7, 2016 L22.4 Institute of Technology, University of Washington - Tacoma Institute of Technology, University of Washington - Tacoma RAID LEVEL 0 - STRIPING RAID LEVEL 1 - MIRRORING ° RAID Level 0: Simplest form ° RAID 1 tolerates HDD failure ° Stripe blocks across disk in a round-robin fashion ° Two copies of each block across disks ° Excellent performance and capacity ° Capacity ° Capacity is equal to the sum of all disks ° Performance ° R/W are distributed in round-robin fashion across all disks ° Reliability ° RAID 10 (RAID 1 + RAID 0): Mirror then stripe data ° No redundancy ° RAID 01 (RAID 0 + RAID 1): Stripe then mirror data TCSS422: Operating Systems [Fall 2016] TCSS422: Operating Systems [Fall 2016] December 7, 2016 L22.5 December 7, 2016 L22.6 Institute of Technology, University of Washington - Tacoma Institute of Technology, University of Washington - Tacoma Slides by Wes J.
    [Show full text]
  • Evaluation of Performance and Space Utilisation When Using Snapshots in the ZFS and Hammer File Systems
    UNIVERSITY OF OSLO Department of Informatics Evaluation of Performance and Space Utilisation When Using Snapshots in the ZFS and Hammer File Systems Master thesis Martin Christoffer Aasen Oppegaard Network and System Administration Oslo University College Spring 2009 Evaluation of Performance and Space Utilisation When Using Snapshots in the ZFS and Hammer File Systems Martin Christoffer Aasen Oppegaard Network and System Administration Oslo University College Spring 2009 Abstract Modern file systems implements snapshots, or read-only point-in-time rep- resentations of the file system. Snapshots can be used to keep a record of the changes made to the data, and improve backups. Previous work had shown that snapshots decrease read- and write performance, but there was an open question as to how the number of snapshots affect the file system. This thesis studies this on the ZFS and Hammer file systems. The study is done by run- ning a series of benchmarks and creating snapshots of each file system. The results show that performance decreases significantly on both ZFS and Ham- mer, and ZFS becomes unstable after a certain point; there is a steep decrease in performance, and increase in latency and the variance of the measurements. The performance of ZFS is significantly lower than on Hammer, and the per- formance decrease is higher. On space utilisation, the results are linear for ZFS, up to the point where the system turns unstable. The results are not linear on Hammer, but more work is needed to reveal by which function. Acknowledgements I wish to thank the following list of individuals, which have made possible this final work to end a two years master’s program in network and system administration.
    [Show full text]
  • Operating Systems Software Eng
    TCSS 422 B – Spring 2020 6/4/2020 School of Engineering and Technology FALL 2020 - TCSS 562 TCSS 422: OPERATING SYSTEMS SOFTWARE ENG. FOR CLOUD COMPUTING This is a “cloud computing” course Previous year’s course: http://faculty.washington.edu/wlloyd/courses/tcss562 Course introduces major cloud computing delivery models: HDDs, RAID, File Systems Infrastructure-as-a-Service (IaaS), Platform (PaaS), Functions Final Exam Review (FaaS), Container (CaaS), Software (SaaS) Course features a software development project where we Wes J. Lloyd build and evaluate software entirely for the cloud Fall 2019 focus: developing serverless software: e.g. data School of Engineering and Technology processing pipelines University of Washington - Tacoma Fall 2020 focus: serverless/cloud-native software, containerization, cloud services TCSS422: Operating Systems [Spring 2020] TCSS422: Operating Systems [Spring 2020] June 4, 2020 June 4, 2020 L19.2 School of Engineering and Technology, University of Washington - Tacoma School of Engineering and Technology, University of Washington - Tacoma NEXT YEAR - TCSS 498/499 (ANY QUARTER) TCSS 562 – CLOUD COMPUTING - 2 UNDERGRADUATE READIN/RESEARCH IN CSS Class does not have prerequisites Independent study in “cloud computing” TCSS 422 provides good foundation – we use Linux Work to collaboratively draft a proposal and submit to Dr. Chinn, CSS Chair for Approval If interested in enrolling, contact by email Focus on variety of topics related to cloud/distributed systems Can take 1 x 500-level class, counts as 400-level elective Variable credits from 1 to 5 . SAVINGS: able to take graduate course and only pay Involves participation in weekly research group meeting undergraduate tuition . Spring 2020: currently Wednesday at 12:30p DOUBLE-DIP !! Usually 1 or 2 one-on-one or small group meeting during week .
    [Show full text]
  • Zack's Kernel News
    Community Notebook Kernel News Zack’s Kernel News Chronicler Zack Status of OverlayFS and Union technical problems that remain. At the mo- Filesystems in General ment, none of the projects seem close to get- Brown reports on Recently, Miklos Szeredi requested that Over- ting past Al’s laser-beam code reviews, and the latest news, layFS be included in the main kernel tree. until that happens, I’m certain none of them OverlayFS allows two directory trees to appear will be merged. views, dilemmas, as one. Two files with the same path on each tree would appear to occupy the same direc- Astonishing Tux3 and developments tory in the overlayed filesystem. The project Performance Claims within the Linux has been in existence for several years, but this There seems to be some suspicion between time Linus Torvalds replied, “Yes, I think we certain kernel developers and Tux3 develop- kernel community. should just do it. It’s in use, it’s pretty small, ers. Tux3 is a versioning filesystem that’s and the other alternatives are worse. Let’s just been in development since 2008. Recently, By Zack Brown plan on getting this thing done with.” Daniel Phillips, the project leader, posted Al Viro said he’d start reviewing the code, some benchmarks that showed Tux3 outper- but he also suggested that if they were going to forming tmpFS. As he put it, “To put this in merge a union filesystem such as OverlayFS, perspective, we normally regard tmpfs as un- they might as well consider merging other sim- beatable because it is just a thin shim be- ilar projects, such as Unionmount and Aufs.
    [Show full text]
  • The NILFS2 Filesystem: Review and Challenges
    Ryusuke KONISHI NTT Cyberspace Laboratories NTT Corporation — NILFS Introduction — FileSystem Design — Development Status — Wished features & Challenges Copyright (C) 2009 NTT Corporation 2 — NILFS is the Linux file system supporting “continuous snapshotting” üProvides versioning capability of entire file system üCan retrieve previous states before operation mistake even restores files mistakenly overwritten or destroyed just a few seconds ago. üMerged into the mainline kernel 2.6.30 Copyright (C) 2009 NTT Corporation 3 CAUSE OF DATA LOSS Software Viruses Natural disaster malfunction 4% 2% 9% Human error Hardware 26% failure 59% Unprotected by redundant drives. Mostly preventable with basic high-integrity system Source: Ontrack Data Recovery, Inc. (Redundant configuration) Including office PC.The data is based on actual data recoveries performed by Ontrack. Copyright (C) 2009 NTT Corporation 4 ISSUES IN BACKUP — Changes after the last backup are not safe — But, frequent backups place burden on the system as well as the interval is limited by the backup time. Incrementally done Hard drive Backup Discretely scheduled e.g. per 8 hours, per day Backup Backup Some applications (esp. for system software) Restoration is cumbersome are sensitive to coherency among files (and often fails or unhelpful) Copyright (C) 2009 NTT Corporation 5 — Adopt Log-structured File System approach to continually save data on disk. — Checkpoints are created every time user makes a change, and each checkpoint is mutable to snapshots later on. Instantly Ordinary
    [Show full text]