An Operating Systems Vade Mecum

Physical representation 221The structure just described works very well for sequential access, in which theentire file is read from start to finish. When the file is opened, the file manager can readthe file descriptor into main store and use its information to direct the input of the firstnine extents. Then the manager can read the overflow file descriptor into main store andcontinue the input. In fact, most very long files are read in exactly this fashion. They aretypically load images for large programs or data files created sequentially by one programto be read sequentially by another.However, long files used as databases are often accessed in non-sequential fashion.As we saw, the Position service call might indicate the exact byte of the file that is to beaccessed next. If this call is used, our use of extents and overflow file descriptors has twoshortcomings.To find out which block holds any given byte in the file, we must first calculatewhich extent holds that byte. This calculation requires repeated inspection of theextent entries in the descriptor because each extent may have a different size.If many overflow descriptors are used, seeking a great distance in the file mayrequire many disk operations to read all the overflow file descriptors between thecurrent location and the desired location.These problems can be addressed by a slight change in organization of the file descriptor.First, we can demand that all extents have the same length. Next, we can organize thefile descriptor as a tree, not as a linked list. The tree has a depth determined by the sizeof the file; the depth is indicated in one of the fixed locations in the file descriptor. Adepth-1 tree just uses the entries in the descriptor as direct pointers to extents. Figure6.11 is a depth-1 tree. It has ten entries; therefore, depth-1 trees may use up to tenextents.A depth-2 tree treats each entry in the descriptor as a pointer to an overflowdescriptor, which is full of direct pointers to extents. If overflow descriptors can hold128 pointers, such files may use up to 1280 extents. A depth-3 tree treats those overflowdescriptors as indirect pointers yet again. Such files have 10 × 128 × 128 = 163,840extents.Let’s assume that we have a depth-3 tree representing an enormous file and wewish to find the block that has byte 1,000,000. Since there are 512 bytes in a block, wewant byte 64 of block 1953. (The first block is given the number 0.) Since each entry inthe file descriptor is the root of a subtree of blocks that includes 128 × 128 = 16,384blocks, the block we want is in the first subtree. We now read the overflow descriptorpointed to by the first entry in the file descriptor. Since each of its 128 entries governs128 blocks, we want the 33rd block in the 16th entry. We read the overflow blockpointed to by the 16th entry. Its 33d block is the one we want. We have accessed a particularbyte with four disk accesses. Some of these accesses may have been avoided bycache hits because the disk driver caches recently used disk blocks in main store.Our new organization does have its costs. If we do not know how long a file willbe when it is created, we will have to assume it needs only a one-level tree. When it outgrowsthose limits, the organization must be changed, rearranging entries (although notrecopying any data blocks). One way to avoid this rearrangement is to let the first sevenentries always be direct pointers. The eighth could head a two-level tree, the ninth athree-level tree, and the tenth a four-level tree. This scheme is pictured in Figure 6.13,which only begins to suggest how huge the file can grow.