chris@mimsy.UUCP (Chris Torek) (12/27/87)
In article <3075@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >To be fair, the RA-81 was a radical departure in disk subsystem >design. A lot of the smarts that used to be in the kernel-resident driver >are now in the controller. Not quite. VMS has no disk optimisation: It just queues I/O requests, then services them in queue order [1]. Any cacheing is done outside the kernel. On other controllers this leads to suboptimal seek patterns, and the lack of cacheing means that reread requests really re-read. The UDA50 accepts multiple commands and will do its own seek ordering, and has a cache. The last sentence above should thus read: `The smarts that used to be lacking entirely in VMS are now in the controller.' Unix has always done seek sorting and disk cacheing; the controller's abilities give very little gain here. ----- [1] I have never dealt directly with VMS internals; this is just what I have heard. Feel free to correct any misapprehensions. ----- >I don't know how much the Unix drivers take advantage of the ability >of the controllers (such as the most common UDA-50) to optimize disk >operations. I suspect very little. As much as exists, actually. There are several problems with the UDA50 that make its intelligence virtually useless for Unix. For instance, I believe its cache is a whopping 16KB [2]. In the 4.2BSD file system, that is all of two blocks. Even our memory-poor Sun-3/50s have bigger caches! All the UDA50 drivers I have seen use the multiple-outstanding-I/O- requests feature (which is what tickles the seek sorting in the UDA50). In fact, this is the source of several bugs in the 4.2 driver. To be fair, the 4.2BSD driver was such that it made the UDA50 look worse than it was. ----- [2] It might be 32K. But since the UDA50 uses (I think) an 8086, it is not likely to be any bigger than this. ----- >With smarter and smarter controllers (such as the HSC-[57]0), and >drivers designed to take full advantage of the hardware the RA-81 >(and RA-82) may indeed come into their own. I tend to doubt it however. Indeed. It *would* help, I think, if these things had a real cache (how about 16 *mega*bytes for starters?) and did track-at-a-time transfers into this cache, with dual ported or otherwise fast memory so that the actual block requested goes out as soon as it is in memory, at the same time as the rest of the track dribbles in. But it would also help if the RA81 were an Eagle. (*sigh*) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris