CS469/569 - Linux and Unix Administration and Networking Spring 2022

Displaying ./code/04-05/README

h8
- questions?
- due tomorrow

h7, h8 - let me know to check things

q8
- due by midnight Thursday, over lessons 9-12

Attendance

Reading - lessons 13 (today) and 14 (Thursday)

q9
- lesson 13
- likely released before next class

h9 - lesson 14 (sql/apache)

Devices
- block versus character devices
- character devices
  - examples: keyboard, mouse,
  - properties: stream of input or output, nothing to "save"
  - operations: read/write a character
- block - page / sector / block, caching (OS and drive controller)
  - examples: drives
  - properties: you can seek to a particular spot, save/retrieve
  - operations: seek to a location (integer), read/write some blocks
                seek to position 100  # position on the device
		read 3 blocks         # transfer 3 blocks from device to memory
  - page/sector/block - smallest unit on the device, because efficiency (reduce the # of requests)
  - what the world looks like
    Device: SATA 1TB drive
      position:0123456789abcdef 0123456789abcdef ... 
      contents:0000000000000000 1111111111111111
	    
    storage controller: SATA controller on your MB, 50MB of cache
     cache: 50MB in 1KB units
      block #:    0                                    1                            2                           3         4
      contents:   drive0, block# 678                   drive0, block #679           drive0, block #680

    OS file system cache: in RAM

    C program memory: in RAM, char buffer[1000]; 

  - C program: fscanf("%99s", username);  # /usr/bin/ls
                ... read system call: ask the OS to read from this file /usr/bin/ls
		... file system stuff: /usr/bin/ls is at block 678 on drive0
		...   OS: check file system cache for blocks 678-680 for drive0 # cache lives in RAM
		...       if in RAM cache, then copy back to the program
		...   OS: seek to block 678 on drive 0, read 3 blocks -> to the SATA conroller
		... SATA controller: if blocks 678-680 on drive0 are in cache, send that back, otherwise read
		... SATA drive0:       send blocks if they weren't in cache

   - Why the multiple levels?
     security - any shared resource needs to go through the OS
     error correction - OS, drive, the controller can deal with errors, so programs don't have to
     why cache? - faster/efficiency, reading from drive is slower than reading from controller,
                  reading from controller is slower than reading from RAM
		  (speed - throughput speed, "seek" time / time to run one operation)
     abstraction - each level doesn't need to worry about things far beneath it


Virtual memory
- basic idea, why - security between processes, simplicity of memory model, limited memory
- basic idea, how - page tables, page fault, ...
- picture and more details -
  https://en.wikipedia.org/wiki/Virtual_memory
- Your C program -> compiled into assembly language
  Assembly language -> memory looks like an array from 0 to 1TB of bytes
                       let's call the memory array "memory"
                       memory[1000] = memory[1001] + 3; # one byte integer
		       memory[1000:1004] = memory[1004:1008] * 3; # four byte integer
		    -> memory[1000] does /not/ go straight to physical memory location 1000
		       why? security, RAM is a shared resource
		       how? OS keeps a "page table" mapping the virtual address (1000 here) to a
		            physical memory location
			    OS keeps a page table for every process, and makes sure all
			      processes are using separate physical memory
		       another benefit? abstraction - we don't need to worry about how much
		                        physical memory there is, or where my allocation is.
		       another benefit? we can more virtual memory than physical memory,
		                        using swap space for things that don't fit
- How does this actually work?
  CPU - needs to have instructions for setting page tables, needs to be
        designed for this
  Each process - needs to have its own virtual memory page table (kept by the OS)
  Context switch - changing which process is running - the page table will change
- Drawbacks?
  read memory[1001];
  -> where is address 1001 for this process
     -> look at page table for this process, at physical address 12345678
     read physical address 12345678
  Security?  Make sure other processes can't see our stuff.  CPU/OS/VM design.
  Efficiency - every time we access memory, we have to look at page tables?
               that might double running time
	       ... be smart, what can be done... -> use/design CPU cache for this
	           VM translations stored in the CPU cache, changed for a context switch