Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!lobster!siswat!buck From: buck@siswat.UUCP (A. Lester Buck) Newsgroups: comp.unix.internals Subject: Re: RAM disk. Message-ID: <563@siswat.UUCP> Date: 17 Oct 90 14:02:30 GMT References: <18560@rpp386.cactus.org> <143359@sun.Eng.Sun.COM> Organization: Photon Graphics, Houston Lines: 83 In article , bzs@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@world.std.com -- A. Lester Buck buck@siswat.lonestar.org ...!uhnix1!lobster!siswat!buck