Re: [Gluster-devel] Question about Glusterfs

[Krishna Srinivas]

Antonio,

Adding to what Amar has said...

It is better to have unify in all the clients for better performance.
I think you are worried about maintenance of spec file in all the clients,
check the -s -P options to glusterfs client, using which you can
specify the server from which the client should fetch the spec
file. On the server you can specify the path to client spec file
(which will be fetched by clients by -s -P option) using
"option client-volume-filename <path/filename>" So you can
define the client spec at a single place for all the clients
(assuming all the clients should have the same spec file)

Regards
Krishna

On Wed, Apr 9, 2008 at 2:15 PM, Amar S. Tumballi <address@hidden> wrote:
> Hi Antonio,
>   Client side unify is simple and easier approach in my opinion. But
>  depending on how your i/o pattern is, how your network topology is, you may
>  want to change it. but to start with, unify on client side is a better
>  approach.
>
>  Regards,
>  Amar
>
>
>
>  On Wed, Apr 9, 2008 at 1:41 AM, Antonio González <
>  address@hidden> wrote:
>
>  > Hello all,
>  >
>  >
>  >
>  > I try to think about a GlusterFS file system, where we have a lot of
>  > servers
>  > and clients. In my firsts test I place the unify translator in a central
>  > server, because I think that is more scalable that a schema where the
>  > unify
>  > translator were in the client, because it would necessary that the clients
>  > knows the bricks exported in the full system.
>  >
>  >
>  >
>  > What schema is better, a central unify or a unify client…??
>  >
>  >
>  >
>  >
>  >
>  > _______________________________________________
>  > Gluster-devel mailing list
>  > address@hidden
>  > http://lists.nongnu.org/mailman/listinfo/gluster-devel
>  >
>
>
>
>  --
>  Amar Tumballi
>  Gluster/GlusterFS Hacker
>  [bulde on #gluster/irc.gnu.org]
>  http://www.zresearch.com - Commoditizing Supercomputing and Superstorage!
>
> _______________________________________________
>  Gluster-devel mailing list
>  address@hidden
>  http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>