Outline

Minix File System Implementation: in-memory data structures

the file system process table (p. 925) includes the current and root directories, process IDs, an array of pointers to open files, and information that allows saving information for slow reads/writes (e.g. on a pipe or a terminal)
inodes on disk (p. 921 and p. 928) have up to 8 direct block pointer ("zones"), one indirect, one double-indirect -- total, 64 bytes
an inode block is read from disk whenever the file corresponding to at least one of the inodes is opened
the corresponding inode representation in memory (p. 928) has additional references to make it easy to locate the device and the device's superblock, whether the inode is dirty, whether the file is special in some way (pipe, mount, etc)
the superblock array (p. 930) stores information about each mounted file system, particularly the sizes of the inode and zone bitmaps. The in-memory copy of the structure also stores mount information, including the device and the byte-order
an open file structure (p. 927), pointed to by the open files in the process table, contains a pointer to the inode, the position being read or written, and a few other items. These structures may be shared, e.g. by a parent and a child after a fork.
the lock array (p. 928) contains information for each file lock set -- this is checked every time a lock is requested
the device array (p. 686) contains function pointers for opening, closing, and reading/writing data, and the number of the corresponding device task

a buffer may contain (p. 926) a data page, a directory page, an indirect block, an inode block, or a bitmap block
free buffers are kept in a hash table, to make it easy to locate them quickly. The hash table is indexed by the low bits of the block number
most free buffers are maintained in an LRU doubly-linked list, but some free buffers are placed at the head of the list because they are very unlikely to be needed again (e.g. superblock buffers)
when a new buffer is needed, it is taken from the head of the list
when reading a block from disk (or when writing part of a block), the hash table is searched to see if the block might be in the buffer -- if so, no need to access the disk
when writing a full block to disk, the block then goes to the head of the LRU list
most dirty buffers on the LRU list are only written back when:
- the block reaches the head of the list, or
- another block on the same device is written back
when writing any block to disk, Minix writes all blocks from that device, in sorted (elevator) order