9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] Ephase question.
@ 2002-08-13  3:37 rob pike, esq.
  2002-08-13  9:31 ` Douglas A. Gwyn
  0 siblings, 1 reply; 36+ messages in thread
From: rob pike, esq. @ 2002-08-13  3:37 UTC (permalink / raw)
  To: 9fans

>   I see. But can you give me any insight into why it was implemented this
>   way. Again, it seems so obvious to use fids for reference counting and it
>   shouldn't be of a significant overhead. Moreover it's entirely up to
>   the FileServer to support this feature -- kernel is not supposed to
>   care. You should've had some reason for not supporting this in all
>   your FileServers.

There was an implementation reason, which I don't remember.  I prefer
this argument:

	When you remove a file, it's removed.

That's the definition of remove, as I understand it.

Unix has a weird property that you can remove files and they're still not
removed until some unfindable process dies.  We used to run out of disk
space because an editor (mine) unlinked its /tmp file so it wouldn't clutter the
disk if it exited prematurely.  If someone edited a big file, /tmp would fill
up but ls /tmp wouldn't tell you anything.  Not to mention what happens
if the kernel crashed with a file in that half-made state.

open(ORCLOSE) is a much cleaner solution to the /tmp problem.

But the real argument is that Unix's semantics are an accident of the way
it implemented its file system.  Plan 9 has different semantics.  Whether
or not it's what you want, it's hard to argue with:

	When you remove a file, it's removed.


-rob



^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-14 14:12 Russ Cox
  0 siblings, 0 replies; 36+ messages in thread
From: Russ Cox @ 2002-08-14 14:12 UTC (permalink / raw)
  To: 9fans

> What about releasing the resources attached to the file descriptor
> / fid?  A long-running command using hundreds of files in
> sequence - for instance a network server - would be a resource
> hog without close.  Of course you could provide a garbage collector
> but that opens a whole new world of trouble.

It'd be just like NFS!



^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-14 13:19 rob pike, esq.
  2002-08-15  8:59 ` Douglas A. Gwyn
  0 siblings, 1 reply; 36+ messages in thread
From: rob pike, esq. @ 2002-08-14 13:19 UTC (permalink / raw)
  To: 9fans

> It would be an interesting academic exercise to determine the
> minimal set.  E.g. close() doesn't seem to be needed; whenever
> there's no reference to the object, any connection to it can be
> cleaned up.
What about releasing the resources attached to the file descriptor
/ fid?  A long-running command using hundreds of files in
sequence - for instance a network server - would be a resource
hog without close.  Of course you could provide a garbage collector
but that opens a whole new world of trouble.

> At least for Unix devices, it was only the *last*
> close that did anything interesting.
Except for releasing the fd.

>  And I've sometimes had
> the feeling that bind and mount aren't dissimilar enough to
> require separation.
The earliest version of Plan 9 had a different setup than bind
and mount; it was mount and fmount.  It was a mess.  I don't
remember much about it but the current scheme was a huge
improvement - huge.  I think for instance exportfs might have
been impossible in the old scheme.

But there well may be a unified approach that we just missed.


In any case, who cares?  As you said, it's academic.  I can do
everything with a single system call, syscall, that takes as its
first argument the call to make.  If you call that cheating, I
respond that rfork is really a set of calls encoded with a bitvector.

Nobody asks what the minimum libc interface is, or even counts
the calls.  For some reason system calls are seen as magical.  They're
just one way to implement a library.  In Plan 9 in particular, we've
tried to blur the difference between syscall and library, with
things moving back and forth over time.  Stat, wait, and read (!) are
no longer system calls.

What matters is expressibility without bloat, not finding the
criteria under which to claim a lower count of functions of type
T, for some T.

-rob



^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13 23:49 rog
  0 siblings, 0 replies; 36+ messages in thread
From: rog @ 2002-08-13 23:49 UTC (permalink / raw)
  To: 9fans

> > would it be too nasty to make the fileserver refuse writes
> > on files that are currenty open with OEXEC?

> sometimes you really do want to update a binary and it's annoying when
> you can't

well, safeinstall would still have its place:

	cp $prereq $stem || mv $prereq _$stem && cp $prereq $stem

...it would just be less exercised.

