Under a non-sequential disk-block allocation scheme, the disk would have no external fragmentation because any page anywhere on the disk could be allocated to any file. Under a sequential disk-block allocation scheme, a disk might exhibit external fragmentation as files are deleted, creating holes that may not be exactly the same size as later disk allocation requests.
Both sequential and non-sequential disk-block allocation schemes are susceptible to internal fragmentation. Even if a sequential allocation request is exact, it must be rounded up to the nearest multiple of a disk block, leading to wasted space inside the file. In addition, the amount of internal fragmentation possible in non-sequential disk-block allocation schemes is bounded above by one disk block because the next disk block is not allocated until the last disk block is full. On the other hand, the amount of internal fragmentation possible in sequential disk-block allocation is bounded only by the number of blocks on the disk because the allocation request could wildly over-estimate the amount of disk space needed.
Yes, it is. A write-though cache solves the problem updating the disk with writes in a timely fashion, but it doesn't address the issue of what blocks should be dropped when the buffer cache is full. The LRU strategy is a good approximation to an optimal block replacement strategy, but it doesn't provide timely write updates to disk. When combined, the strengths of each technique compliment the weaknesses of the other.
/usr/bin/xterm. Assume the file exits and there are no links.
Starting at the known location of the directory root (/), look up the
i-node number associated with the file usr. The i-node associated with
usr indicates, among other things, that it's a directory, and the location
of its first disk block. The usr directory contains the i-node number
associated with the file /usr/bin, and the i-node itself indicates that
it's a directory and the location of its first disk block. The /usr/bin
directory indicates the i-node number for /usr/bin/xterm, and the
associated i-node indicates that it's an executable file, and the location of
its first disk block.
The i-nodes themselves are stored in tables spread through-out the file system, although it's most likely that the i-nodes for heavily used directories are cached in primary memory.
Neither of them, because the index linked list itself keeps track of the free blocks. Alternatively, you could have said the linked list scheme, if you made it clear that the index linked list itself used that scheme to keep track of the free blocks.
This page last modified on 3 April 2000.