1. Add worst fit and circular best fit. Hence there will be four curves on each graph.
2. Add the number of allocated blocks, and the size of the largest allocated block to the standard statistics. Hence there will be 12 graphs.
3. Add buddy system. Now allocations should be restricted to powers of two. Do not compare with the other four algorithms graphically, i.e. just produce the numerical output.
4. If done completely correctly 10 points extra credit will be given.
5. Don't even try this extra credit. I only added it on the request of a (presumably masochistic) student.

Notes on copyfile

• Normally in unix one wouldn't call read and write directly.
• Indeed, for copyfile, getchar() and putchar() would be nice since they take care of the buffering (standard I/O, stdio).
• Tanenbaum is correct that the error reporting is atrocious.
  The worst is exiting the loop on error and thus generating an exit(0) as if nothing happened.

4.1.7: Memory mapped files (not on 202 exams)

Conceptually simple and elegant. Associate a segment with each file and then normal memory operations take the place of I/O.

Thus copyfile does not have fgetc/fputc (or read/write). Instead it is just like memcopy

while ( (dest++)* = (src++)* );

The implementation is via demand paging (on top of segmentation) but the backing store for the pages is the file. This all sounds great but ...

1. How do you tell the length of a newly created file? You know which pages were written but not what words in those pages. So a file with one byte or 10, looks like a page.
2. What if same file is accessed by both I/O and memory mapping.
   
3. What if the file is bigger than the size of virtual memory (will not be a problem in 5 years on modern systems).

4.2: Directories

Unit of organization.

4.2.1: Hierarchical directory systems

Possibilities

• One directory in the system
• One per user
• One tree
• One tree per user
• One forest
• One forest per user

These are not as wildly different as they sound.

• If the system only has one directory, but allows the character / in a file name. Then one could fake a tree by having a file named
  /allan/gottlieb/courses/arch/class-notes.html
  rather than a directory allan, a subdirectory gottlieb, ..., a file class-notes.html.
• Dos (windows) is a forest, unix a tree. In dos there is no common parent of a:\ and c:\.
• But windows explorer makes the dos forest look quite a bit like a tree. Indeed, the gnome file manager, looks A LOT like windows explorer.
• You can get an effect similar to (but not the same as) one X per user by having just one X in the system and having permissions that permits each user to visit only a subset. Of course if the system doesn't have permissions, this is not possible
• Today's systems have a tree per system or a forest per system.

4.2.2: Path Names

• Absolute versus Relative file names.

• The former is starts at the (or a) root, the latter starts at the current (a.k.a working) directory.
• The special directories . and ..

Homework: 1, 8.

4.2.3: Directory operations

1. Create: Normally comes with . and ..
   
   
2. Delete: First empty the directory (except for . and ..)
   
   
3. Opendir: Same as with files (creates a ``handle'')
   
   
4. Closedir: Same as files
   
   
5. Readdir: In the old days (of unix) could read directories as files so there was no special readdir (or opendir/closedir). It was believed that the uniform treatment would make programming (or at least system understanding) as there was less to learn.

   However, experience has taught that this was not a good idea since the structure of directories then becomes exposed. Early unix had a simple structure (and there was only one). Modern systems have more sophisticated structures and more importantly they are not fixed across implementations.
   
   

6. Rename: As with files
   
   
7. Link: Add a second name for a file; discussed below.
   
   
8. Unlink: Remove a directory entry. This is how a file is deleted. But if there are many links, the file remains. Discussed in more detail below.

4.3: File System Implementation

4.3.1; Implementing Files

• A disk cannot read or write a single word. Instead it can read or write a sector, which is often 512 bytes.
• Disks are written in blocks whose size is a multiple of the sector size.
• For memory management we dealt with words (or bytes). Here we deal with blocks.

Contiguous allocation

• This is like OS/MVT.
• The entire file is stored as one piece
• Simple and fast for access, but ...
• Problem with growing files
  • Must either evict the file itself or the file it is bumping into.
  • Same problem with an OS/MVT kind of system if jobs grow.
• Problem with external fragmentation.
• Not used for general purpose systems. Ideal for systems where files do not change size.

Homework: 7.

Linked allocation

• The directory entry contains a pointer to the first block of the file.
• Each block contains a pointer to the next.
• Horrible for random access.
• Not used.

FAT (file allocation table)

• Used by dos / windows (but not windows/NT)
• Directory entry points to first block (i.e. specifies the block number)
• A FAT is maintained in memory having one (word) entry for each disk block. The entry for block N contains the block number of the next block in the same file as N.
• This is linked but the links are store separately.
• Still is linear in size of file but now all the entries are to this one table which is in memory. So it is bad but not horrible for random access.
• Size of table is one word per disk block. If one writes all blocks of size 4K and uses 4-byte words, the table is one megabyte for each disk gigabyte. Large but not prohibitive.
• If write blocks of size 512 bytes (the sector size of most disks) then the table is 8 megs per gig, which is prohibitive