Re: RE : RE : RE : user question : multiple clients concurrent access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> OK.
> One last point : I tried the rr scheduler with default settings.
> To unleash storage bandwidth, is it possible to set the round-robin or the
> random scheduler to use a volume-based policy instead of a time-based policy
> (that is, "switch to the other volumes every megabyte wrote" instead of
> "switch to the other volume every 10 seconds") ?
> If so, what is the lowest value I could use ? (If possible, I'd like to
> test a 1MB round-robin or random sched).
>

the round robin and random  schedule every create.. so every new file goes
to the next node / random node. The 10 seconds is used to update the stats
(which, in the case of random/rr only determines the min-disk-space check)

Also, from a network point of view, a simple client/server setup did not
> exceed 35MB/s with a bonnie++ test. (no options set to bonnie, just the
> directory to use, and a GbE network) whereas a local test (server and client
> on the same computer) shows a result of nearly 60MB/s.
> What is the theorical overhead implied by GlusterFS ?
> Can I expect to get something close to the theorical values (100MB/s for
> the network connection limited by the 80MB/s of the FC RAID) or should ?
>
probably not with bonnie++, it was not written from network FS  point of
view. and our current focus is not really on getting good bonnie++ numbers,
but towards scaling out (which is why you want a clustered filesystem)

Using TCP transport and a raw, untuned setup, GlusterFS seems equal to NFS
> (with the great advantage of storage aggregation for GlusterFS)
>
> Note : is it correct to say that "namespace" is like "metadata" ? (I'm
> lost in what a namespace can be)
>

namespace is not 'metadata' in the regular sense. namespace is just a cache.
if you lose glusterfs namespace, you lost nothing (it will rebuild on
demand). if namespace were to be 'metadata', then losing namespace would
make the rest of the nodes a big blob of 1s and 0s, and not files and
folders.


thanks,
avati


-- 
If I traveled to the end of the rainbow
As Dame Fortune did intend,
Murphy would be there to tell me
The pot's at the other end.


[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux