Dual interface HDDs

And you reading from vastly different parts of the file you're reading from? (Since, if the files are relatively small or you're reading parts not that "far" from what you just wrote, the data should still be in the file cache and it'd be rather surprising to see a huge slowdown.)

I haven't, although I wouldn't be surprised if historically such drives existed. I imagine the problem is that this is a bit of a one-trick pony: As soon as you have more than one reader and one writer, you're back to the same problem and it might end up being more effective, in general, to use multiple drives, a bigger cache, etc.

Perhaps you'd be better served by solid-state (flash) memory? Speeds are getting pretty impressive these days, and they don't have any significant "track to track" latency.

---Joel

Yes. Way back in the 360/370 days IBM had a disk drive series (3880 IIRC) that had 4 head/arm combinations. That guarantees at least 4 read channels and the thing was controlled by an i860 uC/uP (IIRC).

Can't remember the number either (it was often used on the 370/155 but never saw one on a high-end machine), but the 3880 was a disk controller and 3380 the disk drive that went with it. The 3380 was in the 3330/3350/... series and only had a single head per surface; single actuator per pack.

...and well after the 360. It couldn't have been an i860 in a 360 storage device. The 370 series came out in '70 or '71. I *highly* doubt it was any 370 series either, unless you consider the 3090s a /370. IBM tended to use their own microprocessors until at least that era (mid '80s, anyway).

It seems the i860 came out in '89, by which time "paging stores" were history, so...

--
Keith

I rechecked my memory, it was late 1980's to early 1990's. I never did see anything like schematics though, so i cannot be sure. And i think it was attached to a 3090-600J, 4 integer units, one vector unit. (Thus a s/390 class machine, kind of a baby super at the time)

Since the i860 was announced in '89, I sorta doubt it was in a

3090J. As I said, until about then, IBM used their own microprocessors. The 3090s were pretty much all done by '89. I worked in 3090J Crypto Facility (ICRF - replaced the Vector Facility) development at the tail end of the 3090s ('J' only), in '88-89.

--
Keith

The i860 was in the disk drive electronics or disk controller electronics.

I don't believe it, if it came with a 3090. The last 3090 ('J' model) was in design about the same time the i860 was announced (the i860 would have had to have been around a while already). The 3090J was just the final link in the 3090 series and nothing special (except crypto, of course ;-).

--
Keith

When you read and write to the same drive at the same time you have to seek to relocate the head between reads and writes same file or not. You probably also corrupt the file.

Bob

Bob

Your home or business PC does this trick all the time. Do you have terrible problems with data and file system corruption all the time? You are partly right about the seeks, but the real trick is in the seek, read, and write scheduling.

Yes, I've often noticed that file copies (larger than available cache at least) are substantially faster between two different drives than between locations on the same drive.

Seems like it would work. A good on-drive controller should be able to sort things out between the two heads and the cache so it all makes sense, ie, if one head is asked to read what the other is currently writing, you'll just get the data out of cache instead of having to write and then read it back.