1. OPERATING SYSTEMS DESIGN AND IMPLEMENTATION Third Edition ANDREW S
OPERATING SYSTEMS DESIGN AND IMPLEMENTATION Third Edition ANDREW S. TANENBAUM ALBERT S. WOODHULL Chapter 5 File Systems
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

2. Storing/Retrieving Information
Essential requirements for long-term information storage:
It must be possible to store a very large amount of information.
The information must survive the termination of the process using it.
Multiple processes must be able to access the information concurrently.
So, we store stuff in files
Files are persistent
They are organised into a File System
The user perspective is: what’s a file, how’s it named, permissions
The File System designer is concerned with the internals.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

3. Figure 5-1. Some typical file extensions.
File Naming
Files are an abstraction!
What are the differences in naming between UNIX, DOS & Window?
Some OS’s enforce an extension. This can be useful, e.g. Windows.
UNIX is fairly open in that regard.
Figure 5-1. Some typical file extensions.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

4. Figure 5-2. Three kinds of files.
File Structure (1)
Figure 5-2. Three kinds of files.
(a) Byte sequence.
(b) Record sequence
The first is just an unstructured sequence of bytes. Any meaning is put there by the program operating on the file.
The second shows bytes organised into records. Operations are on records, not on bytes, e.g. old card-based systems used 80 byte records because lines were 80 bytes long.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

5. Figure 5-2. Three kinds of files. … (c) Tree.
File Structure (2)
The classic tree structure: tree is sorted on some key.
Used by mainframes.
Figure 5-2. Three kinds of files. … (c) Tree.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

6. Figure 5-3. (a) An executable file. …
File Types (1)
Figure 5-3. (a) An executable file. …
Regular files contain user data: ASCII or binary
Directories contain files and directories.
UNIX also has character special (raw) and block special files (disks).
Here is a sequence of bytes that happen to be binary to make an executable.
The magic number identifies the file type, in this case, executable.
BSS = block started by symbol. Contains static local variables
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

7. Figure 5-3. … (b) An archive.
File Types (2)
Figure … (b) An archive.
An archive is another form of binary file: a collection of library procedures (ar)
$ cd /usr/lib
$ ar –t libgcc.a
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

8. Figure 5-4. Some possible file attributes.
Keyword here is “possible”. Not all file systems have all of these attributes for files. But all of them will have some of these attributes.
. . .
Figure 5-4. Some possible file attributes.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

9. Figure 5-4. Some possible file attributes.
. . .
Figure 5-4. Some possible file attributes.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

10. File Operations Append Create Seek Delete Get attributes Open
Close
Read
Write
Append
Seek
Get attributes
Set Attributes
Rename
Lock
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

11. Directories Figure 5-5. (a) Attributes in the directory entry.
A directory is a folder.
First example puts all the information in a directory structure.
The second example only puts the name there, with points to other structures for all the details.
Regardless, access to a file gets the info from the directory and puts it into a system data structure from which operations commence (the file table)
Figure 5-5. (a) Attributes in the directory entry.
(b) Attributes elsewhere.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

12. Hierarchical Directory Systems
Here we see the FQDN approach to file names so that users can have files with the same names, as long as they are in different subdirectories. And this requires hierarchical file systems.
Interesting comment about digital cameras going from (a) to (b) but most users wouldn’t know what to do with directories on their cameras.
Figure 5-6. Three file system designs. (a) Single directory shared
by all users. (b) One directory per user. (c) Arbitrary tree per
user. The letters indicate the directory or file’s owner.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

13. Figure 5-7. A UNIX directory tree.
Path Names
Absolute path names start with /
Relative path names start anywhere and are relevant to some current working directory.
Each directory these days also tends to have a ‘.’ (dot) and “..” (dot dot) that refer to the current directory and the parent directory, respectively.
Figure 5-7. A UNIX directory tree.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

14. Directory Operations Create Delete Opendir Closedir Readir Rename Link
Unlink
These examples are for UNIX only. Directory ops will vary widely between systems.
Links can be hard and soft. A hard link increments the inode counter. A soft link doesn’t.
The unlink command just removes a file’s entry in the table. When the inode count goes to zero, it’s actually deleted (because it could have more than one entry from being linked multiple times).
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

