OPERATING SYSTEMS ASSIGNMENT 4 FILE SYSTEM

Transcription

1 OPERATING SYSTEMS ASSIGNMENT 4 FILE SYSTEM Introduction The File system is an integral part of every operating system. The use of files enables the user to save persistent data. Files can also be used for process communication. A weakness of a file system is its low speed. Access time to the disk is far greater than access time to the main memory. Computations of the CPU that require I/O operations are postponed until the disk delivers the requested data. Many optimizations can be implemented at this layer in order to improve the overall system performance. In this task you will implement a few of them in the XV6 kernel. Xv6 implements the file system as a layered structure. Each layer depends on the layer beneath it and uses its services (functions) to implement its own services for the layer above it. Each layer is at a higher level than the level beneath it and produces a more abstract perspective of the file system. Each layer also has a specific purpose and its services are implemented so as to achieve this specific goal. Before continuing, you should extend your knowledge regarding the file system of xv6 by reading chapters 6, chapter 7 and chapter 8. Disk Driver The disk driver and the buffer cache together form the bottom layer of the file system. Data is presented on disk as 512-byte blocks called sectors. Xv6 uses struct buf to represent the content of a sector in a specific disk device. In addition to the sector data the struct also contains several flags: Valid (set true once the data from the disk is copied to the buf's data member), Dirty (set true once changes were made to the data that requires updating to the disk) and Busy (used for synchronization). The disk driver implements services that operate directly on data blocks of the disk. Relevant file: ide.c Buffer Cache Using the disk driver's services the buffer cache also has its responsibilities to contribute. The buffer cache has two purposes: The first is to speed up the operating system performance performing a read for the second time from some disk sector may save disk access. The buffer cache records data blocks from disk into main memory in order to make the I/O requests complete faster. Sectors are saved in a doubly-linked list in memory. When an I/O request is generated the doubly linked list is searched first. If the requested sector isn t found, the request is forwarded to the disk driver. The second purpose of the buffer cache is to synchronize accesses to disk sectors. You should have read more about this issue in chapters 6-8. Relevant file: bio.c

2 super-block The disk driver and the buffer cache form together the bottom layer of the file system. Together they provide an easy, efficient and synchronized access to disk blocks for the upper layers. XV6's File System On top of this bottom layer, the upper layers of XV6's file system are implemented. The upper layer is composed of four layers: Block Allocator, I-nodes, directories and path names. The Block Allocator is the lower layer and Path Name is the higher layer. Every layer implements its own functions which support the layer above it. For example, I- Nodes use the Block Allocator to handle disk blocks. XV6's file system layout is as follows: i-nodes Blocks bitmap Data Blocks Block Allocator Uses the buffer cache in order to manage disk blocks. Provides high-level access to disk blocks, relatively to the disk driver and to the buffer cache. It has two main functions: balloc and bfree. I-Nodes Unnamed file in the file system. Every i-node referrs to one file only which is composed of disk blocks. Each i-node contains several fields such as device number, i-node number, 12 direct blocks, indirect block, flags, etc. Directories A special kind of file: its type is T_DEV and its data is a sequence of directory entries. Each entry is a struct dirent, which contain a name and an i-node number. Path names Evaluating a given path such as x/y/file.am to the correct i-node of the file "file.am" that is located in directory 'y', where 'y' is located in directory 'x'. Directory name 'x' is

3 retrieved from the currently working directory. As the topmost layer, it uses the functions implemented by the directory layer. File System calls User programs that wish to use disk services have an api in the the form of file system calls. When a system call is generated it traverses through the different layers of the file system until reaching its target. For example, creating a new file and filling it with content requires passing through all layers until the disk driver is reached, which creates new blocks and writes fresh data to it. Relevant files: fs.h, fs.c, mkfs.c, file.h, file.c, sysfile.c Task 0: running xv6 As always, begin by downloading our revision of xv6, from the os112 svn repository: Open a shell, and traverse to the desired working directory. Execute the following command (in a single line): svn checkout assignment4 This will create a new folder called assignment4 which will contain all the project's files. Build xv6 by calling: make Run xv6 on top of QEMU by calling: make qemu Task 1: Improving the Cache Buffer Search Time As already mentioned above, the buffer cache maintains a double linked list of sectors. The most recently used sector is placed at the front of the list, enforcing a policy of LRU on the sectors referenced. Based on the principle of locality we hope searching the linked list will take little time, as the most recently used sectors are at the head of the list. However, in the worst case scenario, searching a sector in the list would take O(n) time, where n is the number of sectors in the list. In this task you are to imrpove the efficiency of searching the data structure by adding a Hash table. Given a pair of device number and sector as the key, the hash returns the block corresponding to that pair (key). When a block is requested you will use the hash table to find it in the cache, instead of linearly scanning the linked list. Make the necessray changes to support this improvment. It is up to you to figure out which hash function to use and what changes are required. Hint: you might want an achor table. Hint: several blocks in the cahce might have the same hash value (belong to the same hash-bucket).

4 Task 2: Sector Replacement Policy in the Cache Buffer The buffer cache stores the most recently used disk sectors, regardless of which file each sector belongs to. For example, the cache can contain data of only one file. In this task you will prevent this possibility, based on the configuration paramater SRP = i, where i is some non-negative integer. Add this line to param.h: #define SRP = 5 Default value for SRP should be 5 but we may replace this value during testing. When SRP = i and i>2, you will prevent the cache from containing more than i sectors that belong to the same file. For example, assume i=3 and the cache capacity is 6 sectors (to make things simple). If the user reads a file, the file's blocks are being read into memory and into the cache. Once the cache contains 3 blocks that belong to this file, reading another block forces the cache to remove one of the 3 existing blocks from the cache to make room to load the 4 th block. This means that the cache will never exceed 50% capacity while reading this one file. To fill the rest of the cache, the system would have to load data blocks of a different file. To summarize, the cache may only contain upto i amount of blocks which belong to the same file. When there are already i such blocks and another must be loaded, you pick one of the existing i blocks and remove it to make room. When SRP = i and i<3, the system behaves normally - there are no constraints on the cache (as it did before you implemented this task). Notice for example that device (disk) number 1 may have an inode 122 and device (disk) number 2 may have an inode number 122, and these are DIFFERENT files as they reside on different devices. Task 3: Printing the Cache Buffer Add support via the makefile macro (if you don't remember what that is look back to SCHEDFLAG from assignment 1) SRPPrint to print to stdout whenever the buffer cache changes. If SRPPrint = TRUE then after every change to the buffer cache you are to print a line whose content is in the following format: For example: BC = [ <d#,s#,i#>, <d#,s#,i#>, <d#,s#,i#>, <d#,s#,i#>. <d#,s#,i#>] BC = [ <0,1,5>, <0,2,5>, <0,6,4>] means that the cache contains 3 sectors, the first sector belongs to device 0, sector number 1, and belongs to the file whose i-node number is 5. The next sector in the cache is also from device 0, sector number 2, i-node 5. The last sector is from device 0, sector 6, i-node 4. If a sector is added to the cache or removed from it (or replaces some other sector), the status line is printed again to show the changes to the buffer cachce.

5 Task 4: Renaming a File Add the following system call: rename(char* path, char* oldname, char* newname) which changes the name of the file in the directory path from name oldname to name newname. If the file oldname does not exist or the path is invalid, return -1. If there is already another file named newname in that directory, renaming is impossible (can't have two different files with the same name in same directory) so return -2. Task 5: Sanity test First create 3 files: File "a.txt" that contains 6 times the character 'a', a file "b.txt" that contains 600 times the character 'b' and a file "c.txt" that contains 6000 times the character 'c'. Create a program named check1.c which opens file "a.txt", reads it in full and closes it. Then, the same is done for file "b.txt" and finally for file "c.txt". Create a program named check2.c which receives one command line paramter named amount. For example: > check2 3 The program first opens all 3 files, next it performs iterations of reads. In each iteration the program reads amount characters from each file (first from a.txt, then b.txt then c.txt). Once we reach an end of file we close that file and continue the iterations with the remaining files. Once all data of all files is read, the program terminates. Create a program ren.c that takes 3 command line arguments, and calls the system call rename with those 3 arguments. Submission guidelines Assignment due date: 15/06/ :00 Make sure that your Makefile is properly updated and that your code compiles with no warnings whatsoever. We strongly recommend documenting your code changes with remarks these are often handy when discussing your code with the graders. Due to our constrained resources, assignments are only allowed in pairs. Please note this important point and try to match up with a partner as soon as possible. Submissions are only allowed through the submission system. To avoid submitting a large number of xv6 builds you are required to submit a patch (i.e. a file which patches the original xv6 and applies all your changes). You may use the following instructions to guide you through the process: Back-up your work before proceeding!

6 Before creating the patch review the change list and make sure it contains all the changes that you applied and noting more. Modified files are automatically detected by svn but new files should be added explicitly with the svn add command: >svn add<filename> In case you need to revert to a previous version: >svn revert <filename> At this point you may examine the differences (the patch): >svn diff Alternatively, if you have a diff utility such as kompare: >svn diff kompare o - Once you are ready to create a patch simply make sure the output is redirected to the patch file: >svn diff>id1_id2.patch Tip: although graders will only apply your latest patch file, the submission system supports multiple uploads. Use this feature often and make sure you upload patches of your current work even if you haven t completed the assignment. Finally, note that the graders are instructed to examine your code on lab computers only(!) - Test your code on lab computers prior to submission. Enjoy!!!