Re: [Gluster-devel] Need inputs on patch #17985

[Raghavendra G]

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
features/changetimerecorder
features/changelog
features/bitrot-stub
features/access-control
features/locks
features/worm
features/read-only
features/leases
features/upcall
performance/io-threads
features/selinux
features/marker
features/barrier
features/index
features/quota
debug/io-stats
performance/decompounder
protocol/server


For those not following this thread, the question we need to answer is,
"whether the xlator you are associated with works fine if a non-lookup fop
(like open, setattr, stat etc) hits it without a lookup ever being done on
that inode"

regards,
Raghavendra

On Wed, Aug 23, 2017 at 11:56 AM, Raghavendra Gowdappa 
wrote:

> Thanks Pranith and Ashish for your inputs.
>
> - Original Message -
> > From: "Pranith Kumar Karampuri" 
> > To: "Ashish Pandey" 
> > Cc: "Raghavendra Gowdappa" , "Xavier Hernandez" <
> xhernan...@datalab.es>, "Gluster Devel"
> > 
> > Sent: Wednesday, August 23, 2017 11:55:19 AM
> > Subject: Re: Need inputs on patch #17985
> >
> > 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 issue with this approach.
> > > However, I would welcome comments from Xavi and Pranith too for any
> side
> > > effects which I may not be able to foresee.
> > >
> > > Ashish
> > >
> > > --
> > > *From: *"Raghavendra Gowdappa" 
> > > *To: *"Ashish Pandey" 
> > > *Cc: *"Pranith Kumar Karampuri" , "Xavier
> Hernandez"
> > > , "Gluster Devel" 
> > > *Sent: *Wednesday, August 23, 2017 8:29:48 AM
> > > *Subject: *Need inputs on patch #17985
> > >
> > >
> > > Hi Ashish,
> > >
> > > Following are the blockers for making a decision on whether patch [1]
> can
> > > be merged or not:
> > > * Evaluation of dentry operations (like rename etc) in dht
> > > * Whether EC works fine if a non-lookup fop (like open(dir), stat,
> chmod
> > > etc) hits EC without a single lookup performed on file/inode
> > >
> > > Can you please comment on the patch? I'll take care of dht part.
> > >
> > > [1] https://review.gluster.org/#/c/17985/
> > >
> > > regards,
> > > Raghavendra
> > >
> > >
> >
> >
> > --
> > Pranith
> >
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
> --
> Raghavendra G
>
> 
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] gfproxy

[Poornima Gurusiddaiah]

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 approach has its own pros and cons. In 
several use cases, it is desirable to have all this clustering logic on the 
server side and have, as thin client as possible. Eg: Samba, Qemu, Block device 
export etc. This makes the upgrades easier, and is more scalable as the 
resources consumed by thin clients are much less than normal client. 

Approach: 
Client volfile is split into two volfiles: 
1. Thin client volfile: master(gfapi/Fuse) followed by Protocol/client 
2. gfproxyd volfile: protocol/server, performance xlators, cluster xlators, 
protocol/servers. 
With this model, the thin client connects to gfproxyd and glusterd(like 
always). gfproxyd connects to all the bricks. The major problem with this is 
performance, when the client and gfproxyd are not co-located. 


What is already done by Facebook: 
- 
1. Volgen code for generating thin client volfile and the gfproxyd daemon 
volfile. 
2. AHA translator on the thin client, so that on a restart/network disruptions 
between thin client and gfproxyd, we retry fops and the client doesn't become 
inaccessible. 


What remains to be done: 
- 
1. Glusterd managing the gfproxyd 
Currently the gfproxy daemon listens on 4 port, if we want to run multiple 
gfproxyd (one per volume) 
2. Redo the volgen and daemon management in glusterd2 
- Ability to be able to run daemons on subset of cluster nodes 
- ssl 
- Validate with other features like snap, tier, 
3. Graph switch for the gfproxyd 
4. Failover from one gfproxyd to another 
5. Less resource consumption on thin client - Memory and threads 
6. Performance analysis 

