9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] AFS-client for Plan9 - ?
@ 2000-11-14 23:57 David Gordon Hogan
  0 siblings, 0 replies; 25+ messages in thread
From: David Gordon Hogan @ 2000-11-14 23:57 UTC (permalink / raw)
  To: 9fans

> > Precisely. And any kernel that will try _not_ to do that will die under the
> > leaks produced by the $BIGNUM of applications expecting it do act as any
> > sane UNIX should.
> Which UNIX version lacks this behavior?
> (Or are you trying to run UNIX programs
> on some non-UNIX?)

The hypothetical one positted earlier in this thread.

Sorry to butt in, but this is just getting riddiculous.



^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] AFS-client for Plan9 - ?
@ 2000-11-20 15:25 rog
  2000-11-21 16:04 ` Douglas A. Gwyn
  0 siblings, 1 reply; 25+ messages in thread
From: rog @ 2000-11-20 15:25 UTC (permalink / raw)
  To: 9fans

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

however, it's worth remembering, that in the Unix i remember at any
rate, _exit() is not always invoked on program exit.  it isn't invoked
if the program dies from a signal, for instance.

i've always presumed that the final close of fds is done when their
refcount drops to zero, i.e.  when the exited process's file table is
cleared up by the kernel.

so the actual _?exit() system calls are not that crucial to the issue
of file closing under AFS. stdio is a different matter, of course.

but i'm not entirely sure whether we're on topic here...  :-)

  cheers,
    rog.


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

To: <cse.psu.edu!9fans>
Subject: Re: [9fans] AFS-client for Plan9 - ?
Date: Mon, 20 Nov 2000 14:24:48 +0100
Message-ID: <009201c052f5$420a2480$0ab9c6d4@cybercable.fr>

From: Douglas A. Gwyn <gwyn@arl.army.mil>

> Boyd Roberts wrote:
> > here we go.  the kernel closes the fd's as a part of exit,
> > like td said.
> 
> Further, upon return from main(), all the exit() actions
> are performed.
> 
> _exit(), on the other hand, does not perform any stdio.
> (Its main use is in a child branch of a fork.)

absolutely correct.


^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] AFS-client for Plan9 - ?
@ 2000-11-15  8:10 nigel
  2000-11-15  8:20 ` Alexander Viro
  0 siblings, 1 reply; 25+ messages in thread
From: nigel @ 2000-11-15  8:10 UTC (permalink / raw)
  To: 9fans

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

Let me explain (and, yes, this is a quote from Fawlty Towers)

Programs which do not explicitly close flies before invoking exit() are
not

1) badly written

or

2) forcing Unix implementations to have to do close on exit to compensate

These are the defined semantics. So the reason is "because that's what
the program quite reasonably expects".

Just in the same way that you don't have to free all memory before
calling exit, unless, as in td's words "they've changed that since I
last looked".  I know "they" did for 16 bit Windows applications, and
it's certainly the case for semaphores in Unix.

> Grr... OK, let me rephrase it:
> 
> 	I really doubt that there is (or ever was) a UNIX variant that
> would not do close-on-exit. Reason: lots and lots of programs that would
> kill such system with file leaks.


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

From: Alexander Viro <viro@math.psu.edu>
To: Tom Duff <td@pixar.com>
Cc: 9fans@cse.psu.edu
Subject: Re: [9fans] AFS-client for Plan9 - ?
Date: Tue, 14 Nov 2000 19:31:13 -0500 (EST)
Message-ID: <Pine.GSO.4.21.0011141923210.5482-100000@weyl.math.psu.edu>



On Tue, 14 Nov 2000, Tom Duff wrote:

> > Precisely. And any kernel that will try _not_ to do that will die under the
> > leaks produced by the $BIGNUM of applications expecting it do act as any
> > sane UNIX should.
> Which UNIX version lacks this behavior?
> (Or are you trying to run UNIX programs
> on some non-UNIX?)

Grr... OK, let me rephrase it:

	I really doubt that there is (or ever was) a UNIX variant that
would not do close-on-exit. Reason: lots and lots of programs that would
kill such system with file leaks.

IOW, "not likely" was about "some numskull changed it" part - such attempt
would backfire immediately. We are in violent agreement...

^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] AFS-client for Plan9 - ?
@ 2000-11-13 20:22 presotto
  0 siblings, 0 replies; 25+ messages in thread
From: presotto @ 2000-11-13 20:22 UTC (permalink / raw)
  To: 9fans

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

Andrew can cache whole files locally and send back journaled updates.
It's a lot more than cfs.  This is not a trivial project.  Might be
interesting though.

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

From: anothy@cosym.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] AFS-client for Plan9 - ?
Date: Mon, 13 Nov 2000 15:19:02 -0500
Message-ID: <20001113201911.6003E199EB@mail.cse.psu.edu>

