1 / 109

ecs150 Spring 2006 : Operating System #5: File Systems (chapters: 6.4~6.7, 8)

ecs150 Spring 2006 : Operating System #5: File Systems (chapters: 6.4~6.7, 8). Dr. S. Felix Wu Computer Science Department University of California, Davis http://www.cs.ucdavis.edu/~wu/ sfelixwu@gmail.com. File System Abstraction. Files Directories. System-call interface.

vallari
Download Presentation

ecs150 Spring 2006 : Operating System #5: File Systems (chapters: 6.4~6.7, 8)

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. ecs150 Spring 2006:Operating System#5: File Systems(chapters: 6.4~6.7, 8) Dr. S. Felix Wu Computer Science Department University of California, Davis http://www.cs.ucdavis.edu/~wu/ sfelixwu@gmail.com ecs150, spring 2006

  2. File System Abstraction • Files • Directories ecs150, spring 2006

  3. System-call interface Active file entries VNODE Layer or VFS Local naming (UFS) FFS Buffer cache Block or character device driver Hardware ecs150, spring 2006

  4. ecs150, spring 2006

  5. ecs150, spring 2006

  6. ecs150, spring 2006

  7. dirp = opendir(const char *filename); struct dirent *direntp = readdir(dirp); struct dirent { ino_t d_ino; char d_name[NAME_MAX+1]; }; directory dirent inode file_name dirent inode file_name dirent inode file_name file file file ecs150, spring 2006

  8. Local versus Remote • System Call Interface • V-node • Local versus remote • NFS or i-node • Stackable File System • Hard-disk blocks ecs150, spring 2006

  9. File-System Structure • File structure • Logical storage unit • Collection of related information • File system resides on secondary storage (disks). • File system organized into layers. • File control block – storage structure consisting of information about a file. ecs150, spring 2006

  10. File  Disk • separate the disk into blocks • separate the file into blocks as well • paging from file to disk blocks: 4 - 7- 2- 10- 12 How to represent the file?? How to link these 5 pages together?? ecs150, spring 2006

  11. Hard Disk • Track, Sector, Head • Track + Heads  Cylinder • Performance • seek time • rotation time • transfer time • LBA • Linear Block Addressing ecs150, spring 2006

  12. File  Disk blocks 0 file block 0 file block 1 file block 2 file block 3 file block 4 4 7 2 10 12 • What are the disadvantages? • disk access can be slow for “random access”. • How big is each block? 64 bytes? 68 bytes? ecs150, spring 2006

  13. A File System partition partition partition b s i-list directory and data blocks d i-node i-node ……. i-node ecs150, spring 2006

  14. One Logical File  Physical Disk Blocks efficient representation & access ecs150, spring 2006

  15. An i-node A file ??? entries in one disk block Typical: each block 8K or 16K bytes ecs150, spring 2006

  16. inode (index node) structure • meta-data of the file. • di_mode 02 • di_nlinks 02 • di_uid 02 • di_gid 02 • di_size 04 • di_addr 39 • di_gen 01 • di_atime 04 • di_mtime 04 • di_ctime 04 ecs150, spring 2006

  17. System-call interface Active file entries VNODE Layer or VFS Local naming (UFS) FFS Buffer cache Block or character device driver Hardware ecs150, spring 2006

  18. ecs150, spring 2006

  19. A File System partition partition partition b s i-list directory and data blocks d i-node i-node ……. i-node ecs150, spring 2006

  20. ecs150, spring 2006

  21. 125 struct ufs2_dinode { 126 u_int16_t di_mode; /* 0: IFMT, permissions; see below. */ 127 int16_t di_nlink; /* 2: File link count. */ 128 u_int32_t di_uid; /* 4: File owner. */ 129 u_int32_t di_gid; /* 8: File group. */ 130 u_int32_t di_blksize; /* 12: Inode blocksize. */ 131 u_int64_t di_size; /* 16: File byte count. */ 132 u_int64_t di_blocks; /* 24: Bytes actually held. */ 133 ufs_time_t di_atime; /* 32: Last access time. */ 134 ufs_time_t di_mtime; /* 40: Last modified time. */ 135 ufs_time_t di_ctime; /* 48: Last inode change time. */ 136 ufs_time_t di_birthtime; /* 56: Inode creation time. */ 137 int32_t di_mtimensec; /* 64: Last modified time. */ 138 int32_t di_atimensec; /* 68: Last access time. */ 139 int32_t di_ctimensec; /* 72: Last inode change time. */ 140 int32_t di_birthnsec; /* 76: Inode creation time. */ 141 int32_t di_gen; /* 80: Generation number. */ 142 u_int32_t di_kernflags; /* 84: Kernel flags. */ 143 u_int32_t di_flags; /* 88: Status flags (chflags). */ 144 int32_t di_extsize; /* 92: External attributes block. */ 145 ufs2_daddr_t di_extb[NXADDR];/* 96: External attributes block. */ 146 ufs2_daddr_t di_db[NDADDR]; /* 112: Direct disk blocks. */ 147 ufs2_daddr_t di_ib[NIADDR]; /* 208: Indirect disk blocks. */ 148 int64_t di_spare[3]; /* 232: Reserved; currently unused */ 149 }; ecs150, spring 2006

  22. 166 struct ufs1_dinode { 167 u_int16_t di_mode; /* 0: IFMT, permissions; see below. */ 168 int16_t di_nlink; /* 2: File link count. */ 169 union { 170 u_int16_t oldids[2]; /* 4: Ffs: old user and group ids. */ 171 } di_u; 172 u_int64_t di_size; /* 8: File byte count. */ 173 int32_t di_atime; /* 16: Last access time. */ 174 int32_t di_atimensec; /* 20: Last access time. */ 175 int32_t di_mtime; /* 24: Last modified time. */ 176 int32_t di_mtimensec; /* 28: Last modified time. */ 177 int32_t di_ctime; /* 32: Last inode change time. */ 178 int32_t di_ctimensec; /* 36: Last inode change time. */ 179 ufs1_daddr_t di_db[NDADDR]; /* 40: Direct disk blocks. */ 180 ufs1_daddr_t di_ib[NIADDR]; /* 88: Indirect disk blocks. */ 181 u_int32_t di_flags; /* 100: Status flags (chflags). */ 182 int32_t di_blocks; /* 104: Blocks actually held. */ 183 int32_t di_gen; /* 108: Generation number. */ 184 u_int32_t di_uid; /* 112: File owner. */ 185 u_int32_t di_gid; /* 116: File group. */ 186 int32_t di_spare[2]; /* 120: Reserved; currently unused */ 187 }; ecs150, spring 2006

  23. i-node • How many disk blocks can a FS have? • How many levels of i-node indirection will be necessary to store a file of 2G bytes? (I.e., 0, 1, 2 or 3) • What is the largest possible file size in i-node? ecs150, spring 2006

  24. Answer • How many disk blocks can a FS have? • 264 or 232: Pointer (to blocks) size is 8/4 bytes. • How many levels of i-node indirection will be necessary to store a file of 2G (231) bytes? (I.e., 0, 1, 2 or 3) • 12*210 + 28 * 210 + 28 *28 *2 10 +28 *28 *28 *2 10 >? 231 • What is the largest possible file size in i-node? • 12*210 + 28 * 210 + 28 *28 *2 10 +28 *28 *28 *2 10 • 264 –1 • 232 * 210 You need to consider three issues and find the minimum! ecs150, spring 2006

  25. A File System partition partition partition b s i-list directory and data blocks d i-node i-node ……. i-node ecs150, spring 2006

  26. FFS and UFS • /usr/src/sys/ufs/ffs/* • Higher-level: directory structure • Soft updates & Snapshot • /usr/src/sys/ufs/ufs/* • Lower-level: buffer, i-node ecs150, spring 2006

  27. # of i-nodes • UFS1: pre-allocation • 3% of HD, about < 25% used. • UFS2: dynamic allocation • Still limited # of i-nods ecs150, spring 2006

  28. di_size vs. di_blocks • ??? ecs150, spring 2006

  29. One Logical File  Physical Disk Blocks efficient representation & access ecs150, spring 2006

  30. di_size vs. di_blocks • Logical • Physical • fstat • du ecs150, spring 2006

  31. Extended Attributes in UFS2 • Attributes associated with the File • di_extb[2]; • two blocks, but indirection if needed. • Format • Length 4 • Name Space 1 • Content Pad Length 1 • Name Length 1 • Name mod 8 • Content variable • Applications: ACL, Data Labelling ecs150, spring 2006

  32. Some thoughts…. • What can you do with “extended attributes”? • How to design/implement? • Should/can we do it “Stackable File Systems”? • Otherwise, the program to manipulate the EA’s will have to be very UFS2-dependent or FiST with an UFS2 optimization option. • Are there any counter examples? • security and performance considerations. ecs150, spring 2006

  33. ecs150, spring 2006

  34. ecs150, spring 2006

  35. struct dirent { ino_t d_ino; char d_name[NAME_MAX+1]; }; struct stat {… short nlinks; …}; directory dirent inode file_name dirent inode file_name dirent inode file_name file file file ecs150, spring 2006

  36. A File System partition partition partition b s i-list directory and data blocks d i-node i-node ……. i-node ecs150, spring 2006

  37. ln –s /usr/src/sys/sys/proc.h ppp.h • ln /usr/src/sys/sys/proc.h ppp.h ecs150, spring 2006

  38. File System Buffer Cache application: read/write files translate file to disk blocks OS: ... ...buffer cache maintains controls disk accesses: read/write blocks hardware: Any problems? ecs150, spring 2006

  39. File System Consistency • To maintain file system consistency the ordering of updates from buffer cache to disk is critical • Example: • if the directory block is written back before the i-node and the system crashes, the directory structure will be inconsistent ecs150, spring 2006

  40. File System Consistency • File system almost always use a buffer/disk cache for performance reasons • This problem is critical especially for the blocks that contain control information: i-node, free-list, directory blocks • Two copies of a disk block (buffer cache, disk)  consistency problem if the system crashes before all the modified blocks are written back to disk • Write back critical blocks from the buffer cache to disk immediately • Data blocks are also written back periodically: sync ecs150, spring 2006

  41. Two Strategies • Prevention • Use un-buffered I/O when writing i-nodes or pointer blocks • Use buffered I/O for other writes and force sync every 30 seconds • Detect and Fix • Detect the inconsistency • Fix them according to the “rules” • Fsck (File System Checker) ecs150, spring 2006

  42. File System Integrity • Block consistency: • Block-in-use table • Free-list table • File consistency: • how many directories pointing to that i-node? • nlink? • three cases: D == L, L > D, D > L • What to do with the latter two cases? 0 1 1 1 0 0 0 1 0 0 0 2 1 0 0 0 1 1 1 0 1 0 2 0 ecs150, spring 2006

  43. File System Integrity • File system states (a) consistent (b) missing block (c) duplicate block in free list (d) duplicate data block ecs150, spring 2006

  44. Metadata Operations • Metadata operations modify thestructure of the file system • Creating, deleting, or renamingfiles, directories, or special files • Directory & I-node • Data must be written to disk in such a way that the file system can be recovered to a consistent state after a system crash ecs150, spring 2006

  45. Metadata Integrity • FFS uses synchronous writes to guarantee the integrity of metadata • Any operation modifying multiple pieces of metadata will write its data to disk in a specific order • These writes will beblocking • Guarantees integrity and durability of metadata updates ecs150, spring 2006

  46. Deleting a file (I) i-node-1 abc def i-node-2 ghi i-node-3 Assume we want to delete file “def” ecs150, spring 2006

  47. Deleting a file (II) i-node-1 abc ? def ghi i-node-3 Cannot delete i-node before directory entry “def” ecs150, spring 2006

  48. Deleting a file (III) • Correct sequence is • Write to disk directory block containing deleted directory entry “def” • Write to disk i-node block containing deleted i-node • Leaves the file system in a consistent state ecs150, spring 2006

  49. Creating a file (I) i-node-1 abc ghi i-node-3 Assume we want to create new file “tuv” ecs150, spring 2006

  50. Creating a file (II) i-node-1 abc ghi i-node-3 tuv ? Cannot write directory entry “tuv” before i-node ecs150, spring 2006

More Related