Re: [9fans] ORCLOSE

Re: [9fans] ORCLOSE

[erik quanstrom]

that's often not a reliable sign.  networks go down.  dhcp and
ppp may reassign addresses.

- erik

> Erik wrote:
> > how would the fs determine that the machine hosting the
> > client is in casters-up mode?
>
> Loss of the TCP or IL connection is the usual sign.
>
> Russ
>

Re: [9fans] ORCLOSE

[Russ Cox]

> that's often not a reliable sign.  networks go down.  dhcp and
> ppp may reassign addresses.

Sorry.  9P does not address such concerns.  There is no notion
of re-establishing a connection.  If your connection is dropped,
your ORCLOSE files get removed, all your other files get closed
(including lock files, making them available for use by others).

If you are concerned about keeping a single 9P session across
multiple network instances, you can use a 9P filter like aan or
recover.  Aan just sits on top of any network connection, allowing
special clients and servers to reconnect and pick up where they
left off.  Neither side knows that the connection got lost.

Recover is a client-only solution.  A program runs on the client
that keeps track of the fids the client is using.  If the connection
is lost, then recover redials and reestablishes the fid state as
needed.  It handles ORCLOSE specially: it strips that bit out of the
open mode and turns Tclunks on previously-ORCLOSE fids into
Tremoves.  It also refuses to reopen exclusive-use files.

Recover is not in the distribution yet.  I wrote it for the old 9P and
revised it for 9P2000 but never quite finished it.  Gorka finished it
and tested it last summer but I haven't gotten around to putting
it in.  So for now it's ozinferno^Wvapor-ware.  Sorry.

Russ

Re: [9fans] ORCLOSE

[erik quanstrom]

how would the fs determine that the machine hosting the
client is in casters-up mode?

- erik

On Mon Apr  3 10:12:35 CDT 2006, nemo@lsub.org wrote:
> When a ORCLOSE file is created by a process at
> machine A into a FS at machine B, if the machine
> A goes away (e.g., you power it down), the file
> is not removed. This is as it could be expected, because
> ORCLOSE, IFAIK, is processed by the kernel during the cleanup
> done for the process while it exits.
>
> My question is, whouldn't it be better to honor ORCLOSE
> within the file server? (i.e., lib9p and fossil, mostly).
> This is more resilient to failures and disconnections of the
> client kernel. Otherwise, files are kept hanging around.
>
> I was about to change this for Plan B, because we use
> ORCLOSE files to announce our file trees. If this is no ok
> for Plan 9 as well, I'll use something else for our announces.
>
> thanks
>
>

[9fans] ORCLOSE

[Fco. J. Ballesteros]

When a ORCLOSE file is created by a process at
machine A into a FS at machine B, if the machine
A goes away (e.g., you power it down), the file
is not removed. This is as it could be expected, because
ORCLOSE, IFAIK, is processed by the kernel during the cleanup
done for the process while it exits.

My question is, whouldn't it be better to honor ORCLOSE
within the file server? (i.e., lib9p and fossil, mostly).
This is more resilient to failures and disconnections of the
client kernel. Otherwise, files are kept hanging around.

I was about to change this for Plan B, because we use
ORCLOSE files to announce our file trees. If this is no ok
for Plan 9 as well, I'll use something else for our announces.

thanks

Re: [9fans] ORCLOSE

[Russ Cox]

Nemo wrote:
> When a ORCLOSE file is created by a process at
> machine A into a FS at machine B, if the machine
> A goes away (e.g., you power it down), the file
> is not removed.

I believe this.

> This is as it could be expected, because
> ORCLOSE, IFAIK, is processed by the kernel during the cleanup
> done for the process while it exits.

But this is not true.  ORCLOSE is processed by the remote server.
The kernel does not handle it specially when talking to a
remote 9P server.  (It does handle ORCLOSE for local devices
like devenv and devsrv.)

I think what you are seeing is just a bug in fossil.
fidClunkAll should test for (fid->open & FidORclose) and
then do the remove.  If you implement and test it I'd be
happy to see a patch.

Erik wrote:
> how would the fs determine that the machine hosting the
> client is in casters-up mode?

Loss of the TCP or IL connection is the usual sign.

Russ