Issue: https://github.com/gluster/glusterfs/issues/242 

Regards, 
Poornima 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Brick count limit in a volume

[Serkan Çoban]

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  wrote:
> Hi,
> Gluster version is 3.10.5. I am trying to create a 5500 brick volume,
> but getting an error stating that  bricks is the limit. Is this a
> known limit? Can I change this with an option?
>
> Thanks,
> Serkan
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Brick count limit in a volume

[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...
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Coverity covscan for 2017-08-23-5b14c11d (master branch)

[staticanalysis]

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
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Brick count limit in a volume

[Gaurav Yadav]

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
https://github.com/gluster/glusterfs/blob/c136024613c697fec87aaff3a07086
2b92c57977/cli/src/cli-cmd-parser.c#L84.

While doing so when
wordcount increases which is happening in your case cli fails the command
with the above message.
In the error message you are getting , this is coming based on the
parsing logic.

I believe having dynamically allocated size based on max_brick_path(4096) *
no_of_bricks will solve the issue.

Thanks
Gaurav

On Wed, Aug 23, 2017 at 11:23 AM, Serkan Çoban 
wrote:

> 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...
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Need inputs on patch #17985

[Raghavendra Gowdappa]

Thanks Pranith and Ashish for your inputs.

- Original Message -
> From: "Pranith Kumar Karampuri" 
> To: "Ashish Pandey" 
> Cc: "Raghavendra Gowdappa" , "Xavier Hernandez" 
> , "Gluster Devel"
> 
> Sent: Wednesday, August 23, 2017 11:55:19 AM
> Subject: Re: Need inputs on patch #17985
> 
> 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 issue with this approach.
> > However, I would welcome comments from Xavi and Pranith too for any side
> > effects which I may not be able to foresee.
> >
> > Ashish
> >
> > --
> > *From: *"Raghavendra Gowdappa" 
> > *To: *"Ashish Pandey" 
> > *Cc: *"Pranith Kumar Karampuri" , "Xavier Hernandez"
> > , "Gluster Devel" 
> > *Sent: *Wednesday, August 23, 2017 8:29:48 AM
> > *Subject: *Need inputs on patch #17985
> >
> >
> > Hi Ashish,
> >
> > Following are the blockers for making a decision on whether patch [1] can
> > be merged or not:
> > * Evaluation of dentry operations (like rename etc) in dht
> > * Whether EC works fine if a non-lookup fop (like open(dir), stat, chmod
> > etc) hits EC without a single lookup performed on file/inode
> >
> > Can you please comment on the patch? I'll take care of dht part.
> >
> > [1] https://review.gluster.org/#/c/17985/
> >
> > regards,
> > Raghavendra
> >
> >
> 
> 
> --
> Pranith
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Need inputs on patch #17985

[Pranith Kumar Karampuri]

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 issue with this approach.
> However, I would welcome comments from Xavi and Pranith too for any side
> effects which I may not be able to foresee.
>
> Ashish
>
> --
> *From: *"Raghavendra Gowdappa" 
> *To: *"Ashish Pandey" 
> *Cc: *"Pranith Kumar Karampuri" , "Xavier Hernandez"
> , "Gluster Devel" 
> *Sent: *Wednesday, August 23, 2017 8:29:48 AM
> *Subject: *Need inputs on patch #17985
>
>
> Hi Ashish,
>
> Following are the blockers for making a decision on whether patch [1] can
> be merged or not:
> * Evaluation of dentry operations (like rename etc) in dht
> * Whether EC works fine if a non-lookup fop (like open(dir), stat, chmod
> etc) hits EC without a single lookup performed on file/inode
>
> Can you please comment on the patch? I'll take care of dht part.
>
> [1] https://review.gluster.org/#/c/17985/
>
> regards,
> Raghavendra
>
>


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel