6.033 | Spring 2018 | Undergraduate

Computer System Engineering

Week 2: Operating Systems Part II

Lecture 2: Naming in Systems

Lecture 2 Outline

  1. Previous Lecture/Introduction
  2. Naming in General
  3. Abstract View of Naming Schemes
  4. Naming on the Internet: DNS

Lecture Slides

Reading

  • Book sections 2.2 and 3.1

Hands-on Assignment 1: Domain Name System (DNS)

(Not available to OCW users.)

Recitation 3: Domain Name System (DNS)

Lecture 3: Operating Systems + Virtual Memory

Lecture 3 Outline

  1. Previously
  2. Operating Systems
  3. Virtual Memory
  4. Page Tables
  5. Hierarchical Page Tables
  6. Kernel
  7. Abstraction
  8. Virtual Memory as Naming

Lecture Slides

Reading

  • Book sections 5.1, 5.3, and 5.4

Recitation 4: UNIX Part 1

Hands-on Assignment 2: UNIX

(Not available to OCW users.)

Tutorial 2: Consensus and Critique

One of the goals of 6.033 is for students to be able to analyze and critique technical systems. We will assign multiple system critiques during the semester.

These critiques will be graded by your TAs and/or Communication Instructors, and assigned a letter grade (we will specify more details about grading in each of the assignments). The expectations for each individual critique will be detailed in the tutorials. As your skills at analyzing and reading technical papers improve throughout the semester, we will expect your critiques to reflect that.

Read Book section 4.4: “Case Study: The Internet Domain Name System (DNS)”.

As you read, think about the following:

  • What is the benefit of a recursive query?
  • What are the benefits of DNS’s hierarchical design?
  • Are there any drawbacks to DNS’s design?

Questions for Recitation

Before you come to this recitation, write up (on paper) a brief answer to the following (really—we don’t need more than a sentence or so for each question):

  • What is the purpose of DNS?
  • How does it work?
  • Why was it designed to work that way?

