Re: [9fans] Ephase question.

["Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>]

Thanks for the answer ( special thanks to Ken for providing historical
background ). The only thing I still wish for is couple of lines in
9P specification or any other document saying that, generally speaking,
Servers have no obligations whatsoever regarding returned fids. Fids can
be dangling.

As for simplicity -- I can't agree more. That's what make 9P and Plan9 so
appealing to me.

Roman.

On Mon, Aug 12, 2002 at 11:33:53PM -0400, presotto@plan9.bell-labs.com wrote:
> 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.
> Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon Aug 12 23:15:17 EDT 2002
> Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Mon Aug 12 23:15:15 EDT 2002
> Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.6.6])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
> 	id DC934199DD; Mon, 12 Aug 2002 23:15:06 -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 661B919999
> 	for <9fans@cse.psu.edu>; Mon, 12 Aug 2002 23:14:24 -0400 (EDT)
> Received: (from vugluskr@localhost)
> 	by unicorn.math.spbu.ru (8.9.3/8.9.3) id HAA12130
> 	for 9fans@cse.psu.edu; Tue, 13 Aug 2002 07:14:22 +0400
> From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] Ephase question.
> Message-ID: <20020813071422.A12044@unicorn.math.spbu.ru>
> References: <edbdeed0efb39dc5d9a1446470bbbdac@plan9.bell-labs.com>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> X-Mailer: Mutt 1.0pre3i
> In-Reply-To: <edbdeed0efb39dc5d9a1446470bbbdac@plan9.bell-labs.com>
> 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 07:14:22 +0400
>
> 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.