//Local caching would be great, I think.

okay, let me say off the bat i have no idea how
AFS handles caching, so this comparison may be
totally inapropriate. but for fs caching in
Plan 9 (without 9p↔AFS), take a look at cfs(4)
and the -C option to mount in bind(1).

if your goal is talking to AIX or other Unix
boxes, take a look at u9fs(4).
-α.

^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [9fans] AFS-client for Plan9 - ?
@ 2000-11-13 20:19 anothy
  2000-11-14  9:58 ` Wladimir Mutel
  0 siblings, 1 reply; 25+ messages in thread
From: anothy @ 2000-11-13 20:19 UTC (permalink / raw)
  To: 9fans

//Local caching would be great, I think.

okay, let me say off the bat i have no idea how
AFS handles caching, so this comparison may be
totally inapropriate. but for fs caching in
Plan 9 (without 9p↔AFS), take a look at cfs(4)
and the -C option to mount in bind(1).

if your goal is talking to AIX or other Unix
boxes, take a look at u9fs(4).
-α.


^ permalink raw reply	[flat|nested] 25+ messages in thread
[parent not found: <200011131639.eADGdhI37677@smtp3.alkar.net>]
* Re: [9fans] AFS-client for Plan9 - ?
@ 2000-11-13 16:39 presotto
  2000-11-14 15:20 ` Boyd Roberts
  0 siblings, 1 reply; 25+ messages in thread
From: presotto @ 2000-11-13 16:39 UTC (permalink / raw)
  To: mwg, 9fans

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

Are you volunteering?  I don't know of anyone else writing
an AFS<->9P converter.

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

From: Wladimir Mutel <mwg@alkar.net>
To: 9fans@cse.psu.edu
Subject: [9fans] AFS-client for Plan9 - ?
Date: Mon, 13 Nov 2000 16:30:52 GMT
Message-ID: <8uoutp$als$1@pandora.alkar.net>

	IBM recently opened their AFS (distributed file system with local
	caching) -
	http://oss.software.ibm.com/developerworks/opensource/afs/

	Could there be any reason or use to make Plan9 AFS-client (like
	afssrv, to connect to afs-servers and map 9p to afs) ?

	Could Plan9 fs(8) get some afs features ? Local caching would be
	great, I think.

--
mwg@alkar.net, 399916, 340044, 7442333, 7786458 - Владимир Мутель

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [9fans] AFS-client for Plan9 - ?
@ 2000-11-13 16:30 Wladimir Mutel
  0 siblings, 0 replies; 25+ messages in thread
From: Wladimir Mutel @ 2000-11-13 16:30 UTC (permalink / raw)
  To: 9fans

	IBM recently opened their AFS (distributed file system with local
	caching) -
	http://oss.software.ibm.com/developerworks/opensource/afs/

	Could there be any reason or use to make Plan9 AFS-client (like
	afssrv, to connect to afs-servers and map 9p to afs) ?

	Could Plan9 fs(8) get some afs features ? Local caching would be
	great, I think.

--
mwg@alkar.net, 399916, 340044, 7442333, 7786458 - Владимир Мутель


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

end of thread, other threads:[~2000-11-21 16:04 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-11-14 23:57 [9fans] AFS-client for Plan9 - ? David Gordon Hogan
  -- strict thread matches above, loose matches on Subject: below --
2000-11-20 15:25 rog
2000-11-21 16:04 ` Douglas A. Gwyn
2000-11-15  8:10 nigel
2000-11-15  8:20 ` Alexander Viro
2000-11-13 20:22 presotto
2000-11-13 20:19 anothy
2000-11-14  9:58 ` Wladimir Mutel
     [not found]   ` <mwg@alkar.net>
2000-11-14 22:33     ` Tom Duff
2000-11-14 22:41       ` Boyd Roberts
2000-11-14 22:41       ` Alexander Viro
2000-11-14 22:51         ` Boyd Roberts
     [not found]           ` <boyd@planete.net>
2000-11-14 23:02             ` Tom Duff
2000-11-20 10:55           ` Chris Locke
2000-11-20 10:56           ` Douglas A. Gwyn
2000-11-20 13:24             ` Boyd Roberts
     [not found]         ` <viro@math.psu.edu>
2000-11-14 23:00           ` Tom Duff
2000-11-14 23:15             ` Alexander Viro
2000-11-14 23:54           ` Tom Duff
2000-11-15  0:31             ` Alexander Viro
2000-11-15  0:38               ` Boyd Roberts
     [not found] <200011131639.eADGdhI37677@smtp3.alkar.net>
2000-11-13 17:03 ` Wladimir Mutel
2000-11-13 16:39 presotto
2000-11-14 15:20 ` Boyd Roberts
2000-11-13 16:30 Wladimir Mutel

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).