As always, there are multiple correct answers for each of these questions.

  1. Previous Lecture/Introduction
    • Complexity limits what we can build.
    • Enforced modularity mitigates complexity.
    • Modularity requires names (how else will modules communicate?).
  2. Naming in General
    • Examples of names: mit.edu, schedule.shtml, 617–253–0000, etc.
    • Systems manipulate/pass objects either by value or by name.
    • Benefits of using names:
      • Retrieval
      • Sharing
      • User-friendliness
      • Addressing
      • Hiding (+access control)
      • Indirection
    • We can get certain functionality in our systems by the way we pick our names.
    • Design of the naming scheme should reflect the properties we want in the system as a whole.
  3. Abstract View of Naming Schemes
    • Three components: Namespace, set of values, look-up algorithm to translate.
    • Lots of questions to ask:
      • What is the syntax of the names?
      • Is there any internal structure to the names?
      • Is the name space global (context-free) or local?
      • What are the values?
      • Does every name have a value (or can you have “dangling” names)?
      • What part of the system has the authority to bind a name to a value?
      • Can a single name have multiple values?
      • Does every value have a name (i.e., can you name everything)?
      • Can a single value have multiple names (i.e., are there synonyms)?
      • Can the value corresponding to a name change over time?
      • What context is used to resolve the names? What part of the system specifies it?
      • Where does resolution happen (“who does it”)?
    • Designing a naming system means balancing engineering tradeoffs.
      • Example tradeoffs: Distribution, scalability, delegation.
  4. Naming on the Internet: DNS
    • Maps hostnames to IP addresses. Necessarily because routers can only operate on IP addresses, not hostnames.
    • Provides:
      • User-friendliness
      • Load balancing (single name -> multiple values)
      • Single value -> multiple names
      • Mappings can change over time
    • Look-up algorithm
      • Bad design 1: hosts.txt. One file on every machine. Hard to keep files updated.
      • Bad design 2: One powerful machine with one big table. That machine is hit with a ton of requests.
      • DNS’ algorithm: Divide names into hierarchy, each zone contains its own mappings. Send request to root, which delegates down the tree.
        • Zones have authority over their own names.
    • Enhancements
      • 1 zone can = more than 1 physical name server (MIT has 3, root server has hundreds distributed globally).
      • Initial DNS request can go to any server, not just root.
      • Many name servers support recursive queries.
      • Name servers and clients can cache.
      • Those three combined result in the performance improvement.
    • Design questions (will be discussion in recitation)
      • DNS has a hierarchical design. Why? What’s good about that?
      • Is it simple?
      • Does it scale? In what senses?
      • Is it fault tolerant?
      • Are there any lingering policy issues that are unsatisfying?
      • Are there aspects of the design that *don’t* perform well?
      • Is it secure?
      • Was it a successful design?
  1. Previously
    • Modularity reduces complexity.
    • Naming is necessary for modularity.
  2. Operating Systems
    • Job: Enforce modularity on a single machine.
      • Also: Multiplexing, isolation, cooperation, portability, performance, …
    • To enforce modularity on a single machine, need to:
      • Protect programs’ memory from each other.
      • Allow programs to communicate.
      • Allow programs to share a single CPU.
    • Virtualization is how we do that.
    • Today: Virtualize memory. Assume one CPU per program and that programs don’t need to communicate.
  3. Virtual Memory
    • Two components: Main memory, CPU.
    • CPU holds instruction pointer (EIP).
    • Naive method: Two programs can just point to each other’s memory (bad).
    • Another method: Force programs to only use particular blocks of memory by having them address only part of the space. Complicated.
    • Virtual memory addressing: Let each program address the full 32-bit space. MMU translates virtual to physical addresses.
  4. Page Tables
    • Idea 1: Store physical addresses, use virtual addresses as an index into that table.
    • Problem: Table is too big.
    • Solution: Virtual address = page number + offset. MMU maps virtual page numbers to physical page numbers. Keeps offset the same.
    • Page table entries contain other stuff. Among that stuff:
      • Present bit
        • This bit lets us know if a page resides in RAM or storage. That’s how the OS deals with not actually having 2^32* (number of programs) physical addresses in RAM: Pages can live on disk when necessary.
      • R/W bit
      • U/S bit
      • These bits let the OS know when to trigger page faults.
  5. Hierarchical Page Tables
    • “Normal” page tables (described above) still use a lot of space.
    • Page tables have to be allocated all at once or not at all.
    • Hierarchical page tables solve this by creating a hierarchy of page tables and allocating each table only when it’s needed.
      • Virtual addresses get divided into multiple parts, one part per level in the hierarchy + an offset.
    • Downside? Speed. Multiple lookups instead of one. More page faults.
  6. Kernel
    • Virtualized memory doesn’t protect the page table.
    • Kernel mode vs. user mode does this.
    • Switch between user and kernel modes via interrupts.
  7. Abstraction
    • Some things can’t be virtualized (disk, network, …).
    • OS abstractions (system calls) make these things portable.
    • System calls are implemented as interrupts.
  8. Virtual Memory as Naming
    • Virtual memory is just a naming scheme.
    • Gives us hiding, controlled sharing, indirection.

Next lectures: Get rid of our initial assumptions (one CPU per program, etc.).

Read “The UNIX Time-Sharing System (PDF)” by Dennis Ritchie and Ken Thompson. Recitation 4 will focus on the first four sections of the paper; Recitation 5 will focus on the rest.

To help you as you read:

  • By the end of section three, you should understand the differences between ordinary files, directories, and special files.
  • By the end of section four (along with section three), you should be able to explain what happens when a user opens a file. For instance, if a user opens /home/example.txt, what does the UNIX file system do in order to find the file’s contents? You should understand this in detail (e.g., at the i-node level). 

As you read, you may also find it helpful to think about the following:

  • What things in UNIX are named?
  • How does naming in UNIX compare to naming in DNS? How do layering and hierarchy apply (if at all)? 

Questions for Recitation

Before you come to this recitation, write up (on paper) a brief answer to the following (really—we don’t need more than a sentence or so for each question):

  • What is UNIX?
  • How is its filesystem designed?
  • Why was it designed to work that way?

As always, there are multiple correct answers for each of these questions.

Course Info

Instructor
Departments
As Taught In
Spring 2018
Level
Undergraduate
Topics
Learning Resource Types
Lecture Notes
Written Assignments
Projects with Examples
Instructor Insights
Download Course
MIT Open Learning
Over 2,500 courses & materials
Freely sharing knowledge with learners and educators around the world. Learn more
© 2001–2024 Massachusetts Institute of Technology
Accessibility
Creative Commons License
Terms and Conditions
Proud member of:
© 2001–2024 Massachusetts Institute of Technology