* Where is the "elevator algorithm" typically used?

In magnetic media, there's a moving head, slow to move it into the right
track position.  So when N access requests come in, for data on different
tracks, the disk I/O scheduler will order the accesses from smallest to
largest, and then "sweep" the disk tracks, stopping along the way to
read/write data; when the head reaches the other side of the platter, you do
the same, but now you sort the next batch of accesses in reverse order, b/c
you're sweeping the disk in the other direction.

Applications' access to files and data evenrtually get translated into disk
sector or block reads.  Each such block has a number, called the Logical
Block Number (LBN).  Block-based media (HDDs also SSDs) have LBN numbers
starting from 0, 1, 2, ..., N (where N is the largest LBN).  The disk
capacity is usually N * block_size (block/sectore sizes are either 512B or
4KB).

This minimizes the slowest component of hard disks, called a "head seek",
which requires giving a jolt of power to the head's motor, to move it into
position, then another reverse jolt to slow it down, then position it exatly
above the track needed, and read/write the data.

Note: if the exact data block for the track is not positioned under the
head, you have to wait for the platter to make as much of a whole revolution
-- this is called a "rotational latency".  Once the head is on a track,
it'll read/write all the data that is on that track.  (Note: inner tracks
store less data than outer tracks, due to difference in diamaters.)

This alg operates just like a regular elevator: going from top to bottom
floors, and stopping along the way to pick up or drop off passengers.

This alg makes sense for rotational media.  For SSDs, completely different
algs are needed.

* Name at least three pieces of data that go into an inode?

Q: What's an "inode"?
A: data structure that contains the "metadata of a file"

Different file systems have differnet inode structures, storing m-d that's
relevant to that file system.  In memory, the OS has a different
representation of an inode, that is a combination of common fields and
per-f/s fields.

Q: What syscall can I use to get this m-d?
A: stat(2) or lstat(2), also user util stat(1)

What goes into an inode?
- file size in bytes + blocks
- number of links (hard linked files)
- access permissions
- owner, group
- timestamps: file creation, last modification, last access/read, others
- links or pointers to data blocks of the file's content
- type of object: regular file, directory, symlink, etc.

Q: Where's the name of the file?

A: A file's name could be considered "meta data", so why is it NOT in the
inode?  The names of files and directories are part of an overall
"namespace" of the file system, names are stored inside directories (an
inode of type "dir"), and a file can be hardlinked (has MULTIPLE names).

A inode of type dir has a regular inode, but its "content" is an array of
tuples that are <name,inode_num,flags>.
- name of the object in THIS directory only
- inode number to search for that object on the media
- flags (optional): can sometimes denote the type of inode that "name" is

* What resource does a process in "READY" (or "RUNNABLE") state waiting for?

Q: What is this READY/RUNNABLE state?
A: process scheduler

Process scheduler has multiple states that a process can be in:
- RUNNING: currently running on a CPU/core
- READY/RUNNABLE: ready to run on a CPU/core
- WAITING: waiting for ... I/O (slow)

CONTINUE NEXT TIME