Messages in this thread |  | | Date | Tue, 16 Jul 1996 22:49:36 +0100 (BST) | From | Bryn Paul Arnold Jones <> | Subject | Re: Alternate solutions (Was: Re: NFS still has caching problem) |
| |
On Sun, 14 Jul 1996, Alan Cox wrote:
> > I recall that some candidates were mentioned some while ago. Anybody > > working on this? Any progress? > > > > If not, maybe it's time to see if we can't come up with something ... > > The world is waiting for a decent networked file system with > > o Security
A fast symetric block cypher (IDEA or blowfish), something like ssh ....
> o Replication support
Active or pasive ? Could we have a list of hosts that are all keeping up to date with each other, and we talk to one unless it fails, then the next in the list, then .... _OR_ can we talk to all the servers that we've been told about, at the same time, ie if we've 5 servers, and we're getting a 5 Mb file we can get 1 Mb from each (1st block from the first, second bolck from the second, 3rd from the third ....), this could get very iccky indead.
> o Fast bulk transfer
multiple servers would keep this fast ...
> o Low latency >
... and this low ...
> and bonus points for parallelism across multiple servers (watch the parallel > fsck problem). >
Yep, could be very iccky, as could serving requests on multiple servers for parts of files.
> I don't see any reason why the Linux community shouldnt write it. >
I don't see why we should let anyone else get there grubby patents on the idea before us ....
> Alan > >
It could be writen so that we could only need to know one server, and make an encryption connection to that one, authenticate our selves, then when the server knows it can trust us, it tells us a list of servers that we can use. Hmm, more servers for some preferred clients ?, all for mirrors/other members of the server group.
Hmm, you could also have dynamic reconfiguration of the servers/clients to take advantage of new servers coming up, and avoid trying to talk to broken/crashed/unsynced hosts (unsynced, in that it crashed/broke, but is coming back up).
Oh, and passing all requests through the one server that keeps the meta data up to date, with all actual data coming either from a bank of boxes, or from the lone server ....
Having subsecond creation/modification times would be good (all remote host times too), and making file creation/modification syncronus would make caching trival, not the whole write, just the "I want to change/create this file, give me a new mtime for it and I'll send you the data asyncronsly" bit, we could even be told that the data we have is out of date (how do we handle this at the moment, take the newer as what should be there, and loose the changes that mr third party made ?).
We'll proberbly need annother fs (ext3 ?;) to get the subsecond times in, I don't know tho.
Bryn -- PGP key pass phrase forgotten, \ Overload -- core meltdown sequence again :( | initiated. / This space is intentionally left | blank, apart from this text ;-) \____________________________________
|  |