RE: [DotGNU]Comments on distributed file system DFS

[Peter Waldschmidt]

Another issue to consider is reliability.  If data is truly to be
"striped" across several nodes (which I am assuming could be distributed
across the Internet), then the reliability statistics have a
multiplicative effect.  i.e. if only one machine crashes, most, if not
all, of the data is taken offline.

I think that this scheme, in order to be successful, must include a
strategy for automatically duplicating data across nodes in an
intelligent manner.  There are papers and examples of this.

Peter Waldschmidt

-----Original Message-----
From: Karthik Kumar [mailto:address@hidden 
Sent: Wednesday, September 12, 2001 9:08 AM
To: address@hidden
Cc: address@hidden
Subject: [DotGNU]Comments on distributed file system DFS

Hello,

   The one proposed by Myriddian seems to be
interesting. Let me express my commments on that.

--- address@hidden wrote:

> With this DFS will allow easily extendable network  
> file systems by adding a new machine to share the  
> mount.

Example: 

(DFS mount) /var/opt <-------------- 
|------ Machine 1 (33%) /usr/local/dfs
|------ Machine 2 (33%) /usr/local/dfs
|------ Machine 3 (33%) /usr/local/dfs

  Lets consider a network and I want to know where
will the data be present ? [ In conventional systems,
just like a /etc/fstab file provides the file system
info , where will be this file be located ? ]. More
precisely, I could say we could have machines that
could be categorised in two - one that actually
contains and handles the data ( similar to machine 1,
m/c 2, m/c 3 etc ] and the other kind of systems which
do not store any particular data but rather is
responsible for maintaining the data. 
   But I feel a more better option could be getting
away from the centralized menchanism but distributing
the knowledge of which system or machine got which
mount point . 

(DFS mount) /var/opt <-------------- 
|------ Machine 1 (33%) /usr/local/dfs
|------ Machine 2 (33%) /usr/local/dfs
|------ Machine 3 (33%) /usr/local/dfs

Now that being the case, in addition to the one
mentioned above we also need to know which /var/opt we
are referring to. In that case, what we get is a
cluster of machines representing one single system as
a whole. So to identify a mount point we could give an
unique ID to a group of such clusters.  So the world
will not have individual machines but only groups as
such. 
  So in addition to a machine ID , every machine also
got a group ID. And now listing of files could not be
done merely as : 

ls /var/opt/listme.txt  but as
ls <groupID>/var/opt/listme.txt .

Now storing this <groupID> kind of a thing could be
done something like a DNS system. 
   My second question is regarding the quota mentioned
for the partitition. Is that static ? I think it is
better if it is not. But if it is dynamic, how is that
going to get implemented ? Increasing the size may not
be a problem, I suppose, with better data structures.
If we are decreasing the size then how are we going to
handle the data that gets squeezed by it ? 
   The last but the most important thing is regarding
the nature of the file system. Being a distributed
file sytem, we got to modify our conventional -
<tape> === <boot><super> <inodes> <disk blocks>  
look.
In fact the journalling file systems also contain -
meta-meta-data ( data about inodes ) to improve
performance. I am referring to ReiserFS, a journalling
file sytem. Please visit http://www.namesys.com for
more details regarding ReiserFS. Probably we also put
in much more meta-data before the actual disk blocks
to take care of the overhead mentioned. I think I am
typing a bit large and so will cut it short here and
discuss the possible data structure design in my next
mail.

Thanks.
Karthik Kumar A.

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo!
Messenger
http://im.yahoo.com
_______________________________________________
Developers mailing list
address@hidden
http://subscribe.dotgnu.org/mailman/listinfo/developers