Your SlideShare is downloading. ×

Unixfs

296

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
296
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. File Systems (1) CS 167 1Copyright © 1999 Thomas W. Doeppner. All rights reserved. XVII-1
  • 2. File Systems • System 5 File System (S5FS) • UNIX File System (UFS) • Buffer Cache CS 167 2 In this lecture we cover the "traditional" UNIX file systems: S5FS and UFS. Wethen look at how kernel-supported buffering is used to speed file-system operationsand the trouble this sometimes causes. XVII-2
  • 3. S5FS: Inode Device Inode Number Mode Link Count Owner, Group Size Disk Map CS 167 3 In both S5FS and UFS, a data structure known as the inode (for index node) isused to represent a file. These inodes are the focus of all file activity, i.e., everyaccess to a file must make use of information from the inode. Every file has a inodeon permanent (disk) storage. While a file is active (e.g. it is open), its inode isbrought into primary storage. XVII-3
  • 4. Disk Map 0 1 2 3 4 5 6 7 8 9 10 11 12 CS 167 4 The first file system we discuss is known as the S5 File System -- it is based on theoriginal UNIX file system, developed in the early seventies. The name S5 comes fromthe fact that this was the only file system supported in early versions of whatsknown as UNIX System V. The purpose of the disk-map portion of the inode is to map block numbers relativeto the beginning of a file into block numbers relative to the beginning of the filesystem. Each block is 1024 (1K) bytes long. The disk map consists of 13 pointers to disk blocks, the first 10 of which point tothe first 10 blocks of the file. Thus the first 10Kb of a file are accessed directly. If thefile is larger than 10Kb, then pointer number 10 points to a disk block called anindirect block. This block contains up to 256 (4-byte) pointers to data blocks (i.e.,256KB of data). If the file is bigger than this (256K +10K = 266K), then pointernumber 11 points to a double indirect block containing 256 pointers to indirectblocks, each of which contains 256 pointers to data blocks (64Mb of data). If the fileis bigger than this (64MB + 256KB + 10KB), then pointer number 12 points to atriple indirect block containing up to 256 pointers to double indirect blocks, each ofwhich contains up to 256 pointers pointing to single indirect blocks, each of whichcontains up to 256 pointers pointing to data blocks (potentially 16GB, although thereal limit is 2GB, since the file size, a signed number of bytes, must fit in a 32-bitword). This data structure allows the efficient representation of sparse files, i.e., fileswhose content is mainly zeros. Consider, for example, the effect of creating an emptyfile and then writing one byte at location 2,000,000,000. Only four disk blocks areallocated to represent this file: a triple indirect block, a double indirect block, asingle indirect block, and a data block. All pointers in the disk map, except for thelast one, are zero. All bytes up to the last one read as zero. This is because a zeropointer is treated as if it points to a block containing all zeros: a zero pointer to anindirect block is treated as if it pointed to an indirect block filled with zero pointers,each of which is treated as if it pointed to a data block filled with zeros. However,one must be careful about copying such a file, since commands such as cp and taractually attempt to write all the zero blocks! (The dump command, on the other XVII-4hand, copes with sparse files properly.)
  • 5. S5FS Layout Data Region I-list Superblock Boot block CS 167 5 The file system is organized on disk as four separate regions: • Boot block – used on some systems to contain a bootstrap program • Superblock – describes the file system: · total size · size of inode list (I-list) · header of free-block list · list of free inodes · modified flag · read-only flag · number of free blocks and free inodes · resides in a buffer borrowed from the buffer cache while the file system is mounted • I-list – area for allocating inodes • Data region – remainder of file system is for data blocks and indirect blocks A problem with this organization is the separation of the I-list and the data region.Since one must always fetch the inode before reading or writing the blocks of a file,the disk head is constantly moving back and forth between the I-list and the dataregion. XVII-5
  • 6. S5FS Free List 99 98 97 99 98 0 97 Super Block 0 CS 167 6 Free disk blocks are organized as shown in the picture. The superblock containsthe address of up to 100 free disk blocks. The last of these disk blocks contains 100pointers to additional free disk blocks. The last of these pointers points to anotherblock containing up to n free disk blocks, etc., until all free disk blocks arerepresented. Thus most requests for a free block can be satisfied by merely gettingan address from the superblock. When the last block reference by the superblock isconsumed, however, a disk read must be done to fetch the addresses of up to 100more free disk blocks. Freeing a disk block results in reconstructing the liststructure. This organization, though very simple, scatters the blocks of files all over thesurface of the disk. When allocating a block for a file, one must always use the nextblock from the free list; there is no way to request a block at a specific location. Nomatter how carefully the free list is ordered when the file system is initialized, itbecomes fairly well randomized after the file system has been used for a while. XVII-6
  • 7. S5FS Free Inode List 16 0 15 14 13 0 12 0 11 0 13 10 9 0 8 11 7 6 6 0 12 5 4 4 0 3 Super Block 2 1 I-list CS 167 7 Inodes are allocated from the I-list. Free inodes are represented simply by zeroingtheir mode bits. The superblock contains a cache of indices of free inodes. When afree inode is needed (i.e., to represent a new file), its index is taken from this cache.If the cache is empty, then the I-list is scanned sequentially until enough free inodesare found to refill the cache. To speed this search somewhat, the cache contains a reference to the inode withthe smallest index that is known to be free. When an inode is free, it is added to thecache if there is room, and its mode bits are zeroed on disk. XVII-7
  • 8. UFS • The goal is to lay out files on disk so that they can be accessed as quickly as possible and so that as little disk space as possible is wasted • Component names of directories can be much longer than in the original (S5) file system CS 167 8 UFS was developed at the University of California at Berkeley as part of the versionof UNIX known as 4.2 BSD (BSD stands for Berkeley Software Distribution). It wasdesigned to be much faster than the S5 file system and to eliminate some of itsrestrictions, such as the length of components within directory path names. This material is covered in The Design and Implementation of the 4.3BSD UNIXOperating System, by Leffler et al. XVII-8
  • 9. UFS Directory Format 117 16 4 u n i x 0 4 12 3 e t c 0 18 484 3 u s r 0 Free Space Directory Block CS 167 9 UFS allows component names of directory path names to be up to 255 characterslong, thereby necessitating a variable-length field for components. Directories arecomposed of 512-byte blocks and entries must not cross block boundaries. Thisdesign adds a degree of atomicity to directory updates. It should take exactly onedisk write to update a directory entry (512 bytes was chosen as the smallestconceivable disk sector size). If two disk writes are necessary to modify a directoryentry, then clearly the disk will crash between the two! Like the S5 directory entry, the UFS directory entry contains the inode numberand the component name. Since the component name is of variable length, there isalso a string length field (the component name includes a null byte at the end; thestring length does not include the null byte). In addition to the string length, there isalso a record length, which is the length of the entire entry (and must be a multipleof four to ensure that each entry starts on a four-byte boundary). The purpose of therecord length field is to represent free space within a directory block. Any free spaceis considered a part of the entry that precedes it, and thus a record length longerthan necessary indicates that free space follows. If a directory entry is free, then itsrecord length is added to that of the preceding entry. However, if the first entry in adirectory block is free, then this free space is represented by setting the inodenumber to zero and leaving the record length as is. Compressing directories is considered to be too difficult. Free space within adirectory is made available for representing new entries, but is not returned to thefile system. However, if there is free space at the end of the directory, the directorymay be truncated to a directory block boundary. XVII-9
  • 10. Doing File-System I/O Quickly • Transfer as much as possible with each I/O request • Minimize seek time (i.e. reduce head movement) • Minimize latency time CS 167 10 The UFS file system uses three techniques to improve I/O performance. The firsttechnique, which has perhaps the greatest payoff, maximizes the amount of datatransferred with each I/O request by using a relatively large block size. UFS blocksizes may be either 4K bytes or 8K bytes (the size is fixed for each individual filesystem). A disadvantage of using a large block size is the wastage due to internalfragmentation: on the average, half of a disk block is wasted for each file. To alleviatethis problem, blocks may be shared among files under certain circumstances. The second technique to improve performance is to minimize seek time byattempting to locate the blocks of a file near to one another. Finally, UFS attempts to minimize latency time, i.e. to reduce the amount of timespent waiting for the disk to rotate to bring the desired block underneath the desireddisk head (many modern disk controllers make it either impossible or unnecessaryto apply this technique). XVII-10
  • 11. UFS Layout data cg n-1 inodes cg block super block cg i data data cg 1 cg summary inodes cg block cg 0 super block boot block CS 167 11 The UFS file system is laid out on disk as follows: • Superblock – incore while the file system is mounted – contains the parameters describing the layout of the file system – for paranoias sake, one copy is kept in each cylinder group, at a rotating track position • Cylinder group summary (one for each cylinder group) – incore while the file system is mounted – contains a summary of the available storage in each cylinder group – allocated from the data section of cylinder group 0 • Cylinder group block – contains free block map and all other allocation information Note: the superblock contains two sorts of information, static and dynamic. Thestatic information describes the layout of the entire file system and is essential tomake sense of the file system. The dynamic information describes the file systemscurrent state and can be computed from redundant information in the file system. Ifthe static portion of the superblock is lost, then the file system cannot be used. Toguard against this, each cylinder group contains a copy of the superblock (just thestatic information needs to be copied). A possible (though unlikely) failure condition might be that the entire contents ofone surface are lost, but the remainder of the disk is usable. However, if this surfacecontains all copies of the superblock, then the rest of the disk would be effectivelyunusable. To guard against this, the copy of the superblock is placed on a differentsurface in each cylinder group. Of course, the system must keep track of wherethese copies are. This information is kept in the disk label (along with informationdescribing how the physical disk is partitioned). XVII-11
  • 12. Minimizing Fragmentation Costs • A file system block may be split into fragments that can be independently assigned to files – fragments assigned to a file must be contiguous and in order • The number of fragments per block (1, 2, 4, or 8) is fixed for each file system • Allocation in fragments may only be done on what would be the last block of a file, and only if the file does not contain indirect blocks CS 167 12 Fragmentation is what Berkeley calls their technique for reducing disk spacewastage due to file sizes not being an integral multiple of the block size. Files arenormally allocated in units of blocks, since this allows the system to transfer data inrelatively large, block-size units. But this causes space problems if we have lots ofsmall files, where the average amount of space wasted per file (half the block size) isan appreciable fraction of the size of the file (the wastage can be far greater than thesize of the file for very small files). The ideal solution might be to reduce the blocksize for small files, but this could cause other problems; e.g., small files might growto be large files. The solution used in UFS is to have all of the blocks of a file be thestandard size, except for perhaps the last block of a file. This block may actually besome number of contiguous, in-order fragments of a standard block. XVII-12
  • 13. Use of Fragments (1) File A File B CS 167 13 This example illustrates a difficulty associated with the use of fragments. The filesystem must preserve the invariant that fragments assigned to a file must becontiguous and in order, and that allocation of fragments may be done only on whatwould be the last block of the file. In the picture, the direction of growth isdownwards. Thus file A may easily grow by up to two fragments, but file B cannoteasily grow within this block. In the picture, file A is 18 fragments in length, file B is 12 fragments in length. XVII-13
  • 14. Use of Fragments (2) File A File B CS 167 14File A grows by one fragment. XVII-14
  • 15. Use of Fragments (3) File A File B CS 167 15 File A grows by two more fragments, but since there is no space for it, the filesystem allocates another block and copies file As fragments into it. How much spaceshould be available in the newly allocated block? If the newly allocated block isentirely free, i.e., none of its fragments are used by other files, then further growthby file A will be very cheap. However, if the file system uses this approach all thetime, then we do not get the space-saving benefits of fragmentation. An alternativeapproach is to use a "best-fit" policy: find a block that contains exactly the numberof free fragments needed by file A, or if such a block is not available, find a blockcontaining the smallest number of contiguous free fragments that will satisfy file Asneeds. Which approach is taken depends upon the degree to which the file system isfragmented. If disk space is relatively unfragmented, then the first approach is taken("optimize for time"). Otherwise, i.e., when disk space is fragmented, the file systemtakes the second approach ("optimize for space"). The points at which the system switches between the two policies is parameterizedin the superblock: a certain percentage of the disk space, by default 10%, is reservedfor superuser. (Disk-allocation techniques need a reasonable chance of finding freedisk space in each cylinder group in order to optimize the layout of files.) If the totalamount of fragmented free disk space (i.e., the total amount of free disk space notcounting that portion consisting of whole blocks) increases to 8% of the size of thefile system (or, more generally, increases to 2% less than the reserve), then furtherallocation is done using the best-fit approach. Once this approach is being used, ifthe total amount of fragmented free disk space drops below 5% (or half of thereserve), then further allocation is done using the whole-block technique. XVII-15
  • 16. Minimizing Seek Time • The principle: – keep related information as close together as possible – distribute information sufficiently to make the above possible • The practice: – attempt to put new inodes in the same cylinder group as their directories – put inodes for new directories in cylinder groups with "lots" of free space – put the beginning of a file (direct blocks) in the inodes cylinder group – put additional portions of the file (each 2MB) in cylinder groups with "lots" of free space CS 167 16 One of the major components (in terms of time) of a disk I/O operation is thepositioning of the disk head. In the S5 file system we didnt worry about this, but inthe UFS file system we would like to lay out files on disk so as to minimize the timerequired to position the disk head. If we know exactly what the contents of an entirefile system will be when we create it, then, in principle, we could lay files outoptimally. But we dont have this sort of knowledge, so, in the UFS file system, areasonable effort is made to lay files out "pretty well." XVII-16
  • 17. Minimizing Latency (1) 7 6 8 5 1 4 2 3 CS 167 17 Latency is the time spent waiting for the disk platter to rotate, bringing the desiredsector underneath the disk head. In most disks, latency time is dominated by seektime, but if weve done a good job improving seek time, perhaps we can dosomething useful with latency time. A naive way of laying out consecutive blocks of the file on a track would be to putthem in consecutive locations. The problem with this is that some amount of timepasses between the completion of one disk request and the start of the next. Duringthis time, the disk rotates a certain distance, probably far enough that the disk headis positioned after the next block. Thus it is necessary to wait for the disk to rotatealmost a complete revolution for it to bring the beginning of the next blockunderneath the disk head. This delay could cause a significant slowdown. XVII-17
  • 18. Minimizing Latency (2) 4 3 1 2 CS 167 18 A better technique is not to lay out the blocks on the track consecutively, but toleave enough space between them that the disk rotates no further than to theposition of the next block during the time between disk requests. It may be that when a new block is allocated for a file, the optimal position for thenext block is already occupied. If so, one may be able to find a block that is just asgood. If the disk has multiple surfaces (and multiple heads), then we can make thereasonable assumption that the blocks underneath each head can be accessedequally quickly. Thus the stack of blocks underneath the disk heads at one instantare said to be rotationally equivalent. If all of these blocks are occupied, then thenext stack of rotationally equivalent blocks in the opposite direction of disk rotationis almost as good as the first. If all of these blocks are taken, then the third stack isalmost as good, and so forth all the way around the cylinder. If all of these are taken,then any block within the cylinder group is chosen. This technique is perhaps not as useful today as in the past, since many diskcontrollers buffer entire tracks and hide the relevant disk geometry. XVII-18
  • 19. The Buffer Cache Buffer User Process Buffer Cache CS 167 19 File I/O in UNIX is not done directly to the disk drive, but through anintermediary, the buffer cache. The buffer cache has two primary functions. The first, and most important, is tomake possible concurrent I/O and computation within a UNIX process. The secondis to insulate the user from physical block boundaries. From a user threads point of view, I/O is synchronous. By this we mean that whenthe I/O system call returns, the system no longer needs the user-supplied buffer.For example, after a write system call, the data in the user buffer has either beentransmitted to the device or copied to a kernel buffer -- the user can now scribbleover the buffer without affecting the data transfer. Because of this synchronization,from a user threads point of view, no more than one I/O operation can be inprogress at a time. Thus user-implemented multibuffered I/O is not possible (in asingle-threaded process). The buffer cache provides a kernel implementation of multibuffering I/O, and thusconcurrent I/O and computation are possible even for single-threaded processes. XVII-19
  • 20. Multi-Buffered I/O Process read( … ) i-1 i i+1 previous current probable block block next block CS 167 20 The use of read-aheads and write-behinds makes possible concurrent I/O andcomputation: if the block currently being fetched is block i and the previous blockfetched was block i-1, then block i+1 is also fetched. Modified blocks are normallywritten out not synchronously but instead sometime after they were modified,asynchronously. XVII-20
  • 21. Maintaining the Cache buffer requests Aged probably free buffers returns of no-longer- active buffers oldest LRU probably active buffers returns of active youngest buffers CS 167 21 Active buffers are maintained in least-recently-used (LRU) order in the system-wideLRU list. Thus after a buffer has been used (as part of a read or write system call), itis returned to the end of the LRU list. The system also maintains a separate list of"free" buffers called the aged list. Included in this list are buffers holding no-longer-needed blocks, such as blocks from files that have been deleted. Fresh buffers are taken from the aged list. If this list is empty, then a buffer isobtained from the LRU list as follows. If the first buffer (least recently used) in thislist is clean (i.e., contains a block that is identical to its copy on disk), then thisbuffer is taken. Otherwise (i.e., if the buffer is dirty), it is written out to diskasynchronously and, when written, is placed at the end of the aged list. The searchfor a fresh buffer continues on to the next buffer in the LRU list, etc. When a file is deleted, any buffers containing its blocks are placed at the head ofthe aged list. Also, when I/O into a buffer results in an I/O error, the buffer isplaced at the head of the aged list. XVII-21
  • 22. File-System Consistency (1) New Node New Node 1 2 3 CS 167 22 In the event of a crash, the contents of the file system may well be inconsistentwith any view of it the user might have. For example, a programmer may havecarefully added a node to the end of the list, so that at all times the list structure iswell-formed. XVII-22
  • 23. File-System Consistency (2) CRASH!!! New Node New Node Not on Not on disk disk 1 2 3 4 5 CS 167 23 But, if the new node and the old node are stored on separate disk blocks, themodifications to the block containing the old node might be written out first; thesystem might well crash before the second block is written out. XVII-23
  • 24. Keeping It Consistent 2) Then write this asynchronously 1) Write this New Node synchronously CS 167 24 To deal with this problem, one must make certain that the target of a pointer issafely on disk before the pointer is set to point to it. This is done for certain systemdata structures (e.g., directory entries, inodes, indirect blocks, etc.). No such synchronization is done for user data structures: not enough is knownabout the semantics of user operations to make this possible. However, a userprocess called update executes a sync system call every 30 seconds, which initiatesthe writing out to disk of all dirty buffers. Alternatively, the user can open a file withthe synchronous option so that all writes are waited for; i.e, the buffer cache acts asa write-through cache (N.B.: this is expensive!). XVII-24

×