lkml.org 
[lkml]   [1996]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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 ;-)
\____________________________________

\
 
 \ /
  Last update: 2005-03-22 13:37    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site