[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [DotGNU]Comments on distributed file system DFS
From: |
Peter Waldschmidt |
Subject: |
RE: [DotGNU]Comments on distributed file system DFS |
Date: |
Wed, 12 Sep 2001 09:20:00 -0400 |
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