1
play

1 Lab 5::Pintos file-structures Lab 5::Reading/Writing (1) Lab - PowerPoint PPT Presentation

Lab 5::General Description Lab 5::General Description Lab 5: File System Lab 5: File System Laboratory work in TDDI04 Synchronization of read-write operations Synchronization of read-write operations Pintos Assignment 5 One


  1. Lab 5::General Description Lab 5::General Description Lab 5: “File System” Lab 5: “File System” Laboratory work in TDDI04 Synchronization of read-write operations Synchronization of read-write operations Pintos Assignment 5 One writer writes at a time One writer writes at a time Many readers can read Many readers can read Additional system calls to work with files Additional system calls to work with files Viacheslav Izosimov seek() seek() 2009-04-23 tell() tell() viaiz@ida.liu.se filesize() filesize() remove() remove() Creating and removing files without destroying the Creating and removing files without destroying the file system file system Lab 5::Files (1) Lab 5::Files (2) Lab 5::Pintos file-structures filesys/file.[h|c] - operations on files. Open files Open inodes Disk location A file object represents an open file. filesys/free-map.[h|c] - struct struct inode file { … } { … } filesys/filesys.[h|c] - operations on STDIN implementation of the map used to keep track of STDOUT P1 struct 561 2 struct inode file { … } the file system. 3 876 { … } all free and occupied disk sectors. Important that 4 785 struct struct inode filesys/directory.[h|c] - operations on file { … } 667 { … } no two files can allocate the same sector. directories. struct inode struct { … } devices/disk.[h|c] - implementation of STDIN file { … } filesys/inode.[h|c] - the most important P2 STDOUT 2 the low-level access to the disk-drive. struct 5 file { … } part of the implementation related to the file Directory Free map system. An inode object represents an STDIN pfs struct STDOUT pfs_reader P3 file { … } 3 pfs_writer individual file (e.g. several open files fd 1, fd 2, fd 3 may belong to one inode “ student.txt ”). 1

  2. Lab 5::Pintos file-structures Lab 5::Reading/Writing (1) Lab 5::Reading/Writing (2) Several readers should be able to read from a file Readers should not starve Consider the previous picture and motivate the at the same time solution. Writers can starve Study the code and determine how the various Reading should be forbidden if the file content is However, think about solution to avoid the structures are involved when: being changed by the writer problem of starvation, even though you are not Creating a file (filesys_create) Only one writer can write to a file at a time obliged to implement it Opening a file (filesys_open) The writer must not write if at least one reader is Reading/writing (file_read/file_write) reading from the file Note that, in this lab assignment, you are not Setting the file position (file_seek, file_tell) asked to implement dynamic enlargement / Closing a file (file_close) reducing of the file size (if you want to write Removing a file (filesys_remove) more than the file size currently is) Lab 5::Reading/Writing (3) Lab 5::Reading/Writing (4) Synchronization Pitfalls Ways to implement: A good starting point is to implement atomic locking Inode counters in inode.c (for example, allowing only one reader or one writer. Locks/Conditions open_cnt counter) Consider carefully where to place the lock so that Semaphores Access to the disk drive during creating a file: different files still can be accessed simultaneously. One file can be opened several times and Step 1: Creating an entity in the directory processes can attempt to read/write Extend this solution to allow several readers, consider: Step 2: Creating a tree of inodes simultaneously at any place in the file What must be done by the first reader? Must not be interrupted! What must be done by the N:th reader? You need to apply synchronization not to each Global shared data such as FreeMap – a global file structure, but to the entire file! What must be done by the last reader? bitmap for the entire hard drive (critical section With this solution, carefully consider where to use locks Synchronization can be done on one of three and where to use locking semaphores. problem!) levels: system calls , files , and i nodes . Can starvation occur? Which level would you choose? Motivate !!! 2

  3. Lab 5:: Additional System Calls Lab 5:: Create and Remove Lab 5::Final Tests (1) void seek (int fd , unsigned position ) The following tests should pass if your implementation is correct in addition Creating and removing of files must not lead to destructive to the tests from Lab 2 and Lab 3: consequences to the file system Sets the current position in the open file fd to position . If the position tests/filesys/base/lg-create exceeds the file size, it should be set to the end of file. tests/filesys/base/lg-full Create and remove are writing operations on the directories tests/filesys/base/lg-random unsigned tell (int fd ) ( filesys/directory[.h|.c] ) tests/filesys/base/lg-seq-block tests/filesys/base/lg-seq-random Returns the current position in the open file fd . tests/filesys/base/sm-create Open is the reading operation on the directories tests/filesys/base/sm-full int filesize (int fd ) tests/filesys/base/sm-random In principle, synchronization of reading/writing operations on Returns the file size of the open file fd . tests/filesys/base/sm-seq-block directories should be handled as synchronization of files, tests/filesys/base/sm-seq-random bool remove (const char *file_name ) tests/filesys/base/syn-read but … tests/filesys/base/syn-remove Removes the file file_name . tests/filesys/base/syn-write For the sake of making student life more convenient, in this lab tests/userprog/close-twice Note that the open files must not be deleted from the file system before tests/userprog/read-normal assignment, you are advised to handle synchronization of they are closed. If the file is to be removed, the operating system tests/userprog/multi-recurse should wait until the file is closed and only then it can delete it. This directories as the critical section problem tests/userprog/multi-child-fd functionality has been already implemented! Lab 5::Final Tests (2) Lab 5::Final Tests (3) Lab 5::Final Tests (4) For testing your readers-writers algorithm, we provide the following user programs in The result is copied into messages file, which should only contain the word In order to run the tests you need to do the following: the examples directory: pfs.c, pfs_reader.c, and pfs_writer.c "cool" (how many times?) like this: Copy this Make.tests to "pintos/src/tests/userprog". These programs try to emulate several readers and writers accessing the same file. cool Copy this Make.vars to "pintos/src/userprog". A script exist to run the test several times, run_pfs_test 5 cool cool Or you can run it directly like: Go to "pintos/src/userprog". cool Clean up everything with "gmake clean". cool cool Run "gmake". pintos -v -k --qemu cool -p ../../examples/pfs -a pfs Go to "pintos/src/userprog/build". cool -p ../../examples/pfs_reader -a pfs_reader Run "gmake check". cool -p ../../examples/pfs_writer -a pfs_writer cool All 66 tests should pass if the implementation is correct. -g messages -- -f -q run pfs cool cool grep -c cool messages cool cool cool ... 3

  4. Conclusion (1) Conclusion (2) In this course you do the first “real” programming Do not wait until the summer vacation! Learning of handing complex programming tasks Complete your assignments now! Self-management training Training of planning skills Working with a pile of extensive documentation And, last but not least, understanding of the basic concepts of operating systems 4

Recommend


More recommend