laurir (02/06/83)
Is there a reason why interleaving of blocks (or sectors) is not done
at the device driver level, rather than by /etc/mkfs ? Most other
OS's let the driver do it.
Any valuable answers will be summarized.
-- Andrew Klossner (decvax!tektronix!tekmdp!laurir)dyer (02/06/83)
The key lies in the meaning of "interleave". With most UNIX systems, physical sectors are contiguous at the device driver level. This assumes that multi-sector I/O can be performed by the hardware, given only a starting disk address and a count. Non-file system operations (swapping, raw I/O) are accomplished in this way. If the underlying disk hardware cannot support multi-sector I/O, then it is common to implement a device-driver level interleaving scheme to minimize latency. But, most mini-type systems don't require this. However, it's another matter when performing I/O within the UNIX file system abstraction. Remember that logically contiguous blocks are not physically contiguous on the disk. Each disk block requires a separate I/O request. The so-called "interleaving" that mkfs performs is actually a sort on the list of free blocks, so that a program reading or writing a file sequentially will not suffer unnecessary latency between logical I/O requests. So, you see, this "interleaving" is quite orthogonal to device-driver interleaving. As I alluded before, the actual interleaving factors are crucially dependent on rotational speed, seek time, and overall throughput of your disk subsystem. As delivered for V7, they're set up for a PDP11-70/RP03. Figures for other processor/ hardware combinations have been published in ";login"; I don't have them on-hand. Maybe others can submit them. We had to discover them empirically for our C/60 and C/70 systems. Steve Dyer
johnl (02/07/83)
#R:tekmdp:-175400:ima:20400003:000:355 ima!johnl Feb 6 17:15:00 1983 I expect that disk interleave is not done in the device driver so that multi-block transfers, such as occur in swapping or raw disk I/O, can be done in a single disk operation. Some small Unix systems such as Onyxes interleave at a very low level and swapping is pretty slow. John Levine, decvax!yale-co!jrl, ucbvax!cbosgd!ima!johnl, research!ima!johnl
hickman (02/10/83)
#R:tekmdp:-175400:zinfandel:12400014:000:1191 zinfandel!hickman Feb 10 08:54:00 1983 You seem to be confusing the several types of interleaving available: 1) Disk format interleaving: - When the disk pack is formatted, an interleave is specified which allows the controller to get sequential multiple sector reads in the same rotation (i.e., no rotational loss because the controller couldn't finish dealing with the first sector before the second sector passed under the disk heads) 2) Unix filesystem interleaving: - on top of the normal (and hopefully transparent) disk interleaving, unix allows a filesystem interleave which is valid only at the time of a "mkfs". Once the filesystem has been used, blocks tend to be moved around alot, and the interleave gets lost. This is done so that files which don't move, will be accessable to unix without rotational delays. Unix attempts read ahead, and thus the filesystem rotational interleave should be set for whatever time is needed to send the first request to the driver and compute the read ahead request. Unfortunately, the filesystem interleave has little if no effect on most unix systems (4.1, 4.2 are exceptions). Hope this brings things into focus... kipp hickman
dmmartindale (02/13/83)
I'm not aware of any of the disks that are used on UNIX systems which have the packs formatted so that numerically adjacent sectors are not physically adjacent on the pack - what you call "format interleaving" is not done. There is sufficient gap between sectors that the controller can be ready to read the next header by the time it comes by. On a disk with N sectors per track, if you do an N-block read the whole thing is done with one revolution of the pack; interleaving the sectors at the pack level would make several revolutions necessary, drastically slowing down the transfer rate for long I/Os.