Operating Systems 2020W Lecture 12

From Soma-notes
Jump to navigation Jump to search


Video from the lecture given on February 14, 2020 is now available.


Lecture 12

* Assignment 2 hints
  - Q3
  - Q1
  - Q2
  - Q4
  - Q6
  - Q14
  - Q17 walkthrough
* Assignment 1 solutions

You cannot decide between physical and logical sizes based on which is bigger.
 - because of coarse allocation (can only allocate in blocks), physical size can be bigger than logical size
 - but files can have holes, which means logical size is bigger than physical size

RAM means addreses (pointers), code + data (variables, etc) in a process
 - they go away when a process terminates

logical/physical size refers to properties of files (data stored persistently
on disk, referred to by a filename)
 - can figure out both based on info in the inode of a file
 - fstat/lstat tells you about inodes

a hole in a file is a range of null bytes (zeros) that aren't explicitly stored
in blocks on disk
 - instead, there is just a note that "byte range X-Y is all zeros"
 - why bother allocating blocks for zeros?
 - if you write to this part of the file, blocks will be allocated
   (allocation is thus lazy)

RAM is allocated with sbrk, anonymous mmaps, and malloc
disk space is allocated with file operations (open, read, write, close, seek)
 - mmap can be used to map disk files into ram, but the size of the file
   is then fixed

Midterm is on Assignment 1 and 2

du reports physical size of files

"one trillion zeros"  <--- how many bytes does this consume?

note all files have to take up some space
 - for their inode
 - so "holes" can be stored in an inode sometimes, depending
   on the design of the filesystem, or maybe just using one data block

How do you get files to show up in lost+found?
 - you lose a directory
   - no directory means no names for files
   - but if those inodes are still allocated, fsck will find them and say
     "hey, I have these allocated inodes but no filenames for them.
      I don't know where they belong so I should put them in lost+found"

 - ideally, make lots of directories and files
 - I suggest rsync -a /etc <your mountpoint>
    - will get you lots of files
    - make sure your mountpoint is writable (after mounting)
      (do it as root or change the ownership of the directory in the top of
       the filesystem to be your current user)
 - then study the structure of the filesystem using dumpe2fs
   - find out the group number based on inode
   - find inode table blocks for that group