round here we tend to

	mv /bin/prog /bin/prog.`{date -n}

which leads to less clashes (but does require garbage collection
every so often).

i don't have such a problem doing this with publicly installed
executables; it's when i'm in the usual compile/edit cycle, and
accidentally overwrite a running executable and spend half an hour
looking for the non-existent bug that gets my goat.  it also means
that i have developed a tendency to ignore hard-to-explain problems:
"oh, it must have been overwritten".

  rog.



^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13 17:28 Russ Cox
  0 siblings, 0 replies; 36+ messages in thread
From: Russ Cox @ 2002-08-13 17:28 UTC (permalink / raw)
  To: 9fans

> and, out of curiosity, were there ever syscalls for
> slots 48 and 49? if so, what'd they do?

I think the gap is historical.  We split the 9P2000 kernel and libraries
from the main sources and added all the new 9P2000 code
in a separate tree.  At some point while the trees were split,
we added pread and pwrite to both systems.  In the 9P2000
system, they were 37 and 38 (previously occupied by read9p
and write9p).  The calls got added to the 9P1 systems some time
later, because they were too convenient not to have, and
I think 50 and 51 got used just to be out of the way as a temporary
slot until the 9P2000 kernels got installed.  (We couldn't replace
read9p and write9p in the 9P1 system, so we needed new numbers.
At the time, the biggest 9P1 syscall number was seek at 39,
while the 9P2000 syscalls were slowly eating the 40s.  I think 50
was just a safe bet.)

One compatibility measure taken in the 9P2000 kernels is that
all the old system calls are emulated, so that old binaries (at least
those that don't read directories) continue to work.  This implies
that we had to allow 50 and 51 as pread/pwrite, so we just
changed the numbers rather than have two for each.

Hence the gap.  There was in fact a summer student project using
40 and 41, but they got recycled for 9P2000 calls.

Pedantically,
Russ



^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13 17:01 rob pike, esq.
  0 siblings, 0 replies; 36+ messages in thread
From: rob pike, esq. @ 2002-08-13 17:01 UTC (permalink / raw)
  To: 9fans

> are these 10 depricated calls used anywhere? if i'm
> reading things right, they're all from the switch to
> 9p2000 (mm, plus ERRSTR change?), so i gather not.
> does any plan exist for removing these?

Some ancient binaries we have still contain them.
They do not appear in the libraries.

> and on the same topic, were write9p and read9p
> eliminated because they were considered redundant
> with pwrite and pread?

They became unnecessary because of the encapsulation
possible with thew new 9P, not because of pread and
pwrite.

> and, out of curiosity, were there ever syscalls for
> slots 48 and 49? if so, what'd they do?

I believe a summer student had something planned
there.

-rob



^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13 16:37 anothy
  0 siblings, 0 replies; 36+ messages in thread
From: anothy @ 2002-08-13 16:37 UTC (permalink / raw)
  To: 9fans

are these 10 depricated calls used anywhere? if i'm
reading things right, they're all from the switch to
9p2000 (mm, plus ERRSTR change?), so i gather not.
does any plan exist for removing these?

and on the same topic, were write9p and read9p
eliminated because they were considered redundant
with pwrite and pread?

and, out of curiosity, were there ever syscalls for
slots 48 and 49? if so, what'd they do?
ア


^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13 15:59 Russ Cox
  2002-08-14  8:42 ` Douglas A. Gwyn
  0 siblings, 1 reply; 36+ messages in thread
From: Russ Cox @ 2002-08-13 15:59 UTC (permalink / raw)
  To: 9fans

I don't know.  Plan 9 has 48 system calls these days,
10 of which are deprecated.  So 38.  That's still a lot.



^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13 15:57 Russ Cox
  0 siblings, 0 replies; 36+ messages in thread
From: Russ Cox @ 2002-08-13 15:57 UTC (permalink / raw)
  To: 9fans

> I've just got v9fs back and mostly working on Linux (uses 9p still but 3e
> ... 4e is next). But I'm going to have the Unix semantics. The shared exec
> over a network case is too common not to use the Unix semantics.

And arguably you _should_ have the Unix semantics.  No one here is
saying that one way is required.  9P doesn't say anything about when
the remove happens.  It's a choice made by some file servers.
U9fs just does a Unix remove too, so you'd get Unix semantics there as well.

Russ


^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13 15:43 rob pike, esq.
  0 siblings, 0 replies; 36+ messages in thread
