9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Walking clarification
@ 2003-11-24  9:58 Skip Tavakkolian
  2003-11-24 14:21 ` David Presotto
  2003-11-24 14:36 ` Russ Cox
  0 siblings, 2 replies; 4+ messages in thread
From: Skip Tavakkolian @ 2003-11-24  9:58 UTC (permalink / raw)
  To: 9fans

I am writing an aggregator fs that serves up a couple of
remote fs'es that have been posted to /srv.  It looks
something like this to the user:

/agg_fs
	/rmt_fs_1	# previously posted to /srv
	/rmt_fs_2	# ditto


I don't want to mount the posted fd's, so I have to
relay the messages.  It seems other than handling
wname during walks in a special way and taking
care of root, it should pretty much be a relay.
Is this correct?



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

* Re: [9fans] Walking clarification
  2003-11-24  9:58 [9fans] Walking clarification Skip Tavakkolian
@ 2003-11-24 14:21 ` David Presotto
  2003-11-24 14:36 ` Russ Cox
  1 sibling, 0 replies; 4+ messages in thread
From: David Presotto @ 2003-11-24 14:21 UTC (permalink / raw)
  To: 9fans

Yes.  However, look at how srvfs is implemented.  You can either use it directly or
do the same thing.


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

* Re: [9fans] Walking clarification
  2003-11-24  9:58 [9fans] Walking clarification Skip Tavakkolian
  2003-11-24 14:21 ` David Presotto
@ 2003-11-24 14:36 ` Russ Cox
  2003-11-24 17:54   ` Skip Tavakkolian
  1 sibling, 1 reply; 4+ messages in thread
From: Russ Cox @ 2003-11-24 14:36 UTC (permalink / raw)
  To: 9fans

> I am writing an aggregator fs that serves up a couple of
> remote fs'es that have been posted to /srv.  It looks
> something like this to the user:
>
> /agg_fs
> 	/rmt_fs_1	# previously posted to /srv
> 	/rmt_fs_2	# ditto
>
>
> I don't want to mount the posted fd's, so I have to
> relay the messages.  It seems other than handling
> wname during walks in a special way and taking
> care of root, it should pretty much be a relay.

and issuing versions for each one.
and issuing attaches for each one.
and assuming that rmt_fs_1 and rmt_fs_2
don't do authentication and neither will you
(or assuming that you can authenticate clients
and authenticate to rmt_fs_* on their behalf).
but that's all startup.

once you get past startup, you're right, it's
pretty much a relay.  the only interesting
issue is managing the returned qids so that
qids from rmt_fs_1 don't overlap with
qids from rmt_fs_2.  look at what exportfs does.
basically there is an assumption that the high
16 bits of the qid.path are very low entropy (real
file servers always leave them at 0) so we
can just shuffle them around to distinguish qids
from different servers.
this affects Rwalk, Rstat, Ropen, Rread of a directory.

russ


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

* Re: [9fans] Walking clarification
  2003-11-24 14:36 ` Russ Cox
@ 2003-11-24 17:54   ` Skip Tavakkolian
  0 siblings, 0 replies; 4+ messages in thread
From: Skip Tavakkolian @ 2003-11-24 17:54 UTC (permalink / raw)
  To: 9fans

> the only interesting
> issue is managing the returned qids

Thanks all.   This was going to be my next question.



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

end of thread, other threads:[~2003-11-24 17:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-24  9:58 [9fans] Walking clarification Skip Tavakkolian
2003-11-24 14:21 ` David Presotto
2003-11-24 14:36 ` Russ Cox
2003-11-24 17:54   ` Skip Tavakkolian

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