15. Figure 5-8. A possible file system layout.
BIOS executes the code in the Master Boot Record (MBR)
It looks in the partition table to find the active partition, and runs the code in the boot block. The boot block runs the OS on that partition.
Each partition has its own independent file system. This is how we can have multiple OS on the same disk.
Different systems will have different names for these things but they’re all the same. And different systems will organise the partitions in different ways.
Figure 5-8. A possible file system layout.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

16. Linked List Allocation
First consider contiguous allocation: location and #blocks are all you need. Reading is fast. But it leads to a lot of holes, keeping track of them, knowing file size in advance, etc. Kinda like modern day CD-R’s.
Linked list of blocks has advantages: every disk block can be used, no fragmentation, sequential access is easy - follow the links
And disadvantages: random access means having to run through the links, Loss of data in blocks to hold the pointer to the next block. That also means the data is no longer a power of 2: have to concatenate blocks together to get a power of 2 amount of data. Internal fragmentation in the last block.
Figure 5-9. Storing a file as a linked list of disk blocks.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

17. Linked List Allocation Using a Table in Memory
Figure Linked
list allocation using a
file allocation table in
main memory.
Can eliminate those disadvantages by keeping pointers to blocks in memory
This is a File Allocation Table (FAT)
Advantages:
the entire block is available for data (the pointer is in the FAT, not the block)
Random access becomes much easier (still have to walk the list, but the list is in memory and pretty fast)
Disadvantages:
- the table must be in memory. The whole thing! E.g. 2GB flash disk with 1K block size means 2M that’s 8MB FAT.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

18. Figure 5-11. An i-node with three levels of indirect blocks.
I-nodes
I-node = index node. A directory entry is just name & I-node.
Advantages:
only the inodes for open files need to be kept in memory. It’s not dependent on disk size but on the number of files.
File attributes can also be stored in the I-node
Disadvantage:
-each one has room for a fixed number of disk addresses, so when the file grows, you need to reserve the last one to point to an indirect block (or double or triple indirect blocks)
Figure An i-node with three levels of indirect blocks.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

19. Figure 5-12. File system containing a shared file.
Shared Files
Directory entries can point to a shared I-node
The i-node has a field that counts the number of (hard) links
Problem is that an i-node is a file system entity. One cannot hard link across file systems.
The answer is a soft link (shortcut for Windows, alias for Mac OS)
But a soft link can become orphaned
Figure File system containing a shared file.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

20. Directories in Windows 98 (1)
32 bits (instead of 16) to point to starting block, so 2^32 blocks
Still an 8 byte + 3 byte file name + extension
To get longer filenames, had to use another type of entry
Figure A Windows 98 base directory entry.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

21. Directories in Windows 98 (2)
The system still creates a short name, but now multiple long filename entries can make a longer name.
Such entries appear before the real directory entry (with the shortened name)
The Attributes field holds an invalid value, so older Windows systems just ignore the entry, and use the automatic short name.
Such shenanigans are required to provide backward compatibility.
Figure An entry for (part of) a long file name in Windows 98.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

22. Figure 5-15. A Version 7 UNIX directory entry.
Directories in UNIX (1)
The UNIX approach is much more simple.
Each directory entry just has a name and an I-node number
But there is a 14 byte limit for the filename! To get longer filenames, the directory entries must be longer.
Figure A Version 7 UNIX directory entry.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

23. Figure 5-16. The steps in looking up /usr/ast/mbox.
Directories in UNIX (2)
Locate the root directory: the first entry in the superblock
Look for the first component of the path, e.g. usr, i-node 6 in block 132
Then look up the next component in that directory’s i-node
And so on, until you get to the file part, and get to its i-node
This works for relative pathnames, including those with “.” and “..”
Figure The steps in looking up /usr/ast/mbox.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

