From mboxrd@z Thu Jan 1 00:00:00 1970 From: presotto@closedmind.org To: 9fans@cse.psu.edu Subject: Re: [9fans] Plan 9 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-onhytzwiidqovoaxphrzdzwswe" Message-Id: <20011108140245.3ADD6199F2@mail.cse.psu.edu> Date: Thu, 8 Nov 2001 09:02:43 -0500 Topicbox-Message-UUID: 19fdf066-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-onhytzwiidqovoaxphrzdzwswe Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I take it that you're suggesting that the file system has no structure other than being an object repository. It's up to each user to impose order by having his or her own object linkage. It is indeed an interesting idea. It seems that sharing views would also be desirable since you would need to communicate with others. You'ld also have to have some form of persistence of the structural information or else run possibly billion line scripts every time you connect to the system. You'ld also need a naming scheme so that you could reference the objects for the links. Sean Quinlan is doing something similar, though only the file storage part with a system called venti. I don't know how much he's released about it but I know there's a paper in the works. Look at http://cm.bell-labs.com/cm/cs/who/seanq I know I've seen something similar before though I can't remember where. The idea there was a sea of objects with multiple views that made the interrelation subjective. I'll see if I can find a reference. Don't hold your breath, I'm getting older by the minute. So, it this what you are intending? Sorry its taken so long to figure it out but your descriptions have been less than clear. --upas-onhytzwiidqovoaxphrzdzwswe Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Thu Nov 8 05:50:03 EST 2001 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 1F99219A2F; Thu, 8 Nov 2001 05:49:54 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from mercury.bath.ac.uk (mercury.bath.ac.uk [138.38.32.81]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 6EBF6199F2 for <9fans@cse.psu.edu>; Thu, 8 Nov 2001 05:48:07 -0500 (EST) Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1) id 161mbd-0002ha-00 for 9fans@cse.psu.edu; Thu, 08 Nov 2001 10:40:21 +0000 Received: from GATEWAY by bath.ac.uk with netnews for 9fans@cse.psu.edu (9fans@cse.psu.edu) To: 9fans@cse.psu.edu From: "Thomas Bushnell, BSG" Message-ID: <87zo5xyau4.fsf@becket.becket.net> Organization: University of California, Irvine Content-Type: text/plain; charset=us-ascii References: <20011107110224.6CE85199BB@mail.cse.psu.edu> Subject: Re: [9fans] Plan 9 Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.6 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: Date: Thu, 8 Nov 2001 10:39:02 GMT geoff@collyer.net writes: > To back up presotto's claim of efficiency of binds, my old department > overlaid our sparsely-populated file server onto the main plan 9 file > server. ovfs got written late in the game, so for a long time, we had > a /lib/namespace that was 346 lines (by the end, anyway). By a "large mount table" I mean one which has a similar number of entries to the size of the file system. For a filesystem with ten thousand files, that would be something a similar number of entries. I'm sorry if that wasn't clear. --upas-onhytzwiidqovoaxphrzdzwswe--