From: rob pike, esq. @ 2002-08-13 15:43 UTC (permalink / raw)
  To: 9fans

> would it be too nasty to make the fileserver refuse writes
> on files that are currenty open with OEXEC?

We talked a lot about this in the early design days.  If I recall
right we decided to allow the write, given permission, because
sometimes you really do want to update a binary and it's annoying when
you can't: build scripts fail, installs abort, that sort of thing.
There are times when we install everything and it's nice not to
worry about it.  Although it's far from perfect, I'm comfortable
enough with the safeinstall notion to leave things as they are.

I realize that's not much of an argument.

-rob



^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13 13:13 rog
  0 siblings, 0 replies; 36+ messages in thread
From: rog @ 2002-08-13 13:13 UTC (permalink / raw)
  To: 9fans

> My biggest headache has been replacing running binaries.  Since we
> can't remove them or overwrite them without disasterous consequences,
> we end up with a 'safeinstall' option in all our mkfiles.  The safeinstall
> moves the file to an unlikely name (e.g. x -> _x) and copies in the
> new file.  Of course, since we have dozens of machines all running off
> the same file system,  something is probably running off the _x that
> was there.  So we sometimes have to move _x to __x, etc.  It's a
> royal pain.  We often forget and just install with the result that
> someone an hour after the fact in some other part of the building
> sends you a snap or pointer to a broken process.  Since I don't have
> to implement the fs, I'ld have preferred the Unix semantics in this
> case.  It's caused me a lot of inconvenience over the last 10+ years.

i was going to mention this, but you did it for me.

would it be too nasty to make the fileserver refuse writes
on files that are currenty open with OEXEC?

that would alleviate somewhat the most common (and hard to find)
problem: overwriting a running binary.
(which can also be a problem for shellscripts, note)

  rog.



^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13 12:16 presotto
  2002-08-13 15:53 ` Ronald G Minnich
  0 siblings, 1 reply; 36+ messages in thread
From: presotto @ 2002-08-13 12:16 UTC (permalink / raw)
  To: 9fans

> - Unix' solution of making the remove fail with "file busy"; it was
> always inconvenient and confusing.  They use that one for in use
> executables.

I'm clearly misremembering.  I was thinking of overwrite.  Don't know
why, had to remove a file last week on an SGI system to do just that.

> The really interesting question is how much pain did that cause when
> porting/rewriting software from Unix.  creat()/unlink()/work with fd
> you'd got from creat()  is definitely a common idiom.  OTOH, most of
> its uses are for situations when you either want remove-on-close
> or are messing with shared directories...
>
> How bad it had it actually been?

Russ addressed the ape library.

As someone, Rob?, has already mentioned, the close on remove
flag (ORCLOSE) flag on open/create does the same thing as unlinking
immediately after opening.

My biggest headache has been replacing running binaries.  Since we
can't remove them or overwrite them without disasterous consequences,
we end up with a 'safeinstall' option in all our mkfiles.  The safeinstall
moves the file to an unlikely name (e.g. x -> _x) and copies in the
new file.  Of course, since we have dozens of machines all running off
the same file system,  something is probably running off the _x that
was there.  So we sometimes have to move _x to __x, etc.  It's a
royal pain.  We often forget and just install with the result that
someone an hour after the fact in some other part of the building
sends you a snap or pointer to a broken process.  Since I don't have
to implement the fs, I'ld have preferred the Unix semantics in this
case.  It's caused me a lot of inconvenience over the last 10+ years.

> "Accident" in this case need not imply "unintentional".
> When Canaday et al. invented the inode-based system,
> it is conceivable that they thought the semantics were
> just what they wanted.

Since the same 'et al' implemented both the first Unix fs
and the first Plan 9 fs, I'll ask him and see what he says.


^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13 11:43 David Gordon Hogan
  2002-08-13 15:45 ` Ronald G Minnich
  0 siblings, 1 reply; 36+ messages in thread
From: David Gordon Hogan @ 2002-08-13 11:43 UTC (permalink / raw)
  To: 9fans

> On freebsd and Linux, exec happens via an mmap (more or less). Possibly
> the behavioural difference you saw between binary and normal file was due
> to how the kernels handle mmap for exec vs. file I/O, not due to it being
> a binary vs. normal file.

