Re: [Vrs-development] Distributed Filesystem

[Chris Smith]

Yep - Bill and I thought of the RM as providing a Virtual File System.
However, it needs to be strongly derived from RAID technology so that there 
is multiple redundancy across 2+ LDS's.

It may be worth noting that Goldwater domains are namespaced, and so you can 
explicitly call a Goldwater LDS function at a particular LDS if required.
Thus, given an LDS function 'get_file_sector( ... )' , if a file sector you 
want is at an LDS namespaced by bobs.lds.thingy, then the LDS wanting the 
sector would invoke 'get_file_sector(), but implicitly specify 
bobs.lds.thingy in the request.....
The RM just needs to keep track of what sectors are deployed where and 
Goldwater along with some cunning abstraction will sort out the rest.


How we get file data distrubted and pushed around the LDS is another question 
entirely........  Just thing of LDS's that come and go....... shudder........


Chris


On Thursday 11 July 2002 04:47, Ian Fung wrote:
> first question is whether the vrs is going to house a distributed file
> *system*? or a distributed file *repository*? in my mind, a distributed
> file repository doesnt have the same properties as a dfs. a file system
> needs to be consistent and sychronized. if we indeed do want the vrs to
> be a file system which i believe we do and should, then we're going to
> have to define what that really means. obviously, it is impossible to
> create a file system by the traditional definition in a distributed
> environment. what we can do is try to maintain consistency and
> sychronization as best we can. the trickest part is to decide what
> happens when enough LDS leaves the vrs such that data is lost even if we
> use redundancy. the mechanism by which modifications are propagated to
> all LDS's is not really the main issue. we should probably think about
> how we negotiate conflicts, deal with lost information, and stuff like
> that.
>
> although this is another issue entirely, it may help with dealing with
> lost data. in the vrs, maybe we can intelligently store data on LDS
> nodes that actually use them (when possible). the idea is to monitor
> usage of files in a given time slot (epoch), then at the end of the
> epoch push files to (or near) LDS's that have been using em. just an
> idea.
>
>
> _______________________________________________
> Vrs-development mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/vrs-development

-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk