Re: [Vrs-development] Who's doing the distributed filesystem?

[Bill Lance]

--- Eric Altendorf <address@hidden> wrote:
> On Monday 29 April 2002 05:52, Bill Lance wrote:
> > That's my thought here also, Eric.  It's basically
> a
> > type 10 RAID system with encrypted blocks and
> spread
> > accross the network
> 
> The difference being that it can take seconds for
> the disks to talk to each 
> other, disks can go on and offline at will, disks
> could theoretically 
> masquerade under false identities, and files need to
> be distributed and 
> fragmented and mirrored in rather particular ways. 
> It all makes it very 
> difficult to guarantee the ACID qualities of file
> operations...not 
> impossible, just difficult.
> 

We are indeed incuring substantial overhead in making
a distributed, robust, secure and private data
storage. But, so far, this is the only way we have
been able to figure a way of achiving those
objectives.  And we are most certainly open to
improvements and other approaches.  




> 
> OK.  So, first of all, the document makes no mention
> of the desired file 
> semantics...that's probably the first thing one
> needs to know before 
> designing a filesystem. :-)
> 
> Do we want Unix semantics (writes and reads are
> serialized so the
> effects of a write are immediately visible)?  This
> requires that when a
> write is issued on a particular virtual block, all
> LDS nodes hosting
> that block must update the block's value and
> confirm, probably using a
> two phase commit protocol, before the write can be
> deemed "complete".
> Not only will this make writes very slow, but it
> will make reads from
> that same filesystem block wait until the write is
> complete, thus
> slowing down the filesystem as a whole.  We should
> be able to make reads
> pretty fast with caching, but only at the expense of
> making writes
> potentially very expensive.  Is this OK?
> 

I THINK it's OK.  

Let me ramble a bit here to try to sort some of this
out.  At the most basic level, the Repository is
something less than a complete virtual FS for an LDS,
since the LDS code ityself is not stored in it.  That
remains on disk, using the hosts native FS. 
Presumably, it all will be isolated into it's own root
structure, but it's still in the native FS.

Early on, we thought of it as the complete FS for the
VRS itself, not the LDS, but the virtual server that
those LDS's project.  The idea is to duplicate the
necessary api's of the OSFS in the Repositiry Manager,
then direct the LDS functions to the RM instead of the
OS.

As you point out, thought, we would still need some
means of doing the same thing with plugin code, such
as Apache.  These are going to have to see both the
host's FS for parts of itself, as well as the RM FS
for data.

There is another perspective also.  The repository can
be thought of as an archive facility.  During an
actual service fulfilment session, the RMFS is not in
active use.  Here is the sequence:

   1 - service request arrives at public LDS.
   2 - request is deligated to LDS x.
   3 - LDS x loads all required files from RMFS.
   4 - service request is fulfilled from cached files.
   5 - if required, files are writen back to the RMFS.


There are obvious issues still to be resolved with
this, but the point may be that any dynamic data
handling for a single session is done out of the local
cache and not the RMFS.  

> 
> Also, I am still unclear on how the services
> interact with the filesystem.  
> It's not a kernel-level filesystem, so it will not
> be transparent to users.  
> How will we make arbitrary services (eg Apache) read
> and write on the virtual 
> filesystem?
> 

An excellant question ..

could we mount it as a device?


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com