24. Block Size
how to store files: sequence of bytes or collection of blocks (like memory's pure segmentation vs. paging)
copying growing files around on the disk is slow, so blocks are the answer
Some research indicates that the mean file size is 2K.
Data rate is better for big files.
Disk space efficiency is better for small files.
So, the compromise is somewhere in the middle - around 4K.
UNIX chose 1K. MS-DOS is based on disk size, but limited to 2^16 blocks, so large blocks on larger disks.
Figure The solid curve (left-hand scale) gives the data rate of a disk. The dashed curve (right-hand scale) gives the disk space efficiency. All files are 2 KB.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

25. Keeping Track of Free Blocks
Two ways to keep track of free blocks.
Use disk blocks! Each disk block can hold a list of free blocks, and point to the next free disk block block
The bitmap uses one bit per block, so it’s size is dependent on the number of blocks in the file system. N blocks requires N bits. These bits are stored in free blocks.
Example: 1KB block size, 32-bit (4 byte) block number. Each block can identify 255 free blocks (and a pointer to the next block of free blocks)
256GB disk has 2^38/2^10 blocks, requiring 2^28/2^8=2^20 blocks to keep track of them all.
The same disk would only need 2^28 bits, or 2^25 bytes, and then 2^25/2^10=2^15 blocks to hold those bits
Figure (a) Storing the free list on a linked list. (b) A bitmap.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

26. File System Reliability
Potential problems solved by backups:
Recover from disaster.
Recover from stupidity.
Backups to tape are the cheapest. Pennies per gigabyte.
Backups to CD, DVD, flash RAM and hard disks are easier but more $$$
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

27. Backup Issues Backup all or part of the system?
Don’t backup file if not changed
Compression of backup or not?
Difficulty of backup while file system active
Physical security of backup media
For UNIX systems, what parts of what file systems should be backed up?
Incremental backups - only backup what has actually changed since the last backup
Compress beforehand takes time and saves space. But if the backup file is corrupted in any way, the entire contents may not be retrievable
How to backup files that are in use? Snapshots - activities to the file are stored for later use, so that a snapshot is available for backup.
Lock them up. Better yet, store backups off site!
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

28. File System Consistency
Many file systems read blocks and modify them in memory, but write them out later. This can lead to file inconsistency, especially if the modified block is an i-node, directory block or free list block.
File system utilities deal with this, e.g. fsck (UNIX), chkdsk/scandsk (MS-DOS/Windows)
No problems
Block 2 is missing. Just add it to the free list
Block 4 occurs twice in free list. Rebuild the free list.
Block 5 is duplicated. Allocate a free block, make a copy.
Figure File system states. (a) Consistent. (b) Missing block.
(c) Duplicate block in free list. (d) Duplicate data block.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

29. Figure 5-20. The buffer cache data structures.
Caching
Reading from a disk can be a million times slower than reading from memory.
Hash the device and disk address for blocks in the cache. Blocks with the same hash value are in a linked list for easier search.
Blocks come and go in the buffer cache, using an algorithm like FIFO, 2nd chance & LRU
Another (bi-directional) linking is kept so that all blocks are kept in LRU. But this causes a problem: the most heavily modified blocks will be i-node blocks, and so will be in memory, not written to disk, when there’s a crash!
UNIX uses sync to write all modified blocks to disk, and update (which loops calling sync)
Another solution (Windows) is to use write-through cache
Figure The buffer cache data structures.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

30. Reducing Disk Arm Motion
Figure (a) I-nodes placed at the start of the disk.
(b) Disk divided into cylinder groups, each
with its own blocks and i-nodes.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

31. The Security Environment
Confidentiality: secret data has to stay secret, control who can view it
Integrity: no changes (deletion, additions, etc.) without owner’s permission
Availability: this is really tough to deal with because the activity can appear “normal”, just a lot of it.
Figure Security goals and threats.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

32. Categories of Intruders
Casual prying by nontechnical users.
Snooping by insiders.
Determined attempts to make money.
Commercial or military espionage.
Passive intruders just want to read (voyeurs)
Active intruders cause real problems.
Malware:
Virus replicates itself, attaching itself to something like
DOS (denial of service) consumes resources so nothing else can happen
DDOS (distributed DOS) thousands of viruses activate at the same time
key logger records typed keys, looking for username/password pairs
Worm similar to virus, but free standing
Trojan horse masquerades as a valid function, but does something else
logic bomb is lodged by an insider in a software provider
Spyware: cookie counting and sending info back to someone
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

33. Accidental Data Loss Acts of God Hardware or software errors
Human errors
Earthquake, fire, flood, tidal wave, alien invasion, war of the worlds
Hardware, network, software, media
Humans almost always screw things up.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

34. Generic Security Attacks (1)
Request memory pages, disk space, or tapes and just read them.
Try illegal system calls, or legal system calls with illegal parameters, or even legal system calls with legal but unreasonable parameters.
Start logging in and then hit DEL, RUBOUT or BREAK halfway through the login sequence.
Try modifying complex operating system structures kept in user space (if any).
Best way to identify security gaps is to try and break into the system!
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

35. Generic Security Attacks (2)
Spoof the user by writing a program that types ‘‘login:’’ on the screen and go away.
Look for manuals that say ‘‘Do not do X.’’ Try as many variations of X as possible.
Convince a system programmer to change the system to skip certain vital security checks for any user with your login name.
All else failing, the penetrator might find the computer center director’s secretary and offer a large bribe.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

36. Design Principles for Security
The system design should be public.
The default should be no access.
Check for current authority.
Give each process the least privilege possible.
The protection mechanism should be simple, uniform, and built into the lowest layers of the system.
The scheme chosen must be psychologically acceptable.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

37. Physical Identification
User authentication: passwords
Card + password (or PIN)
Fingerprint, voiceprint, retina scan, signature
You’re in analysis, and blood sampling: not very user friendly
Figure A device for measuring finger length.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

38. Figure 5-24. Three protection domains.
Moving on to Protection mechanisms. This is where a reference monitor acts.
Control how processes access objects, and also the operations on that object.
A domain is a set of (object, rights) pairs.
A domain could apply to a user, or a group of users.
Note that an object can belong to multiple domains, each with different rights.
In UNIX, a domain is defined by UID and GID.
Also, a UNIX process has two parts: user and kernel (different domains)
SETUID or SETGID bits give processes a new effective UID/GID domain
Figure Three protection domains.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

39. Figure 5-25. A protection matrix.
Protection Domains (2)
Visualising keeping track of all of this:
These are the same domains in the previous slide
Figure A protection matrix.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

40. Figure 5-26. A protection matrix with domains as objects.
Protection Domains (3)
A domain itself is an object, too. This is how one can switch domains.
This shows a SETUID example where a domain 1 process can switch to domain 2, but not back again.
Note how large this matrix would be for all files, and how sparse it would be. We’d want to store only the non-empty bits, and either by row or by column.
Figure A protection matrix with domains as objects.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

41. Access Control Lists (1)
Let’s start by column: associate an object with who can do something to it
In this case, each user is a domain, and the ACLs apply to all processes belonging to some user.
ACLs can also be organized along group lines.
Note there’s a typo in ACL for F1. User B ought to be R instead of A.
Figure Use of access control lists to manage file access.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

42. Access Control Lists (2)
This shows the involvement of groups. Tana may have to choose which group she belongs to in order to access a particular file at a particular time.
In this case, she has to be logged in as sysadm to access the Password file, or as a member of group pigfan to access the Pigeon_data.
You can get around this with wildcards, but then control is less tight.
Note that ACLs are time sensitive: things could change after someone accesses a file, and a user process gets the rights of the ACL at the time of the 1st access.
Figure Two access control lists.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

43. Capabilities (1)
A Capability list (C-list) slices the matrix by rows (instead of columns), and so is organized by user (domain).
This is just another visualization of the original matrix.
Obviously, C-lists must be protected
tagged architecture, capabilities are tagged for kernel only modification
keep the C-list inside the OS itself, access by capability
Keep the C-list in user space, but encrypt them.
Figure When capabilities are used, each process has a capability list.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

44. Figure 5-30. A cryptographically-protected capability.
Capabilities (2)
For example, a client sends a request to a remote server for some object.
The server generates some check field and stores it locally, but returns a capability back to the client.
The last field is run through a one-way function
The client must use the capability to access the file on the remote server.
Figure A cryptographically-protected capability.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

45. Examples of Generic Rights
Copy capability: create a new capability for the same object.
Copy object: create a duplicate object with a new capability.
Remove capability: delete an entry from the C-list; object unaffected.
Destroy object: permanently remove an object and a capability.
These are generic rights other than the standard Read, Write and eXecute on objects.
They apply to either objects or capabilities.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

46. Covert Channels (1)
Book example: the clients have their tax forms filled out by the server. The clients are worried the server will sell their earnings figures to someone, and the server is worried that the clients will try to steal the tax programme. No one trusts anyone, but they need each other.
The collaborator is actually helping the server to steal the client’s information!
Lampson’s (1973) goal is to define a system where the collaborator cannot do this. This is the confinement problem.
We can control the files and IPC so they cannot communicate through customary channels. But they can use covert channels, such as chomping processor time (long to communicate a 1, short to communicate a 0)
Could modulate other machine characteristics: paging, any resource consumption,
Figure (a) The client, server, and collaborator
processes. (b) The encapsulated server can still leak
to the collaborator via covert channels.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

47. Figure 5-32. A covert channel using file locking.
Covert Channels (2)
or file locking (even a file the collaborator cannot access)
Here the server sends a bitstream code to the collaborator
They could could use other files to implement an ACK system
Figure A covert channel using file locking.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

48. MINIX 3 File System (1)
. . .
Figure File system messages. File name parameters are always pointers to the name. The code status as reply value means OK or ERROR.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

49. MINIX 3 File System (2)
. . .
. . .
Figure File system messages. File name parameters are always pointers to the name. The code status as reply value means OK or ERROR.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

50. MINIX 3 File System (3)
. . .
Figure File system messages. File name parameters are always pointers to the name. The code status as reply value means OK or ERROR.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

51. File System Layout (1)
Figure Disk layout for a floppy disk or small hard disk partition, with 64 i-nodes and a 1-KB block size (i.e., two consecutive 512-byte sectors are treated as a single block).
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

52. Figure 5-35. The MINIX 3 superblock.
File System Layout (2)
Figure The MINIX 3 superblock.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

53. Figure 5-36. The MINIX i-node.
I-Nodes
Figure The MINIX i-node.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

54. Figure 5-37. The linked lists used by the block cache.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

55. Directories and Paths
Figure (a) Root file system. (b) An unmounted file system. (c) The result of mounting the file system of (b) on /usr/.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

56. File Descriptors
Figure How file positions are shared between a parent and a child.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

57. Figure 5-40. Procedures used for block management.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

58. Figure 5-41. Procedures used for i-node management.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

59. Superblock Management
Figure Procedures used to manage the superblock and bitmaps.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

60. File Locking Figure 5-43. The POSIX advisory record locking
operations. These operations are requested
by using an FCNTL system call.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

61. Initialization of the File System (1)
Figure Block cache initialization.
(a) Before any buffers have been used.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

62. Initialization of the File System (2)
Figure Block cache initialization.
(b) After one block has been requested.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

63. Initialization of the File System (3)
Figure Block cache initialization.
(c) After the block has been released.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

64. Reading a File (1)
Figure Three examples of how the first chunk size is determined for a 10-byte file. The block size is 8 bytes, and the number of bytes requested is 6. The chunk is shown shaded.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

65. Reading a File (2)
Figure Some of the procedures involved in reading a file.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

66. Writing a File
Figure (a) – (f) The successive allocation of 1-KB blocks with a 2-KB zone.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

67. Converting a Path to an I-Node
Figure Some of the procedures used in looking up path names.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

68. Mounting File Systems Possible file system mounting errors:
The special file given is not a block device.
The special file is a block device but is already mounted.
The file system to be mounted has a rotten magic number.
The file system to be mounted is invalid (e.g., no i-nodes).
The file to be mounted on does not exist or is a special file.
There is no room for the mounted file system’s bitmaps.
There is no room for the mounted file system’s superblock.
There is no room for the mounted file system’s root i-node.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

69. Linking and Unlinking Files
Possible errors in a linking or unlinking call:
File_name does not exist or cannot be accessed.
File_name already has the maximum number of links.
File_name is a directory (only superuser can link to it).
Link_name already exists.
File_name and link "name are on different devices.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved

70. Additional System Call Support
Figure The POSIX request parameters for the FCNTL system call.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved