Note that we need to consider xlators on brick stack too. I've added
maintainers/peers of xlators on brick stack. Please explicitly ack/nack
whether this patch affects your component.
For reference, following are the xlators loaded in brick stack
storage/posix
features/trash
Hi,
This mail is regarding the gfproxy feature, please go through the same and let
us know your thoughts.
About the gfproxy feature:
---
As per the current architecture of Gluster, the client is more intelligent and
has all the clustering logic. This
Hi, I think this is the line limiting brick count:
https://github.com/gluster/glusterfs/blob/c136024613c697fec87aaff3a070862b92c57977/cli/src/cli-cmd-parser.c#L84
Can gluster-devs increase this limit? Should I open a github issue?
On Mon, Aug 21, 2017 at 7:01 PM, Serkan Çoban
This is the command line output:
Total brick list is larger than a request. Can take (brick_count )
Usage: volume create [stripe ] [replica ]
I am testing if a big single volume will work for us. Now I am
continuing testing with three volumes each 13PB...
GlusterFS Coverity covscan results are available from
http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2017-08-23-5b14c11d
___
Gluster-devel mailing list
Gluster-devel@gluster.org
In your case for 5500 bricks cli is failing the command saying "Total brick
list is larger than a request. Can take (brick_count )".
RCA..
gluster cli while parsing the command takes the wordcount and based on that
it compares the statically initialized size as you have point out in
Thanks Pranith and Ashish for your inputs.
- Original Message -
> From: "Pranith Kumar Karampuri"
> To: "Ashish Pandey"
> Cc: "Raghavendra Gowdappa" , "Xavier Hernandez"
> , "Gluster Devel"
>
Raghavendra,
As Ashish mentioned, there aren't any known problems if upper xlators
don't send lookups in EC at the moment.
On Wed, Aug 23, 2017 at 9:07 AM, Ashish Pandey wrote:
> Raghvendra,
>
> I have provided my comment on this patch.
> I think EC will not have any