1 / 30

Topic 9 : File Systems

Topic 9 : File Systems. L & E: Pages 92-113 Tanenbaum: Pages 17-20 & 401-434. File System Objectives. Provide persistent storage for programs and data files. creation and deletion of files reading and writing of files allow reference to files by symbolic name

Download Presentation

Topic 9 : File Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Topic 9 : File Systems L & E: Pages 92-113 Tanenbaum: Pages 17-20 & 401-434

  2. File System Objectives • Provide persistent storage for programs and data files. • creation and deletion of files • reading and writing of files • allow reference to files by symbolic name • manage space available on secondary storage • protect files from unauthorised access and system failure • allow sharing of files

  3. Basic Operations • fd = open (filename, mode) • fd = a file descriptor • mode = read or write • Read (fd, buffer) • Write (fd, buffer) • Seek (fd, position) • Close (fd)

  4. Organising Files for the User • A flat file space is difficult for users. keith slides letters programs 1st year 2nd year Ada Pascal • Imposing a directory structure allows users to logically group files.

  5. Sharing and Security • This is only an issue in multi-user operating systems or those which support remote access to files. • The owners of files must be able to specify the access rights for files. • Two main approaches are to use either a protection mask or access control lists.

  6. Protection Masks • Users are classified as • owner (O) • members of a particular group (G) • others (W) • Access privileges are classified as • read access (R) • write access (W) • execute access (E) • delete access (D)

  7. Protection Masks ... contd. • Owner allocates a mask to a file, e.g. O:RWED, G:RWE, W:RE • Note: for this to work there must be a mechanism for grouping users. • This approach is used in UNIX systems.

  8. Access Control Lists • For each file a list of users and permissible operations is specified, e.g. a file could be read by uid x and any gid and written to by processes with uid y and gid staff. • Pros: • much more flexible than protection masks, it is possible to prohibit specific uids or guids from accessing a file. • Cons: • access control lists can take a lot of space • the ordering of entries in the list is critical to avoid big performance hit

  9. Storing Files on Disk • The next issue to address is how to store files on the disk. • Disks are block oriented devices, i.e. data is stored as a series of blocks. • Therefore files must be stored as a series of blocks. • Of course the question is how big to make the blocks ?

  10. Block Size and File System Performance • The average (median) UNIX file is 1K. • If blocks are made large then small files are very wasteful of disk space. • For example, if we make the block size equal to one cylinder (32K) then 97% (i.e. 31/32) of the disk space is wasted.

  11. Block Size and File System Performance • But, each block requires a separate read/write and so incurs a seek and rotational delay, • So, if we make blocks small then we get poor performance. • Good example of a fundamental conflict between resource utilisation and performance.

  12. The Trade Off… 100 200 Disk space utilisation 75 Assuming file size of 1K 150 Disk space utilisation (%) Kbytes/Sec 100 50 50 25 Data Rate 0 0 128 256 512 1K 2K 4K 8K Block Size

  13. Keeping Tracks of Blocks • We need to keep track of which blocks make up a given file. • Four main methods of doing this: • Make all blocks contiguous for a given file. • Link the blocks of a given file. • Use a file map. • Use index blocks.

  14. Contiguous Files • Keep all of the blocks of the file adjacent. • The directory entry for the file contains: • a pointer to the start • the length of the file

  15. Contiguous Files File Blocks Directory Entries 4 EOF

  16. Contiguous Files • Keep all of the blocks of the file adjacent. • The directory entry for the file contains: • a pointer to the start • the length of the file • Simple to implement • Good performance • Main problem is fragmentation (again!). • Need to reserve disk space • Resilient way of arranging data since corruptions are localised.

  17. Block Linkage • Maintain blocks in a linked list. • Each block contains a pointer to the next block or null if it is the end of the list.

  18. Block Linkage File Blocks Directory Entries 4 NULL

  19. Block Linkage • Maintain blocks in a linked list. • Each block contains a pointer to the next block or null if it is the end of the list. • Access must be sequential. • Data stored in a block is no longer 2n bytes • Corruption can cause real problems if links become corrupted. • Storing data using a doubly linked list can help.

  20. File Map • The state of the entire disk is stored in a file map. • The directory entry points to the first block of the file in the map. • The map contains links to the other blocks in the file. • Effectively, this is linked list allocation using an index.

  21. File Map File Map 0 Directory Entry 1 NULL 2 4 3 7 4 5 6 9 7 8 9 2

  22. File Map • Entire block available for data. • Random access much quicker given that the file map is held in main memory – no disk references. • File map can become very large. • Damage to the file map can result in serious data loss. • Many systems store multiple copies of the file map (though MS-DOS puts them all in the same place!).

  23. Index Blocks • Pointers to a file’s blocks are stored in one or more index blocks. • These index blocks are chained together if required for big files. • The directory entry for a file points to the first index block for the file.

  24. Index Blocks I-node

  25. Index Blocks • Big advantage is that files can be accessed non-sequentially. • In UNIX small files don’t have separate index blocks, instead the entries are in (effectively) the directory entry. • Corruption of an index block is bad news for the file in question.

  26. Free Space • In order to be able to write data to the disk we need to manage the free space. • This is often done using either: • linked list of disk blocks • Each block holds free disk block numbers • a file map (or bit map) • Disk with n blocks requires a bit map with n bits. • Preferred technique

  27. Implementing the Open Operation • look up the directory entry for the file • check access privileges • check if the file is already open • reading vs writing • find device and location of file or create new space • create a file descriptor which acts as a handle to the file

  28. A Quick Note on File Descriptors • These are the handles used by application programs onto files. • Avoids hard-wiring file name dependencies into programs. • Provides a convenient structure in which the O/S can store all its data such as • the location of the first block of the file • the location of the next block to read

  29. Summary • Looked at the major issues in building file systems. • Examined file space structuring, sharing and protection. • Conflict between space and time efficiency w.r.t block sizes. • The basic operations involved in carrying out an open operation. • The notion of file descriptors.

  30. Coming Next Week • Systems software

More Related