So [gigantic leap here], not only does Linux have ~250 system
calls, but most of them can be emulated with mmap?



^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13  6:17 Charles Forsyth
  0 siblings, 0 replies; 36+ messages in thread
From: Charles Forsyth @ 2002-08-13  6:17 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

so if i completely remove a file that someone is executing, it continues to work,
but if i copy into a file that remains and someone is executing it, it fails.

makes perfect sense to me.

[-- Attachment #2: Type: message/rfc822, Size: 2627 bytes --]

From: Alexander Viro <viro@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Ephase question.
Date: Tue, 13 Aug 2002 02:13:08 -0400 (EDT)
Message-ID: <Pine.GSO.4.21.0208130206400.1501-100000@weyl.math.psu.edu>



On Tue, 13 Aug 2002, Russ Cox wrote:

> > > - Unix' solution of making the remove fail with "file busy"; it was
> > > always inconvenient and confusing.  They use that one for in use
> > > executables.
> >
> > I haven't seen a version of unix do this one for a while (as in decades).
> > The remove succeeds, the file goes away when the last reference does (but
> > you have to have inodes ...). But maybe there is some version of Unix
> > you're referencing I'm not familiar with -- there's a lot of possibilities
> > out there nowadays ...
>
> i've seen it recently on either freebsd or linux,
> in the case of trying to remove or perhaps overwrite
> binaries that were being executed at the time.
> it was definitely a binary rather than a normal file.

Overwrite - sure.  Remove - nope.

^ permalink raw reply	[flat|nested] 36+ messages in thread
[parent not found: <rsc@plan9.bell-labs.com>]
* Re: [9fans] Ephase question.
@ 2002-08-13  4:20 Russ Cox
  0 siblings, 0 replies; 36+ messages in thread
From: Russ Cox @ 2002-08-13  4:20 UTC (permalink / raw)
  To: 9fans

APE simulates the creat()/unlink()/work idiom,
so APE-ported Unix programs would tend not to notice.
The programs I've natively ported have never cared.

Russ



^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13  3:33 presotto
  2002-08-13  4:10 ` Alexander Viro
                   ` (3 more replies)
  0 siblings, 4 replies; 36+ messages in thread
From: presotto @ 2002-08-13  3:33 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

We chose it because it was easier to implement and we couldn't see
that doing so would cause undo hardship.  Rsc's observation is good
but wasn't really a design goal.

There are 3 obvious alternatives:
- Unix' solution of making the remove fail with "file busy"; it was
always inconvenient and confusing.  They use that one for in use
executables.  The fs doesn't really know when a file is executing so that
one isn't really that useful to us.
- Have the remove work but not really remove the file from the directory
till the current opener goes away.  That's just too confusing.
- Disassociate the file with the directory, but leave it around for anyone
that has it open to keep playing with.  This is easy to do when the
file is really represented by an inode that doesn't have anything to
do with a directory.  It's a lot harder without that indirection.  We
didn't have inodes.  The best we could do is copy it somewhere else
and fudge up pointers to the somewhere else (a special invisible
directory perhaps).  It also leads to cleaning up orphaned files
during a reboot of the file server, fsck's job (or one of many) in
Unix.  It gets messy quick without inodes being the one true
representation.

Clearly its a matter of taste; with enough code you can do most
anything.  If it were a goal, Ken would proabably have designed
his fs a bit differently.  Our taste, like our minds, tends to
favor the simple.  Of course, we're gradually losing our sense
of taste due to exigency. About time for a new simple operating
system.

[-- Attachment #2: Type: message/rfc822, Size: 4885 bytes --]

From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Ephase question.
Date: Tue, 13 Aug 2002 07:14:22 +0400
Message-ID: <20020813071422.A12044@unicorn.math.spbu.ru>

On Mon, Aug 12, 2002 at 09:39:40PM -0400, presotto@plan9.bell-labs.com wrote:
> This isn't new semantics.  If you remove a file that someone
> else is using, too bad for him.  There's nothing sacred about
> having a file open.

  Indeed. Same applies to any fid, not just opened ones.

> If someone else has permissions to do nasty and nefarious things to it,
> they can.
>
> This is very different than Unix.

  I see. But can you give me any insight into why it was implemented this
  way. Again, it seems so obvious to use fids for reference counting and it
  shouldn't be of a significant overhead. Moreover it's entirely up to
  the FileServer to support this feature -- kernel is not supposed to
  care. You should've had some reason for not supporting this in all
  your FileServers.

Thanks,
Roman.

> Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon Aug 12 21:27:18 EDT 2002
> Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Mon Aug 12 21:27:17 EDT 2002
> Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
> 	id 04B4D199B9; Mon, 12 Aug 2002 21:27:07 -0400 (EDT)
> Delivered-To: 9fans@cse.psu.edu
> Received: from unicorn.math.spbu.ru (unicorn.math.spbu.ru [195.19.226.166])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 4D5C41998C
> 	for <9fans@cse.psu.edu>; Mon, 12 Aug 2002 21:26:20 -0400 (EDT)
> Received: (from vugluskr@localhost)
> 	by unicorn.math.spbu.ru (8.9.3/8.9.3) id FAA10626
> 	for 9fans@cse.psu.edu; Tue, 13 Aug 2002 05:26:18 +0400
> From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
> To: 9fans@cse.psu.edu
> Message-ID: <20020813052618.A10336@unicorn.math.spbu.ru>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> X-Mailer: Mutt 1.0pre3i
> Subject: [9fans] Ephase question.
> Sender: 9fans-admin@cse.psu.edu
> Errors-To: 9fans-admin@cse.psu.edu
> X-BeenThere: 9fans@cse.psu.edu
> X-Mailman-Version: 2.0.11
> Precedence: bulk
> Reply-To: 9fans@cse.psu.edu
> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
> List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
> Date: Tue, 13 Aug 2002 05:26:18 +0400
>
> Hi everybody,
>
> digging inside 4th edition gave me some very unexpected results
> in terms of file access semantics in user space. But let me show
> a scenario first:
>
> first-user$ cat > /shared-directory/file
> blah-blah-blah
>
> second-user$ rm /shared-directory/file
>
> [first user after hitting <CR> ]
> "phase error -- directory entry not allocated"
>
> I was a little bit shocked at first, mainly because I've got so used to
> UNIX semantics of "once you get it -- it's yours", that I've been taking
> it for granted in Plan9 as well.
>
> Suddenly I can't remember how 3nd and 2nd editions behaved.
>
> Before now I was under the impression that regular unopened fids are mostly
> used for reference counting and once you grab a fid nobody can kill the
> actual object it refers to, but 4th edition proved me wrong. Even though
> I still can't understand why it behaves this way. Could somebody explain
> the rationale behind that to me, please ? And I'm really curios now about
> what obligations server is supposed to have when it accepts a new fid from
> a client for a given object.
>
> Thanks,
> Roman.

^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13  3:31 Russ Cox
  0 siblings, 0 replies; 36+ messages in thread
From: Russ Cox @ 2002-08-13  3:31 UTC (permalink / raw)
  To: 9fans

>   I see. But can you give me any insight into why it was implemented this
>   way. Again, it seems so obvious to use fids for reference counting and it
>   shouldn't be of a significant overhead. Moreover it's entirely up to
>   the FileServer to support this feature -- kernel is not supposed to
>   care. You should've had some reason for not supporting this in all
>   your FileServers.

If someone has a big runaway log file open that is running you out of
disk space, and you remove it, then it goes away.  That's a feature.
(Of course, we don't have this problem on the worm drive, but the
point stands.)  This way is simpler, and I've yet to see a compelling
argument against it.

You're right that the kernel doesn't care -- the file server is giving
you the phase error.  Many of the non-disk file systems do reference
count their files.

Russ



^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: [9fans] Ephase question.
@ 2002-08-13  1:39 presotto
  2002-08-13  3:14 ` Roman V. Shaposhnick
  0 siblings, 1 reply; 36+ messages in thread
From: presotto @ 2002-08-13  1:39 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 265 bytes --]

This isn't new semantics.  If you remove a file that someone
else is using, too bad for him.  There's nothing sacred about
having a file open.  If someone else has permissions to do
nasty and nefarious things to it, they can.

This is very different than Unix.

[-- Attachment #2: Type: message/rfc822, Size: 2451 bytes --]

From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
To: 9fans@cse.psu.edu
Subject: [9fans] Ephase question.
Date: Tue, 13 Aug 2002 05:26:18 +0400
Message-ID: <20020813052618.A10336@unicorn.math.spbu.ru>

Hi everybody,

digging inside 4th edition gave me some very unexpected results
in terms of file access semantics in user space. But let me show
a scenario first:

first-user$ cat > /shared-directory/file
blah-blah-blah

second-user$ rm /shared-directory/file

[first user after hitting <CR> ]
"phase error -- directory entry not allocated"

I was a little bit shocked at first, mainly because I've got so used to
UNIX semantics of "once you get it -- it's yours", that I've been taking
it for granted in Plan9 as well.

Suddenly I can't remember how 3nd and 2nd editions behaved.

Before now I was under the impression that regular unopened fids are mostly
used for reference counting and once you grab a fid nobody can kill the
actual object it refers to, but 4th edition proved me wrong. Even though
I still can't understand why it behaves this way. Could somebody explain
the rationale behind that to me, please ? And I'm really curios now about
what obligations server is supposed to have when it accepts a new fid from
a client for a given object.

Thanks,
Roman.

^ permalink raw reply	[flat|nested] 36+ messages in thread
* [9fans] Ephase question.
@ 2002-08-13  1:26 Roman V. Shaposhnick
  0 siblings, 0 replies; 36+ messages in thread
From: Roman V. Shaposhnick @ 2002-08-13  1:26 UTC (permalink / raw)
  To: 9fans

Hi everybody,

digging inside 4th edition gave me some very unexpected results
in terms of file access semantics in user space. But let me show
a scenario first:

first-user$ cat > /shared-directory/file
blah-blah-blah

second-user$ rm /shared-directory/file

[first user after hitting <CR> ]
"phase error -- directory entry not allocated"

I was a little bit shocked at first, mainly because I've got so used to
UNIX semantics of "once you get it -- it's yours", that I've been taking
it for granted in Plan9 as well.

Suddenly I can't remember how 3nd and 2nd editions behaved.

Before now I was under the impression that regular unopened fids are mostly
used for reference counting and once you grab a fid nobody can kill the
actual object it refers to, but 4th edition proved me wrong. Even though
I still can't understand why it behaves this way. Could somebody explain
the rationale behind that to me, please ? And I'm really curios now about
what obligations server is supposed to have when it accepts a new fid from
a client for a given object.

Thanks,
Roman.


^ permalink raw reply	[flat|nested] 36+ messages in thread

end of thread, other threads:[~2002-08-19 16:23 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-08-13  3:37 [9fans] Ephase question rob pike, esq.
2002-08-13  9:31 ` Douglas A. Gwyn
  -- strict thread matches above, loose matches on Subject: below --
2002-08-14 14:12 Russ Cox
2002-08-14 13:19 rob pike, esq.
2002-08-15  8:59 ` Douglas A. Gwyn
2002-08-15 16:22   ` Ronald G Minnich
2002-08-13 23:49 rog
2002-08-13 17:28 Russ Cox
2002-08-13 17:01 rob pike, esq.
2002-08-13 16:37 anothy
2002-08-13 15:59 Russ Cox
2002-08-14  8:42 ` Douglas A. Gwyn
2002-08-13 15:57 Russ Cox
2002-08-13 15:43 rob pike, esq.
2002-08-13 13:13 rog
2002-08-13 12:16 presotto
2002-08-13 15:53 ` Ronald G Minnich
2002-08-13 11:43 David Gordon Hogan
2002-08-13 15:45 ` Ronald G Minnich
2002-08-13  6:17 Charles Forsyth
     [not found] <rsc@plan9.bell-labs.com>
2002-08-13  5:42 ` Russ Cox
2002-08-13  5:53   ` Scott Schwartz
2002-08-13  6:05   ` Ronald G Minnich
2002-08-13  6:22     ` Alexander Viro
2002-08-13  6:13   ` Alexander Viro
2002-08-13  4:20 Russ Cox
2002-08-13  3:33 presotto
2002-08-13  4:10 ` Alexander Viro
2002-08-13  5:39 ` Ronald G Minnich
2002-08-19 16:23   ` Boyd Roberts
2002-08-13  6:46 ` Andrew Lynch
2002-08-13 22:07 ` Roman V. Shaposhnick
2002-08-13  3:31 Russ Cox
2002-08-13  1:39 presotto
2002-08-13  3:14 ` Roman V. Shaposhnick
2002-08-13  1:26 Roman V. Shaposhnick

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).