Lecture #12

Administrivia

• midterm solution

• lab 2 discussion (?)

• lab 3 delayed

  • will publish as soon as practical
  • extension

• concurrency

  • if you are reading a shared variable, you must protect the read unless you can prove that no other thread/process will write to that variable
    • read may not be atomic, someone else may write while you're reading
  • if you are writing to a shared variable, you must protect the write unless you can prove that no other thread/process will write or read that variable
    • read and/or write may not be atomic

• race conditions are hard to test for because they usually happen rarely (usually, long after the system has gone into production)

  • need analytic tools
  • neeed careful inspection
  • need another pair of eyes

• cannot prove the absence of race/deadlock conditions in general because you need to reason about all possible execution paths

  • may be able to show presence of deadlock risk in restricted cases
  • may be able to prove "no deadlock here" (restricted case)
    • see deadlock conditions

• message passing: easier to reason about

  • study Erlang

Previously on CSS503A...

• userland vs. kernel

  • system calls from userland process to request kernel services

• concurrency: processes & threads

• filesystems: abstraction/data structure on top of mass storage devices

• filesystem API: uniform interface

  • regular files
  • devices

Filesystem Layers

• application
  • open/close/read/write/lseek/...
• logical filesystem
  • filename --> file#/file handle/protection
• file organization
  • inode (file control blck)
  • NTFS: master file table entry
• basic filesystem
  • block# --> platter/cylinder/track
  • buffer/cache
• I/O control
  • device access
• device
  • electronic signals

Filesystem Implementation

• disk data structure

  • boot sector
  • partition table
  • superblock
    • magic#
    • mount count/max mount count
      • determine when to run disk check utility
    • blocksize/blocks/group
    • #free blocks
    • #free inodes
    • 1st inode (mount point or / for root filesystem)

• loopback device

  • kernel driver
  • lets you mount a file as if it's a separate filesystem
  • do not confuse with networking loopback device

• File Control Block: aka inode

• multiple filesystem types

  • ISO 9660 (cd-rom/dvd)
  • ext2/ext3/ext4
  • NTFS
  • FAT16/FAT32
  • FUSE
    • userland filesystem ("File System in User Space")
    • virtual filesystem

• directory ("special file"): map name→inode#

  • bit set in inode to identify as directory
  • used to be able to open/read/close
    • now requires separate set of system calls

• inode: data structure containing file metadata

  • size
  • timestamps
  • owner/group id
  • permission bits
  • #links
  • ptr(s) to data block(s)

• name is not an intrinsic property of a file (on Unix-like systems)

  • hard link: 2 filenames for single inode (file object)
  • symbolic (soft) link: directory entry that points to special inode entry that points to directory entry
    • name redirection
  • cannot do hard links to directories
    • otherwise, could lead to cycles in directory tree
    • early Unix: directory is file (read/write)
      • modern Linux systems: not so much
        • separate system calls to read directory

• need both inode# & device# to uniquely identify file

• superblock

  • where are the inodes?
  • free/allocated block list

Disk Allocation & Indexing

• memory allocation problem (like malloc/new)

• latency

  • disk rotation
  • read/write head seek

• clever placement can make orders of magnitude difference

• 2 basic strategies for disk block allocation

  • contiguous (array)
  • linked list (sequential)
  • or some combination of the above

• contiguous allocation

  • OS-360/VM/CMS
    • allocate "cylinders"
    • pros:
      • minimize disk seekage
    • cons:
      • requires pre-allocation (inflexible)
      • fragmentation
        • external fragmentation

• linked list allocation

  • pros
    • inode (File Control Block) only requires 1st block (smaller inode)
    • fragmentation is not an issue (or file is pre-fragmented)
  • cons
    • only suitable for sequential acces
    • link pointers reduce effective size of block
    • broken link --> unrecoverable data
      • e.g. write failure due to OS bug or H/W fault (really bad when either of these things happen)

• best of both worlds: allocation by large block (überblocks?)

  • as disk fragments, performance degrades
    • windows: deframentation utility (compaction)