From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] Walking clarification In-Reply-To: Your message of "Mon, 24 Nov 2003 01:58:10 PST." <9922ec3556b3dee825acd44dfa80c17c@centurytel.net> From: "Russ Cox" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77877.1069684586.1@t40.swtch.com> Message-Id: Date: Mon, 24 Nov 2003 09:36:26 -0500 Topicbox-Message-UUID: 9248a9ce-eacc-11e9-9e20-41e7f4b1d025 > 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