Replacement for NFS with write caching
John F Haugh II
>So, I think the problem that still remains is like so: we have
>server S, client C1, and client C2. As time goes by:
>
> C1: write block 0 of file
> C2: write block 0 of file
>
>There is no way to know which write gets to S first. If this is what
>you guys are complaining about (and I think it is) then get a grip.
Go re-read your Bach and Leffler. Both =clearly= state that the inode
of a file is locked during the entire update to the file. I posted the
relevant page numbers in another article, so I won't re-lookup the pages
again.
C1 and C2 may have very good reason to do exactly what was just described
and may require (perhaps block 0 contains file layout information)
precise ordering.
NFS does =not= have reliable file locking, either in the sense that you
will always have file locking present, or even that if file locking is
present that it will work.
>You clearly haven't thought through the implications of your complaint.
>You are clearly being lazy about programming. Use locking, it exists
>for this sort of problem. You have the same problem on a local machine:
>
> P1: map in block 0 of file
> P2: map in block 0 of file
> P1: write on mapping
> P2: write on mapping
One of the people who was porting some of my software to an Ultrix machine
running NFS reported that file locking was broken and that as a result he
was forced to run the software with no file locking. This is part of the
problem and has nothing to do with Boyd or I being lazy.
--
John F. Haugh II | Every 56 days. | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151 | Give Blood, often. | Domain: j...@rpp386.cactus.org
SigVirusGuard 1.2: Stops the Michealangelo Virus! [ offer expires 5 March 92 ]
Larry McVoy
: In article <kqvvnn...@appserv.Eng.Sun.COM> l...@slovax.Eng.Sun.COM (Larry McVoy) writes:
: >So, I think the problem that still remains is like so: we have
: >server S, client C1, and client C2. As time goes by:
: >
: > C1: write block 0 of file
: > C2: write block 0 of file
: >
: >There is no way to know which write gets to S first. If this is what
: >you guys are complaining about (and I think it is) then get a grip.
:
: Go re-read your Bach and Leffler. Both =clearly= state that the inode
: of a file is locked during the entire update to the file. I posted the
: relevant page numbers in another article, so I won't re-lookup the pages
: again.
Yeah? So what? Your client apps are running on different machines.
You can't expect that stuff to be consistent w/o any indication that
that is what you want. Don't believe me? OK, go look at all the
cache consistency stuff that SMP's do. Go understand the scaling
problems with that. Then tell me how cache consistency with file
systems is any different (it isn't). Then come back and tell me
that you want all the traffic floating around your network every
time somebody updates some shared directory or file.
I predict that when we have consistency at the distributed file system
level you will see the consistency constraints relxed such that the app
has to tell the system "I want it safe now". This is certainly the
trend in MP machines, file systems will follow.
In summary, what you are asking for isn't reasonable unless you tell
the system that you want it. You won't get it by default in the real
world. At least, I don't think you will. If you want local file
semantics then don't use a remote file system. If you think it is easy
to fix NFS, please write up a nice proposal, get all the vendors to
agree that your problems are their problems (in writing, thank you) and
send on to me. If you can the vendors to agree then I can get Sun to
do something with it.
: NFS does =not= have reliable file locking, either in the sense that you
: will always have file locking present, or even that if file locking is
: present that it will work.
Nice summary. The first point is something you will never get in NFS.
The second point is worth a boat load of flames (point that at Sun in
forms of bug reports). Actually, if you do have failing test cases,
please do submit a bug.
A question: how many of you have used the VMS lock manager? Did you
like it? If the NFS lock manager worked, do you like it or the VMS
one better?
---
Larry McVoy (415) 336-7627 l...@sun.com
peter da silva
> : Go re-read your Bach and Leffler. Both =clearly= state that the inode
> : of a file is locked during the entire update to the file. I posted the
> : relevant page numbers in another article, so I won't re-lookup the pages
> : again.
> Yeah? So what? Your client apps are running on different machines.
Yeah? So what? Client one says "start write <n> bytes". Server says "OK".
Client two says "start write <n> bytes". Server says "hold on, it's locked".
Client one writes the data. Server says "OK, got it". Server says "OK,
client two, go ahead". Client two writes *its* data.
You can't do this with a stateless server, of course. That's where most of
the problems with NFS arise... it's got a fundamental design flaw.
> You can't expect that stuff to be consistent w/o any indication that
> that is what you want.
You have an indication: the size parameter passed to the "write" system call
by the application.
--
-- Peter da Silva, Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"
Marcus J. OpenRanum
>The funny thing is that the people that are complaining about NFS
>really don't understand what they are asking. Cache consistency
>is a well known problem, in file systems and memory systems.
It's just a matter of design, Larry. Some people think that
NFS should behave like a distributed database, with none of the
performance loss inherent in doing distributed cache consistency.
After all, distributed cache consistency *IS* do-able - but then
nobody would use NFS if they saw how slow the results were.
If you need transactions and consistency, put transactions
and locking in your application and let your application be a dog.
Don't inflict doglike performance on everyone across the board
by building it into your file systems' guts.
mjr.
--
This is your code.
This is your code under POSIX.
Any questions?
- notebooks of a heretic.
Marcus J. OpenRanum
>I'll ask again: has anyone used the VMS lock manager and did they like
>it?
Anyone who is using VMS in a cluster is using the VMS lock
manager, and if they're a happy cluster user, they can be said to
like it. It's an impressive piece of work.
I don't like the VMS command interface (all the '/option'
stuff makes me break out in hives) but UNIX could learn an awful lot
from looking at how VAX clusters work. There's a degree of functionality
there that UNIX doesn't even come close to matching. It's a shame it's
all hammered into the VMS "kernel" rather than being a nice portable
application layer, but - that's VMS for you.
Let me phrase it differently - could *YOU* sell UNIX more
machines if they had VMS-like available file systems and clustering?
I know we could. :)
Larry McVoy
: > : Go re-read your Bach and Leffler. Both =clearly= state that the inode
: > : of a file is locked during the entire update to the file. I posted the
: > : relevant page numbers in another article, so I won't re-lookup the pages
: > : again.
:
: > Yeah? So what? Your client apps are running on different machines.
:
: Yeah? So what? Client one says "start write <n> bytes". Server says "OK".
: Client two says "start write <n> bytes". Server says "hold on, it's locked".
: Client one writes the data. Server says "OK, got it". Server says "OK,
: client two, go ahead". Client two writes *its* data.
:
: You can't do this with a stateless server, of course. That's where most of
: the problems with NFS arise... it's got a fundamental design flaw.
Excuse me? What you have described is *exactly* what happens. NFS
just calls into UFS, which you seem to think has the "right"
semantics. The locking that you want happens when NFS calls over to
UFS to do the IO. If two IO's happen to the same NFS server to the
same page of the same file, they will be serialized just like the local
file system because they are going to a file system which happens to be
the same code as the local file system.
So tell me again how you understand the system well enough to point out
that "fundamental design flaw" again?
: > You can't expect that stuff to be consistent w/o any indication that
: > that is what you want.
:
: You have an indication: the size parameter passed to the "write" system call
: by the application.
Gimme a break. What you are complaining about is silly. It is like
saying "my system crashed but my write had already returned, it is a
fundamental design flaw that it wasn't the disk". Writes are done
async locally for performance. Everyone knows it, the do O_SYNC when
they care. Why is it so hard to expect people to do locking when they
care about the interaction of IO from two different clients?
The funny thing is that the people that are complaining about NFS
really don't understand what they are asking. Cache consistency
is a well known problem, in file systems and memory systems. What
we are talking about here is analogous to processor caches that are
inconsistent. Consider what has happened when people have tried
to make systems that are cache consistent. They don't scale up
because all those cache consistency chips are busy transfering useless
data back and forth across the bus, all in the name of consistency.
Yet any hardware or software architect can tell you that only about
1% of the memory references need to be consistent - the rest are
all noise.
Making cache consistency work without making your network go nuts is a
hard problem. I'm quite willing to have a discussion with the people
that think they understand this problem and have suggestions as to how
it should be done. But please be sure you understand what it is you
are asking for - you might get it.
John F Haugh II
>Hmm isn't this the scenario:
>
> client | server
>--------------------------------------------------------------
> rename request |
> | process rename
> | positive ack
> positive ack dropped
> rename request re-xmit |
> | process rename
> | negative ack ENOENT
> rename errors |
I did want to address this. You can provide error detection and recovery
in this case and others - just check for successful completion of the
request. I use
if (link fails)
stat source file
stat target file
if the source and target are different
fail for real
the link worked OK
to resolve some (like this particular one) NFS errors and haven't had
any complaints.
Boyd Roberts
> Because there isn't any locking primitive that works reliably and
> correctly over NFS? Using link(2) is, I claim, as close as you can get,
> but Vern insists that even link can work incorrectly over NFS; he's seen
> it happen, I haven't.
Hmm isn't this the scenario:
client | server
--------------------------------------------------------------
rename request |
| process rename
|
| positive ack
|
|
|
positive ack dropped
|
|
rename request re-xmit |
|
| process rename
|
| negative ack ENOENT
|
rename errors |
There was a paper at a UKUUG or EUUG on just this. It was either
Jim Reid or Charles Forsyth (I can never remember which).
Boyd Roberts bo...@prl.dec.com
``When the going gets wierd, the weird turn pro...''
John F Haugh II
>I'll ask again: has anyone used the VMS lock manager and did they like
>it. It seems to me that Sun could supply the VMS style lock manager,
>then we get Oracle to work on our platforms and everyone gets a lock
>manager that works.
The worst file locking bugs on some code I wrote were reported by
a user running Ultrix. Somehow I doubt that the lock manager was
written by DEC, unless there is still the anti-UNIX conspiracy group
working at DEC ...
Jim Reid
Because there isn't any locking primitive that works reliably and
correctly over NFS? Using link(2) is, I claim, as close as you can get,
but Vern insists that even link can work incorrectly over NFS; he's seen
it happen, I haven't.
I've not seen this personally, but others have. Firstly, all the
client and server attribute cacheing can mean that a few seconds can
elapse between a client creating a new directory and another client
seeing that entry (i.e. the lock file).
I have been told by a friend that he has seen NFS link requests
failing EEXIST, when the link was made successfully. The server makes
the link and sends a successful reply to the client which gets lost.
The client then repeats the request when it times out and then gets
the EEXIST error, because the link is already there and the server was
too dumb to detect a retransmitted request!
Jim
Larry McVoy
say. I think I was too inflammatory for people to have heard me.
Please read Marcus' message carefully, understand it, and you'll
understand my frustration with people that want everything but are
willing to pay for nothing.
m...@hussar.dco.dec.com (Marcus J. OpenRanum) writes:
: l...@slovax.Eng.Sun.COM (Larry McVoy) writes:
:
: >The funny thing is that the people that are complaining about NFS
: >really don't understand what they are asking. Cache consistency
: >is a well known problem, in file systems and memory systems.
:
: It's just a matter of design, Larry. Some people think that
: NFS should behave like a distributed database, with none of the
: performance loss inherent in doing distributed cache consistency.
: After all, distributed cache consistency *IS* do-able - but then
: nobody would use NFS if they saw how slow the results were.
:
: If you need transactions and consistency, put transactions
: and locking in your application and let your application be a dog.
: Don't inflict doglike performance on everyone across the board
: by building it into your file systems' guts.
John F Haugh II
>Because there isn't any locking primitive that works reliably and
>correctly over NFS? Using link(2) is, I claim, as close as you can get,
>but Vern insists that even link can work incorrectly over NFS; he's seen
>it happen, I haven't.
I've seen unlink fail, but only in bizarre cases that have nothing to
do with a typical locking implementation (the one where the existence
of the file indicates a lock is present). I've also seen creat fail,
but again, that was a strange situation. So I'd be inclined to believe
that link can fail incorrectly under NFS and will see if I can come
up with a testcase next time I care about it ...
Marcus J. OpenRanum
>Because there isn't any locking primitive that works reliably and
>correctly over NFS?
That's because it's a hard problem.
If you need reliable distributed locking, you need something that
insanely complex and egregiously stateful (like VMS' lock manager) and
that chews on your network. If you need reliable distributed locking for
NFS - goforit. NFS is adequate for its purposes but should not be mistaken
for a distributed filesystem or database.
Someone ought to take a good look at how VMS does this stuff and
consider something similar for UNIX. There are some Damn Clever Ideas
in how VAXclusters do thier thing, and it performs very well, considering
the level of functionality they provide. If I recall, it took a while to
get VAXclusters working right and working fast - people who bust on NFS
should remember it's not exactly a weekend hack to do distributed locking.
Geoff Collyer
>OK, I can buy this. File a bug. Scream at your vendor.
Very funny. If Sun keeps track of bug reports, I believe you'll find a
few filed from UUNET in May 1991 regarding rpc.lockd. In any case, due
to years of bad experience, I've given up on expecting Sun to fix bugs
just because they are real, reproducible and reported. If I resubmit the
bug reports, can you get someone to actually *fix* the bugs and tell me
when they have done so and what the patch is called? Barring that, can
you get me the rpc.lockd source and a commitment to buy back the fixes if
*I* fix it (I make no promises; I hate RPC programming)?
>This is a valid complaint - they should fix it.
Indeed they should. I'm waiting...
>It sounds good to me but nobody seems to want to pipe up that it really
>is good. Does that mean nobody cares or does it mean that people are
>having too much fun flaming to do anything real? Yeah, I know, cheap
>shot.
Look, most people think locking is a nuisance, at best, and that if
link(2) just worked reliably over NFS, we could then completely ignore
lockf, which is what we want to do. However, if lockf actually worked
over NFS, we could probably be persauded to use it. But I don't think
anybody is going to jump up and down cheering "Rock 'em, Sock 'em, Lock'
em!"; locking is just a grungy detail that has to be done correctly. And
it currently isn't, at least over NFS. So we tend to feel defeated.
To add insult to injury, Sun as a corporation seems lethargic about
making lockf work over NFS and now we are being told that we need to be
cheerleaders to get anything fixed. Call me a cynic but Sun seems to
have excuses for every occasion, take your pick: (1) `well, gee, we're
just growing *so* fast, we don't have to time to deal with your problem',
(2) `well, gee, you users just don't seem to care about this problem:
after we rejected, refused or threw away all the bug reports you
submitted, we couldn't find any complaints from you', (3) `golly, gee, we
fixed 250 whole entire bugs in this new major release [we won't tell you
how many we introduced]'.
Okay, I know that the number of competent people in the valley is a small
constant and they just move from company to company, so you're stuck with
a bunch of stumble bums who keep their chairs warm and can fog a mirror
in a pinch. I don't know what to suggest. Maybe hire Henry Spencer at
$1M per year (which would be cheap) and give him authority to fire anyone
in the company at his discretion (I'd suggest that he start with
management). Maybe stick to building hardware, which Sun has had some
success at. Don't pin your future on being a software company.
Sorry for the prolonged flame; I hadn't realised when I started writing
just how fed up with Sun I am.
--
Geoff Collyer world.std.com!geoff, uunet.uu.net!geoff
Larry McVoy
complaint - they should fix it. Apparently nobody cares - I asked about
locking in one of these groups recently and didn't get any response.
I'll ask again: has anyone used the VMS lock manager and did they like
it? It's what Oracle uses and Oracle insists that the vendor supplies
it. It seems to me that Sun could supply the VMS style lock manager,
then we get Oracle to work on our platforms and everyone gets a lock
manager that works. It sounds good to me but nobody seems to want to
pipe up that it really is good. Does that mean nobody cares or does it
mean that people are having too much fun flaming to do anything real?
Yeah, I know, cheap shot.
: >Why is it so hard to expect people to do locking when they care about
: >the interaction of IO from two different clients?
:
: Because there isn't any locking primitive that works reliably and
: correctly over NFS? Using link(2) is, I claim, as close as you can get,
: but Vern insists that even link can work incorrectly over NFS; he's seen
: it happen, I haven't.
: --
: Geoff Collyer world.std.com!geoff, uunet.uu.net!geoff
Geoff Collyer
>Why is it so hard to expect people to do locking when they care about
>the interaction of IO from two different clients?
Because there isn't any locking primitive that works reliably and
Larry McVoy
DEC's OS is broken in this respect but Sun was pretty careful. Sun's
NFS has code to prevent this. There is a cache of non-idempotent
operations, such as rename/link/unlink, and the situation described
below is prevented by this cache. From the code in rfs_dispatch()
/*
* Request caching: throw all duplicate requests away while in
* progress. The final response for non-idempotent requests is
* stored for re-sending the reply, so that non-idempotent requests
* are not re-done (until the cache rolls over).
* A 'ressz' of 0 distinguishes idempotent req's from non-idempotent
* req's that we save results for (ugly).
*/
...
/*
* non-idempotent requests
*/
case RFS_SETATTR:
case RFS_WRITE:
case RFS_REMOVE:
case RFS_RENAME:
case RFS_LINK:
case RFS_SYMLINK:
case RFS_RMDIR:
case RFS_CREATE:
case RFS_MKDIR:
Note that there is a case where this can happen. In the scenario below
if the reply didn't make it to the client because the server crashed,
the client code be retransmitting when the server comes back up. In
that case, the client will indeed get the incorrect error return
because the cache of requests is memory based. I've often wondered if
it would be worth it to stash the cache away on disk but decided no
because of the performance implications. Comments?
j...@cs.strath.ac.uk (Jim Reid) writes:
Richard Tobin
>I've often wondered if it would be worth it to stash the
To do this would be to abandon statelessness, so you might as well
improve the protocol to fix the other problems resulting from
statelessness. In particular you could record which files clients
have open, and provide the normal unix semantics for unlink().
-- Richard
--
Richard Tobin,
AI Applications Institute, R.T...@ed.ac.uk
Edinburgh University.
Robert Thurlow
>In article <krgbgl...@appserv.Eng.Sun.COM> l...@slovax.Eng.Sun.COM (Larry McVoy) writes:
>>I'll ask again: has anyone used the VMS lock manager and did they like
>>it? It's what Oracle uses and Oracle insists that the vendor supplies
>>it. It seems to me that Sun could supply the VMS style lock manager,
>>then we get Oracle to work on our platforms and everyone gets a lock
>>manager that works.
>The worst file locking bugs on some code I wrote were reported by
>a user running Ultrix. Somehow I doubt that the lock manager was
>written by DEC, unless there is still the anti-UNIX conspiracy group
>working at DEC ...
Why is the Ultrix lock manager relevant here? I think it is Sun code,
almost unchanged. The VMS lock technology likely wouldn't ever help
Ultrix.
Rob T
--
Rob Thurlow, thu...@convex.com
Recent poll results show that more Canadians believe that Elvis Presley
is alive than would vote for the current Prime Minister, Brian Mulroney.
Robert Thurlow
>Note that there is a case where this can happen. In the scenario below
>if the reply didn't make it to the client because the server crashed,
>the client code be retransmitting when the server comes back up. In
>that case, the client will indeed get the incorrect error return
>because the cache of requests is memory based. I've often wondered if
>it would be worth it to stash the cache away on disk but decided no
>because of the performance implications. Comments?
I always thought the cure would be worse than the disease, too. If you
want to guarantee 100% reliability, it usually costs you like hell, but
you can get to 99.9% much more cheaply.
Robert Thurlow
>Hmm isn't this the scenario:
> client | server
>--------------------------------------------------------------
> rename request |
> | process rename
> |
> | positive ack
> |
> |
> |
> positive ack dropped
> |
> |
> rename request re-xmit |
> |
> | process rename
> |
> | negative ack ENOENT
> |
> rename errors |
This is why the current state-of-the-art is to implement a duplicate
request cache. Sun 4.1* encaches the responses and sends them back
when it notices duplicate requests, and the code isn't bad. I think
any vendor not doing this at this point should probably get beat up
a little by its users. Does it break statelessness? A little, in
what I've always thought was breaking the letter but not the spirit
of statelessness. It isn't "expensive state", which would call for
protocol overhead to get everyone back into state.
John F Haugh II
>In <20...@rpp386.cactus.org> j...@rpp386.cactus.org (John F Haugh II) writes:
>>The worst file locking bugs on some code I wrote were reported by
>>a user running Ultrix. Somehow I doubt that the lock manager was
>>written by DEC, unless there is still the anti-UNIX conspiracy group
>>working at DEC ...
>
>Why is the Ultrix lock manager relevant here? I think it is Sun code,
>almost unchanged. The VMS lock technology likely wouldn't ever help
>Ultrix.
Since Larry McVoy also sent me a note about this one, obviously it isn't
completely clear.
VMS and Ultrix are both from the same company, DEC. The Ultrix lock
manager caused the most problems for some database code I wrote
recently. One would think that if DEC had written the VMS lock
manager (or cared about file locking on Ultrix) that some of that
expertice would rub off on the Ultrix group. However, IMHO, it appears
that DEC does not care about NFS file locking well enough to insure
that their Ultrix lock manager works correctly. Either there is a
conspiracy to make Ultrix look bad in this regard, or DEC didn't write
the VMS lock manager. This is all just conjecture, etc.
I think it is immaterial that the code is from Sun - if I were Ken
Olsen, I'd make certain MY employees tested the code they were selling
to my customers (lest there be an anti-DEC conspiracy underfoot at
Sun ;-)
--
John F. Haugh II | Every 56 days. | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151 | Give Blood, often. | Domain: j...@rpp386.cactus.org
"A countryman between two lawyers is like a fish between two cats."
-- Benjamin Franklin
Robert Thurlow
>VMS and Ultrix are both from the same company, DEC. The Ultrix lock
>manager caused the most problems for some database code I wrote
>recently. One would think that if DEC had written the VMS lock
>manager (or cared about file locking on Ultrix) that some of that
>expertice would rub off on the Ultrix group. However, IMHO, it appears
>that DEC does not care about NFS file locking well enough to insure
>that their Ultrix lock manager works correctly. Either there is a
>conspiracy to make Ultrix look bad in this regard, or DEC didn't write
>the VMS lock manager. This is all just conjecture, etc.
Given that there is probably no similarity between the over-the-wire
protocols and little similarity in the internals of the two lock
managers, and that each (particularly the VMS lock manager) are
likely to be very dependant on the features of the surrounding OS,
I think your expectations that expertise would "rub off" are quite
unrealistic. I frankly doubt a VMS guru would be any help until he'd
been working with the ONC stuff for quite some time. He might be
able to design a good test suite, but that's not going to get the
bugs _fixed_. I look no further than Sun for my villains in the
case of the lock manager.
>I think it is immaterial that the code is from Sun - if I were Ken
>Olsen, I'd make certain MY employees tested the code they were selling
>to my customers (lest there be an anti-DEC conspiracy underfoot at
>Sun ;-)
Remember that every person you throw on a project is one that you can't
use on another one. The Sun lock manager was likely just supposed to
be a simple port at first. I'm not sure it would be justifiable at
many companies to devote more effort to a port than to stuff they wrote
from scratch (and don't have to pay royalties on). Some companies have
picked up a Really Big Hammer and swung it at the lock manager (e.g.
Data General and MIPS), but they've done it because they have no other
lock manager to support and need this one to _work_. I think DEC's
committment to Unix has always been in question, so I'd be even more
surprised if they took ownership of the lock manager and fixed it all
the way. In some ways, Unix and NFS are just a checklist item for DEC
to be able sell machines into VMS-hostile markets.
Larry McVoy
crowd. The ultrix lock manager has nothing to do with the VMS lock
manager. The VMS lock manager was motivated by the DEC VaxCluster,
one of the few genuinely useful distributed systems ever productized.
You should really give credit to technological and business progress,
rather then conjecturing about hidden agendas, etc.
j...@rpp386.cactus.org (John F Haugh II) writes:
: VMS and Ultrix are both from the same company, DEC. The Ultrix lock
: manager caused the most problems for some database code I wrote
: recently. One would think that if DEC had written the VMS lock
: manager (or cared about file locking on Ultrix) that some of that
: expertice would rub off on the Ultrix group. However, IMHO, it appears
: that DEC does not care about NFS file locking well enough to insure
: that their Ultrix lock manager works correctly. Either there is a
: conspiracy to make Ultrix look bad in this regard, or DEC didn't write
: the VMS lock manager. This is all just conjecture, etc.
Marcus J. OpenRanum
>VMS and Ultrix are both from the same company, DEC. The Ultrix lock
>manager caused the most problems for some database code I wrote
>recently. One would think that if DEC had written the VMS lock
>manager (or cared about file locking on Ultrix) that some of that
>expertice would rub off on the Ultrix group. However, IMHO, it appears
>that DEC does not care about NFS file locking well enough to insure
>that their Ultrix lock manager works correctly. Either there is a
>conspiracy to make Ultrix look bad in this regard, or DEC didn't write
>the VMS lock manager. This is all just conjecture, etc.
That's pretty dumb logic, really. What's your point?
The ULTRIX lock manager is from Sun code that we license. No
doubt it's from some "reference port" that may or may not have all
the latest and greatest bug fixes from Sun. The VMS lock manager
was written by an entirely different group of people (unless they
quit and went to Sun and wrote lockd manager there?) working
under an entirely different set of constraints. I'm sure if they'd
written NFS it'd look like VAXclusters, or something. ;)
This is a pointless and rather sophmoric bash, really. The
line about "either there is a conspiracy || DEC didn't write"
is especially cute ("have you stopped beating your wife?") - it's
almost up to USENET standards.
Did you get a fixed version of lockd? Or are you just venting
your spleen? (I see extant patches for lockd in both 4.2 and 4.2a)
mjr.
--
Theoretical computer scientist: about as useful as a theoretical
ditch-digger, but more widely published.
Marcus J. OpenRanum
>I look no further than Sun for my villains in the
>case of the lock manager.
[...]
>I think DEC's
>committment to Unix has always been in question, so I'd be even more
>surprised if they took ownership of the lock manager and fixed it all
>the way.
Hang on a second. On one hand you say you point the finger at
Sun for lockd stupidities and on the other hand you kick us in the
shins for not fixing it and making it right? Yeah, I guess that makes
sense of a sort, but I'd be surprised that someone who has worked for
a vendor and been around as long as you have wouldn't understand
that in any engineering organization, you can't tackle all the
problems all the time. Maybe DEC decided not to rewrite Sun's
broken lock manager for them, maybe we committed those resources
elsewhere - I'm not privy to those decisions.
I think you're not being realistic (unless this is just
a gratuitious bash, in which case, please prefix it as such and
we can all just yawn and let it slide) or you're ignoring or
pretending to ignore the tradeoffs that all vendors face in order
to get a product out the door. You can bet for example that if it's
a question of fixing lockd or putting resources on adding kernel
support for new hardware, the new hardware will win.
> In some ways, Unix and NFS are just a checklist item for DEC
>to be able sell machines into VMS-hostile markets.
This is a patently silly remark when you look at the huge amount
of resources and money Digital has invested in and continues to commit
towards our UNIX strategy. If UNIX was a "checklist item", we wouldn't
be going to the tremendous effort we've been going to, to get OSF/1 to
become a standardized platform across all our architectures - we'd just
use ULTRIX as a "checklist item" and save the effort. If NFS was a
"checklist item" we wouldn't do stuff like engineer on-CPU NVRAM to
support NFS, and we wouldn't invest the time to add kernel support
for it.
We may not always be winning, but you're a bald-faced liar if
you're going to stand there and say we're not competing. (as much as
anyone can "stand" on the net).
mjr.
PS-
Heck, for that matter, if UNIX was a "checklist item", I'd
have expected all us UNIX folks to be gone in the layoff - we're still
here, and we're still kicking.
Marcus J. OpenRanum
>DEC wrote the VMS lock manager. It was the VMS crowd, not the ultrix
>crowd. The ultrix lock manager has nothing to do with the VMS lock
>manager. The VMS lock manager was motivated by the DEC VaxCluster,
>one of the few genuinely useful distributed systems ever productized.
You bet.
I tell you this, if VAXClustering technology had been available
for UNIX, nobody'd even know what this 'NFS' thing is.
mjr.
PS -
(And to forestall the inevitable "poking DEC with pointed sticks"
responses: the fact that is *doesn't* exist for UNIX doesn't mean jack
about "DEC's commitment to UNIX" - it's because VAXClustering makes
such use of VMS services and functionality that in order to make it
work for UNIX, it would be VMS by the time you were done - then we'd be
back to being bashed for tying to only sell VMS, I suppose... ;) )
John F Haugh II
> This is a pointless and rather sophmoric bash, really. The
>line about "either there is a conspiracy || DEC didn't write"
>is especially cute ("have you stopped beating your wife?") - it's
>almost up to USENET standards.
It was meant to be up to USENET standards ;-)
> Did you get a fixed version of lockd? Or are you just venting
>your spleen? (I see extant patches for lockd in both 4.2 and 4.2a)
Spleen venting. I've always preferred VAX/VMS to UNIX. The former
was written by professionals intent on making money, while the latter
includes large amounts of code written by college students.
[ Now is THAT up to USENET standards? ]
Marcus J. OpenRanum
>Spleen venting. I've always preferred VAX/VMS to UNIX.
Perhaps this is the first clearly documented case of "post lockd
stress disorder"[1][2]. ;) I wonder if I could get published in JAMA..?
mjr.
[1] Dr. Miso Katz, "An epedemic of POSIX-related stress," JAMA, 1991
[2] Dr. Miso Katz, "Tty driver considered in treating the incurably
insane," NEJM, Jul, 1991
Robert Thurlow
>thu...@convex.com (Robert Thurlow) writes:
>>I look no further than Sun for my villains in the
>>case of the lock manager.
>[...]
>>I think DEC's
>>committment to Unix has always been in question, so I'd be even more
>>surprised if they took ownership of the lock manager and fixed it all
>>the way.
> Hang on a second. On one hand you say you point the finger at
>Sun for lockd stupidities and on the other hand you kick us in the
>shins for not fixing it and making it right?
No Marcus, I wasn't trying to kick you in the shins with that second
comment, I was just saying that I would have been astonished if DEC
had taken on the job of fixing the lock manager. It didn't come out
as very complimentary, I agree, but I was in fact trying to say that
it wouldn't make sense for DEC to put 100% effort into fixing 3rd
party cruft rather than homemade stuff.
>> In some ways, Unix and NFS are just a checklist item for DEC
>>to be able sell machines into VMS-hostile markets.
> This is a patently silly remark when you look at the huge amount
>of resources and money Digital has invested in and continues to commit
>towards our UNIX strategy.
Well, I will back off a bit. But your Unix story is hurt by the fact
that the newest iron (e.g. the VAX 9000, the Alpha) never runs Ultrix
until several months after it runs VMS. DEC is stating its priorities
with every machine announcement.
> We may not always be winning, but you're a bald-faced liar if
>you're going to stand there and say we're not competing. (as much as
>anyone can "stand" on the net).
But you can't stand there ans say that Ultrix isn't a few notches less
important to DEC than VMS. IMHO, DEC would be crazy to do anything
different, too; I think I'd do the same under the circumstances.
Marcus, I'm sorry for the tone of the previous message. It didn't
do anyone any good.
Marcus J. OpenRanum
>Well, I will back off a bit. But your Unix story is hurt by the fact
>that the newest iron (e.g. the VAX 9000, the Alpha) never runs Ultrix
>until several months after it runs VMS. DEC is stating its priorities
>with every machine announcement.
Well, a lot of us inside the company feel a great deal of real
progress has been made (and some of us are touchy about it, as you may
notice ;) ) For example, Alpha *is* going to initially ship running
either OSF/1 or VMS. The hardware has no VMS support wired in, and there
is not difference between an Alpha OSF and an Alpha VMS box other than
what you boot on it.
I think that's progress. And, like you say, I think that DEC
is stating its priorities with every machine announcement. The Alpha
announcements show that DEC's priority is to sell cutting edge iron
with whatever operating system our customers want.
>But you can't stand there ans say that Ultrix isn't a few notches less
>important to DEC than VMS. IMHO, DEC would be crazy to do anything
>different, too; I think I'd do the same under the circumstances.
I have been told and believe in fact that software-wise we
are spending on par between VMS and UNIX. Right now, of course, we
are plowing lots of effort into OSF/1. We have a group that is
engineering VAXes (the 4000 is a hell of a quick machine for CISC!)
and we have a group that is engineering MIPS boxes and another doing
Alpha. We're big. We're big enough that inside we're like competing
little companies in separate areas - the fact that Digital is
puttig the effort into UNIX and hardware specifically for UNIX (the
MIPS line) shows that there's at least an awareness at the top
that this is a place where we should compete. The fact that we
are shipping Alpha with OSF/1 or VMS from day one indicates that
*someone* has realized that we can do well in the UNIX arena
with a machine like the Alpha.
>Marcus, I'm sorry for the tone of the previous message. It didn't
>do anyone any good.
I didn't take it personally - and I didn't mean my reply
personally, but I just couldn't let that slide by without at least
making a few rebuttals. ;)
mjr.
Robert Thurlow
>Well, I will back off a bit. But your Unix story is hurt by the fact
>that the newest iron (e.g. the VAX 9000, the Alpha) never runs Ultrix
>until several months after it runs VMS. DEC is stating its priorities
>with every machine announcement.
Two updates: first, I meant OSF/1 above, not Ultrix. Second, Guy Harris
informs me that my information about shipping Alpha VMS at year-end and
Alpha OSF/1 in mid-1993 may be dated. Sorry for the misinformation on
both counts.
Greg Pavlov
>
> Well, I will back off a bit. But your Unix story is hurt by the fact
> that the newest iron (e.g. the VAX 9000, the Alpha) never runs Ultrix
> until several months after it runs VMS. DEC is stating its priorities
> with every machine announcement.
>
Alpha, if HP is any indication. E.g., when HP announced PA-RISC, the
message was MPE first, HP-UX second: I assume HP wanted to show commitment
to its installed base. But something happened on the way to implementation:
HP-UX was up and running and purchasable on PA-RISC a long time before the
MPE version.
So if one does come before the other, I would expect to see OSF/1 first.
Then again, DEC is not going to the extremes of compatibility that HP did.
>
> But you can't stand there ans say that Ultrix isn't a few notches less
> important to DEC than VMS. IMHO, DEC would be crazy to do anything
> different, too; I think I'd do the same under the circumstances.
>
As has been pointed out to me - correctly - in the past, DEC is not a
monolithic organization. And since I assume that the top management's
primary concern is making money AND since I also assume that DEC will not
be able to differentiate price-wise as much as it has in the past (VMS
is in competition with other OSs, particularly at the lower end and work-
station level), I think that the VMS vs UNIX stratifications/infighting
will gradually fade away.
greg pavlov
pav...@karloff.fstrf.org
Fletcher Kittredge
[Various whining about the DEC lockd and late date for OSF/1]
Robert;
No vendor's lockd works: not Sun's, not HP's not DEC's nor IBM's.
My guess is that lockd will never have acceptable performance. We ended up
writing our own. Picking on DEC because lockd doesn't work is gratuitous
violence, bystander bashing. Why don't you go pick on the architects of NFS?
Your statements about release dates for OSF/1 are analogous. If you
have been following developments at all, you would be aware of the magnitude
of the task of releasing an *integrated* OSF/1. As someone who develops
serious applications for Unix and has for the past year been running various
vendor's OSF/1 internal releases, I can tell you that the loud message we
have been sending DEC and others is "don't release OSF/1 until it is completely
integrated with your current Unix offering and *don't* release a buggy OS".
These two tasks are large and probably are the significant factor for releasing
OSF/1 on the Alpha chip, not marketing reasons.
regards,
fletcher
/* Fletcher Kittredge
* BBN Software Products
* 150 CambridgePark Dr, Cambridge, MA. 02140
* 617-USE-FINK / fkit...@bbn.com / fkit...@das.harvard.edu
*/
Robert Thurlow
> No vendor's lockd works: not Sun's, not HP's not DEC's nor IBM's.
>My guess is that lockd will never have acceptable performance. We ended up
>writing our own. Picking on DEC because lockd doesn't work is gratuitous
>violence, bystander bashing. Why don't you go pick on the architects of NFS?
If you've read my postings since this one, you'll know that my point
was that the problem was not with DEC. I was trying to illustrate that
I would not expect DEC to be the first company that set out to fix bugs
they inherited from Sun. I was also trying to offset John Haugh's
"DEC folks are gods, so why haven't _they_ unilaterally fixed locking?"
comments.
> Your statements about release dates for OSF/1 are analogous. If you
>have been following developments at all, you would be aware of the magnitude
>of the task of releasing an *integrated* OSF/1. As someone who develops
>serious applications for Unix and has for the past year been running various
>vendor's OSF/1 internal releases, I can tell you that the loud message we
>have been sending DEC and others is "don't release OSF/1 until it is completely
>integrated with your current Unix offering and *don't* release a buggy OS".
>These two tasks are large and probably are the significant factor for releasing
>OSF/1 on the Alpha chip, not marketing reasons.
I have been told that OSF/1 will be out contemporaneously with VMS,
which is contrary to the information I had when I wrote the message.
It also kinda undoes your comments.
John F Haugh II
> "DEC folks are gods, so why haven't _they_ unilaterally fixed locking?"
> comments.
Since I did not make this statement, I would like it if you would not
attribute quotes to me that I did not make.
My comments do not have anything to do with the overall bugginess of
NFS, to the contrary they have to do with DEC releasing a lockd which
doesn't even perform the mis-function that lockd is supposed to do
correctly. There is a difference between saying that DEC should fix
something that was designed broken, and saying that DEC should ship a
product which conforms to that broken design. You are implying that
I stated that former, while I actually stated the later.
Robert Thurlow
>My comments do not have anything to do with the overall bugginess of
>NFS, to the contrary they have to do with DEC releasing a lockd which
>doesn't even perform the mis-function that lockd is supposed to do
>correctly.
Are you saying that DEC's implementation is more broken than Sun's?
If so, do tell, because you certainly didn't say so in any manner
I could detect before.
Snoopy
| Why don't you go pick on the architects of NFS?
NFS had architects?
_____
/_____\ Snoopy
/_______\
|___| cse.ogi.edu!sopwith!snoopy
|___| {ares,illian,loop,parsely,qiclab,sequent,techbook}!sopwith!snoopy
John F Haugh II
>>My comments do not have anything to do with the overall bugginess of
>>NFS, to the contrary they have to do with DEC releasing a lockd which
>>doesn't even perform the mis-function that lockd is supposed to do
>>correctly.
>
>Are you saying that DEC's implementation is more broken than Sun's?
>If so, do tell, because you certainly didn't say so in any manner
>I could detect before.
I think the statement stands on its own. The Ultrix lockd had numerous
bugs which prevented file locking from working at all. DEC is aware of
the problems and has another lockd available. I have not heard any
reports from SunOS users of behavior similiar to what I received from
Ultrix users, so I must conclude that SunOS' lockd works "correctly",
even though I am aware that NFS file locking is error prone in general.
This has all been explained with crystal clarity in previous postings.
If you have any other questions, rather than dragging this out in public,
I'd suggest you try e-mail.
Lars P. Fischer
Dave> The first Alpha workstations are coming with OSF/1, with VMS to follow.
Dave> Source: Digital News.
The keyword here is "workstations", I guess.
/Lars
--
Lars Fischer, fis...@iesd.auc.dk | It takes an uncommon mind to think of
CS Dept., Aalborg Univ., DENMARK. | these things. -- Calvin
Dave Brower, DBMS hack, [510] 748-3418
>that the newest iron (e.g. the VAX 9000, the Alpha) never runs Ultrix
>until several months after it runs VMS. DEC is stating its priorities
>with every machine announcement.
The first Alpha workstations are coming with OSF/1, with VMS to follow.
"VMS will always be a niche in the workstation market."
Source: Digital News.
-dB
--
"If it were easy to understand, we wouldn't call it 'code'"
David Brower da...@ingres.com (510) 748-3418
Marcus J. OpenRanum
>Dave> The first Alpha workstations are coming with OSF/1, with VMS to follow.
>Dave> Source: Digital News.
>
>The keyword here is "workstations", I guess.
The fact that Alpha machines are the same platform whether they
are running VMS or OSF/1 has been discussed at length elsewhere. The
servers will run the same O/S options (OSF/1 or VMS) as the workstations.
I think Dave's remark probably had more to do with the order in which
stuff will be shipping - the first machines out will be workstations,
then the honking big boxes will follow (all running either OSF/1 or VMS).
There's been a lot of paranoia around this - if you want to track the
discussion, check out comp.sys.dec for all the variations of FUDs.
mjr.
Jari Tavi
> The keyword here is "workstations", I guess.
If you want more detailed information on first wave products and schedules
you should contact your sales rep. and ask for PID on Alpha Program.
The keyword is not necessarily workstations...
===============================================================================
Full-Name: Jari Tavi
Organization: DEC Finland Dept: EIS/ACT
Tel: +358-0-434 5252 DTN: 879-5252
E-mail: rixrax::jpt A1-mail: Jari Tavi @FNO
Internet: j...@rixrax.enet.dec.com
Address: Digital Equipment Corporation Oy
PL 16
02201 Espoo
FINLAND
===============================================================================
* All opinions are my personal, and do not necessarily represent opinions of
* my employer!
Ron Williams
> >Well, I will back off a bit. But your Unix story is hurt by the fact
> >that the newest iron (e.g. the VAX 9000, the Alpha) never runs Ultrix
> >until several months after it runs VMS. DEC is stating its priorities
> >with every machine announcement.
>
The current 9000 is VAX architecture. Although the alpha 9000's
have been announced, I believe them to be in development. Dec
plans to parallel the development of the VAX's and ALPHA machines
for some time to come.
Some have suggested that VMS will eventually be a shell running
under the Alpha's RISC, as opposed to a native O/S running under
VAX's CISC. Maybe VMS will go away, since it is so effectively
married to the VAX system. Why emulate hardware that isn't there?
Programming under both VMS and UNIX environments (not Ultrix),
I apprectiate the strong points of each. I do get a tad frustrated
moving back and forth, and more than a little tired of 'My O/S is
better than yours' which seems to be a frequent theme here abouts.
Then again, who REALLY wants to program under (down under) CICS?
--
_______________________________________________________________________________
Ron Williams Internet : r...@bwunltd.wciu.edu
Systems Analysis & Programming UUCP : {elroy|cit-vax}!wciu!bwunltd!ron
vox (818) 564-7680 mwcbbs : bwunltd!ron
_, /| "We experience moments absolutely free from worry.
\ o.O' These brief respites are called panic."
=(___)=
U - Cullen Hightower
Thaddeus P. Floryan
>da...@Ingres.COM (Dave Brower, DBMS hack, [510] 748-3418) writes:
>> >Well, I will back off a bit. But your Unix story is hurt by the fact
>> >that the newest iron (e.g. the VAX 9000, the Alpha) never runs Ultrix
>> >until several months after it runs VMS. DEC is stating its priorities
>> >with every machine announcement.
>>
> The 9000 is NOT alpha. Alpha is the MIPS architecture.
>The current 9000 is VAX architecture. Although the alpha 9000's
>have been announced, I believe them to be in development. Dec
>plans to parallel the development of the VAX's and ALPHA machines
>for some time to come.
Huh? True, the 9000 is not Alpha; the 9000 is ECL-based.
DEC's Alpha is their own, not MIPS', development, with a 64-bit CPU.
DEC's MIPS-based machines use the R3000 and are, I believe, the
DECstation series.
DEC provides for upgrading the 9000 with IPFU. I'm *NOT* kidding: IPFU
stands for "Investment Protection Forklift Upgrade"! :-) This was just
reported in one of the myriad DEC rags that are published weekly and was a
direct quote from a DEC spokesperson.
Wonder what they do with the 9000 dinosaurs after an IPFU? Convert them
to marine habitats? :-)
>[...]
> Programming under both VMS and UNIX environments (not Ultrix),
>I apprectiate the strong points of each. I do get a tad frustrated
>moving back and forth, and more than a little tired of 'My O/S is
>better than yours' which seems to be a frequent theme here abouts.
"Some" of the VMS-bashing is not without merit. Ever try to find your
timezone on a VMS system?
One VMS deficiency that really gets me is security-related: NO WAY to know
when a file was last accessed/read.
Though I've used VMS since day one, and MANY other systems over the past 30
years, I'm not going to stir up any DEC-bashing here (it belongs in the
comp.os.vms newsgroup! :-) [ Naw, just kidding (about the bashing) ]
Thad Floryan [ th...@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
Ron Williams
> The 9000 is NOT alpha. Alpha is the MIPS architecture.
> The current 9000 is VAX architecture. Although the alpha 9000's
> have been announced, I believe them to be in development. Dec
> plans to parallel the development of the VAX's and ALPHA machines
> for some time to come.
Thanks to all for the Correction and the appropriate Flames . . .
Yes, Having MIPS on the brain is a disease. Indeed, MIPS is RISC,
but of course RISC is not MIPS. My apologies to those offended by
my grevious error. (Please change MIPS to RISC in the previous
and we'll all be happier . . .)
Paul A Vixie
> However, another very interesting thing is that DEC engineers
> are giving a presentation at the IEEE MicroKernel Workshop in
> Seattle at the end of April. This presentation is about their
> work on putting the VMS system on a mach type microkernel (I
> think it is mach 3.0 but not sure). Thus, if both VMS and
> OSF are eventually on a mach type microkernel then it is
> conceivable that they may both be operational in the same
> alpha risc machine simultaneiously...sort of like IBM VM.
Nice idea. I'm glad I don't know anything about it one way or the other.
But can you imagine any large company just grabbing Mach 3.0 and using it,
being careful not to change the interfaces at all and only hacking on the
common code enough to make it run on the new hardware, and submitting all
their proposed architecture changes to CMU rather than just going off and
doing it?
I can't imagine it either.
Much more likely that a large company would grab Mach 3.0 and beat it to
death with pitchforks until it bore no resemblence in interface or spirit
to the original code. The result may end up being a multiple-universe
operating system built on a Mach-like microkernel, but woe be unto any of
us who expected to be able to share device drivers with other Mach-like
systems.
Disclaimer: I'll probably be fired when my boss reads this.
--
Paul Vixie, DEC Network Systems Lab
Palo Alto, California, USA "Ready, Fire, Aim"
<vi...@pa.dec.com> decwrl!vixie
<pa...@vix.com> vixie!paul alt.pink.bunny.boom.boom.boom moderator
Marcus J. will do TCP/IP for food Ranum
>Much more likely that a large company would grab Mach 3.0 and beat it to
>death with pitchforks until it bore no resemblence in interface or spirit
>to the original code. The result may end up being a multiple-universe
>operating system built on a Mach-like microkernel, but woe be unto any of
>us who expected to be able to share device drivers with other Mach-like
>systems.
Don't forget signals. You gotta hammer signals into the kernel,
too, just to make sure it's UNIX-compatible.
Actually, VMSoid ASTs and stuff might make a lot more sense on
top of a MACH microkernel than UNIX does. The big problem is that I
bet you'll find it's not fast enough in critical regions and stuff
starts migrating into the kernel, and - oops - a 5Mb "microkernel".
Does anyone really have any hard evidence that microkernels
are worth jack? It seems to me that a *much* more sensible approach
would be a "bindable" kernel. Write all the kernel modules to some
kind of interface that allows you at build time to specify what
parts should be "in kernel" and what parts should be "layered".
Let the user decide at build time if they want their filesystem
to be wired in (sensible, if you have a disk locally) or not, etc.
Windows NT sounds like a pretty cool technology - it's
got one of those c00l "microkernel" things. Sitting on top of
that is a "user executive" that has all the windowing stuff and
is generally fairly massive. One gathers that in order to support
this nifty stripped down micro-architecture, 16Mb of main memory
is a "useable" system.
No thanks.
mjr.
--
"Sometimes if you have a cappuccino and then try again it will work OK."
- Dr. Brian Reid, 1992
"Sometimes one cappucino isn't enough."
- Me
Paul A Vixie
flipping, the message-passing overhead can be reduced to not-much-more
than the queueing and sleep-on-the-semaphore hackeronious pseudothreads
present in your average 32-bit bsd or sysV kernel today.
looking at the cost of a disk write or read through a humongokernel we
usually find it dominated by the copyin/copyout costs unless there is
real device access in which case that always dominates. after that the
context switch in and out of kernel mode tends to be the big cost, way
above the disk-cache lookups and endless pseudo-object-oriented function
calls.
in a microkernel where the file system and disk cache are services, you
still have some byte copies since we're assuming that stdio hasn't been
recoded to use valloc() and page-flipping I-O; i'm betting that those
byte copies are still the most expensive thing you're doing. there's an
extra couple of context switches depending on whether the disk cache is
mapped into the file system server or accessed through message passing,
but i'll go out on a limb and sweep all that extra hair under the rug and
say that it doesn't cost much more than the humongokernel.
but in the microkernel case you get to debug your live file system code
with gdb or dbx or even sabre-c. and before you kernel-gdb whackers
come after me on that, i should add: you can recompile and reinstall
your file system without rebooting (assuming that you have some other
working file system to do the compile in -- perhaps networking support
would be a better example of live dbx-ing than file system support. i
have actually seen the berkeley ip/tcp code moved outside the kernel,
started and stopped, and debugged by a dbx process running on the same
machine. it required user-level device register mapping, which i'm not
too keen on, but it worked and it ran ttcp as fast as a normal kernel.)
Karl_Kl...@cs.cmu.edu
Does anyone really have any hard evidence that microkernels
are worth jack?
There's a thread in comp.os.research, "Have we learned anything in the
last 20 years?," on which you may want to chime in.
Peter da Silva
> Does anyone really have any hard evidence that microkernels
> are worth jack?
Well, QNX gets pretty good performance. One thing they did was make sure their
microkernel fit in the 8K on-chip cache on the 80486. Another common operating
system with a microkernel design is AmigaOS. Neither of these systems have a
4MB "microkernel". Both run on commodity processors in under 512K, in fact.
Don't extrapolate from some bad implementations of the idea to the conclusion
that the idea doesn't work.
--
/F{/Times-Roman findfont exch scalefont setfont}def /M{moveto}def /S{show}def
8 F 24 24 M (Sugar Land, TX 77487-5012; +1 713 274 5180)S 60 0 rmoveto(`-_-')S
12 F 24 32 M (Peter da Silva, Ferranti International Controls Corporation)S
0 -6 rmoveto 20 F ( Have you hugged your wolf today?)S showpage
