RAM disk.

[A. Lester Buck]

In article <BZS.90Oct9144959 at world.std.com>, bzs at world.std.com (Barry Shein) writes:
> Here's several features that keep coming up. Not all are without
> merit, but some are already there (like RAM disk) and others are
> questionably portable or, well, without merit.

I agree with most of your points, but challenge your comments on
asynchronous I/O.

> 
> 3. Asynchronous I/O for "performance" reasons
> 
> All Unix block I/O is asynchronous (well, driver dependant of course,
> but disks and tapes and so forth.)

This is, of course, incorrect.  Only writes are effectively asynchronous.
Reading can be asynchronous with read ahead and caching, but the effect
is small for high performance input, which is rarely consuming I/O
in chunks of a single block, and that is all that read ahead grabs.
Any process interested in high performance I/O is doing raw reads and
writes to avoid extra buffer copies.  For the numbers, consult
Rochkind, "Advanced Unix Programming".

> The recent addition to Unix has been *synchronous* I/O (FSYNC bit.)
> The one major exception is directory updates, but that's never the
> issue when this comes up.

No objections here, but you are refering to synchrony at a different
point in the I/O system, for reliability from buffer cache to permanent
storage instead of at the user buffer level.

> Another related feature is being able to get an interrupt when an I/O
> has really gone to disk (et al). This has merit and for many
> applications would be vastly superior to the FSYNC bit. I'm not sure
> why this hasn't been done universally as the SIGIO signal could just
> be used for this and it probably only entails marking a bit in the
> buffer and having the kernel issue a psignal() or whatever when the
> right completes and the buffer is being freed. Perhaps I'm missing
> something.

This is a really interesting idea.  A vendor could add this into
POSIX.4 very easily by defining an extra bit in the aio_flag argument
for an asynch request, and the driver would delay the completion
notification until the appropriate level of stable storage had been
reached.  I like it!

I don't see much of an argument here for your initial premise that
asynchronous I/O has no performance benefits.  As a counterexample, I
personally know of at least two database and/or filesystem vendors who
flatly refused to port their products to a major Unix kernel without the OS
vendor adding some form of asynchronous I/O.  When it comes to implementing
real systems where I/O is everything, database vendors know exactly what
they need for performance.

> 4. Command names which resemble english words.
> 
> Bell Labs commissioned independant studies early in Unix's history to
> see if this was important or not. I've tried to locate these, others
> have claimed to have been involved and seen the reports. It's possible
> they were "internal use only", perhaps the work should be repeated.
> 
> The basic conclusion was that you can make commands english, wierd,
> mnemonic, and even counter-intuitive (e.g. "delete" means edit a file,
> "edit" means delete etc.) and it simply doesn't seem to make all that
> much difference to learning curves.
> 
> This may seem horribly counter-intuitive and against all conventional
> wisdom (some people get quite apoplectic when this is asserted, sort
> of like telling them that there is no Santa Claus.)

I hardly get apoplectic, and there are plenty of counterintuitive results
carefully documented in the research literature.  But if this were at all
correct, it would easily generate dozens of papers, theses, and grants.
Until you or someone else can present tangible references, I'm putting this
in my amusing legend category.  Instead, it sounds like a limp coverup for
chosing two letter command names simply because they were faster to type on
ASR-33s.

>         -Barry Shein
> Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs at world.std.com


-- 
A. Lester Buck    buck at siswat.lonestar.org  ...!uhnix1!lobster!siswat!buck