MINIX File System

" Process FS, running in user mode " Main loop which
" Waits for a message " Extracts and uses msg type as index into table with procedure pointers (handlers) " Procedure does the work and returns a status value, which is send back as the reply

" Main Data structures:

" Super-block table " Open File Table " File Position Table " Bit map for free i-nodes and free zones " Block Cache
1

MINIX FS Messages

1!

Directories and Paths

" Consist of files 16-byte entries.
" First two bytes form a 16-bit I-node number " Remaining 14 bytes are the file name

" File name lookup is done one entry at a time. " When a new file is created, a new i-node is allocated (alloc_node) and its name is written into the directory entry

i-node-nr! 2 bytes!

File name! 14 bytes!

3

File Descriptors
" File descriptor is an index in a filp (file position) table. " Filp table contains file position and I-node pointer of the file, the file mode, and the count of processes using it. " Filp is a shared table that allows for:
" sharing files without sharing file positions " sharing files and share file positions (e.g. between parent and a child)
Process P1: fd=open() Process P2: fd=open()
Pos = file position inp = i-node pointer

Table lp!
Pos/inp Pos/inp Pos/inp Pos/inp Pos/inp Pos/inp pos1! pos2!

OpenFileTable!

i-n1 i-n2 i-n3 i-n4

4

2!

Zones vs. blocks

" In Minix, file space is allocated per zones " Zones are collections of consecutive blocks on the disk. (2, 4, 8) " Zone size/block size is always a power of two.

Minix File System 5

FS Layout
" Same structure for any block device. " Uses i-nodes and zones (allocation unit composed of 2n blocks) " Uses bit-maps to keep track of used/free i-nodes and zones (bit maps are not normal blocks)

" To find the zone of a block, do a n-bit shift-right of the block number.
" n=3, Each zone has 8 Blocks. And block #128 is in zone #16

" Utility program mkfs formats disk, and includes magic number in super-block (valid Minix FS)

3!

Super-Block on Disk and in Main Memory

" Contains the layout of the file system:
" number of nodes " number of zones " number of I-node bit map blocks " number of zone bit map blocks " first data zone " log2 (zone/block) " maximum file size " magic number " padding
Minix File System 7

FS Mounting
A mouting is a glue between the mounted-on i-node, and the inode of the root directory of the mounted file system. Example: mount t devtype device mounted-on-dir The i-node of the mounted-on directory has the mount-flag set. At the path resolution, this means: continue search in the mounted FS

4!

Minix FS
" When a device is mounted, its super-block is copied into a super-block table in memory, including several information: " if FS is read-only " device from which the super-block came " pointers to the first free i-nodes/zones in the bit maps " etc

Minix Path Resolution

" The in-memory super-block of a device has 2 pointers which serves to connect the file systems:
" i-node of the root of the mounted-FS " i-node of the mounted-on-FS (e.g. /usr)

" When path resolution reaches /usr, it searches all the super-block table for the i-node pointer, and gets the pointer to the mounted-FS
i-node of the mounted-on-FS!

Super-block table!

Root i-node of the mounted FS!

/usr!

/!

10

5!

Minix i-node
" File Type (regular, directory, special, pipe, etc.) and protection bits " 9 zone pointers (7 direct, 2 indirect), each 32 bits " Status change time updated at every file operation " When a file is opened, the inode is copied to memory into a i-node table " If an open file is re-opened, a used-counter is incremented (only if counter=0) i-node is removed from table
11

Minix FS
" When a new file is created, uses the first-free-bit pointers in the super-block to allocate a new inode and one or more new zones " When a file is deleted, FS:
" locates the corresponding bits in the i-node and zone bit maps and sets them to 0 " updates the first-free-bit pointers in the super-block table entry for the device

" All blocks within a newly allocated zone are initialized (zeroed), to avaiod problem of seek +write beyond the original size of the file

Seek+write!
12

6!

Reading/Writing Files
All in files read.c and write.c: read_write is the common procedure, which calls: " rw_chunk to obtain the block address, and request the copy of it to the user space, which calls: " read_map/write_map to convert the logical position within a file to the block number (write_map) may also insert new zone numbers into the i-node or index blocks " rd_indir/wr_indir to obtain the target block address when indirect (simple/double) indexing is used " get_block checks if the required block is in the cache, if yes, gets the pointer to it. If not, then: " rw_block copies data to/from a block to memory, and calls lower-layer procedures: dev_io, rw_dev, sendrec " sys_copy transfers data from the File Server to the user process
13

Allocating new blocks

" rw_chunk is called whenever a new block is required, and procedure new_block allocates the

zones:
Exampls: Free zones are: 12, 20, 31, 36 (Blocks: 24/25, 40/41, etc.)
24! 24! 25! 24! 25! 40! 24! 25! 40! 41! 24! 25! 40! 41! 62! Fig: Successive allocation of blocks of 1 KB and Zones of 2KB!
14

7!

Minix Block Cache

" Is an array of buffers with a header containing pointers, counters, flags " Entries are chained together in a double-linked list from most-recently-used to least-recently-used " A Hash table points to a single-linked list of blocks whose number has the same n low-order bits (i.e. blocks on a same device are on the same list) " To find a block, FS calls get_block, which gets the hash entry and searches in the list. If found (cache hit), use counter is incremented and a pointer to the block is returned. " If a block is not found on the hash list, the first buffer on the LRU list is chosen for removal, and if modified its contents is copied back to disk
15

Minix Block Cache

16

8!

Minix Block Cache

" After the block use, procedure put_block is called to free the buffer space " It decrements the use_counter, indicating a lower probability of block re-use. If counter is 0 puts block back to LRU list; " Depending on the type of block (index, directory, data) being freed, decides:
" put block at front of end of LRU list? (if unlikely to be re-used, at front) " keep block in cache or write it back to disk? (for blocks that have been modified)

" A modified block is kept in buffer until:

" it reaches front of LRU list, and is removed, or " a SYNCH system call is executed.
17

9!