Re: [Gluster-devel] Release 3.12.3 : Scheduled for the 10th of November

[Jiffin Tony Thottan]

Hi,

I am planning to do 3.12.3 release today 10:00 pm IST (4:30 pm GMT).

Following bugs is removed from tracker list

Bug 1501235 - [SNAPSHOT] Unable to mount a snapshot on client -- based 
on discussion on gerrit, it can be target for 3.13

instead of the 3.12.x release

Bug 1507006 - Read-only option is ignored and volume mounted in r/w mode 
-- assigned to none, no progress in master bug as well,


will be tracked as part of 3.12.4

Regards,

Jiffin


On 06/11/17 11:52, Jiffin Tony Thottan wrote:


Hi,

It's time to prepare the 3.12.3 release, which falls on the 10th of
each month, and hence would be 10-11-2017 this time around.

This mail is to call out the following,

1) Are there any pending *blocker* bugs that need to be tracked for
3.12.3? If so mark them against the provided tracker [1] as blockers
for the release, or at the very least post them as a response to this
mail

2) Pending reviews in the 3.12 dashboard will be part of the release,
*iff* they pass regressions and have the review votes, so use the
dashboard [2] to check on the status of your patches to 3.12 and get
these going

3) I have made checks on what went into 3.10 post 3.12 release and if
these fixes are already included in 3.12 branch, then status on this 
is *green*

as all fixes ported to 3.10, are ported to 3.12 as well.

There are two patches under this category

a.) https://review.gluster.org/#/c/18422/ -- Kaleb has -1 from me and 
Niels


b.) https://review.gluster.org/#/c/18459/ -- @Gunther, can u pls 
trigger regression for this patch(give verified +1 from gerrit)



Thanks,
Jiffin

[1] Release bug tracker:
https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.12.3

[2] 3.12 review dashboard:
https://review.gluster.org/#/projects/glusterfs,dashboards/dashboard:3-12-dashboard 





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

Re: [Gluster-devel] RFC: FUSE kernel features to be adopted by GlusterFS

[Jeff Darcy]

> So - nothing inherent to libfuse and nothing that would be relevant as
> of today.
> 
> But then, let me put it like this: what reason could we have to *not* go
> with xglfs in 4.0? It's true that the deliverables are present in libfuse
> and
> libgfapi and it's just a thin glue. As such it seems to be almost devoid
> of design concerns, it just bridges the two interfaces in a
> straightforward manner. Superficially it seems to be a superior approach
> - what snag holds us back to embrace it wholeheartedly?

What about https://review.gluster.org/#/c/3341/ and its antecedents? 
Libfuse used to be unable to deal with SELinux's behavior of trying to
issue a getxattr from within the mount call.  Have either libfuse or
SELinux fixed that?  There might be other local changes that we'd need
to verify in similar fashion.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] RFC: FUSE kernel features to be adopted by GlusterFS

[Csaba Henk]

On Thu, Nov 9, 2017 at 1:33 PM, Niels de Vos  wrote:
>
> On Thu, Nov 09, 2017 at 01:04:48AM +0100, Csaba Henk wrote:
> > Hello list,
> >
> > here is an overview of recent additions to the
> > FUSE protocol that are not yet supported by
> > the GlusterFS FUSE implementation and
> > what sh/could be done about them.
> >
> > https://docs.google.com/document/d/1VGxMC7Db7Rdd19VXlBe0tI-frdjICJdzxx4EsntuPDU/edit
> >
> > Comments on the doc or in this thread are most
> > warmly welcome.
>
> I would really love to see us use libfuse (not a forked or bundled
> version) with libgfapi. That should make it easier for us to follow
> upstream enhancements. A proof of concept was once written by Olegsandr
> Natalenko and is available at https://github.com/gluster/xglfs
>
> Maintaining three access xlators/protocols (FUSE, gNFS, gfapi) adds a
> lot of overhead. Having a single one (gfapi) with additional projects
> for the other 'bindings' to protocols would be much better to maintain.
>
> There was a bug or issue for this somewhere... I'm not able to find it
> though.

I harbored an unresolved unease about depending on libfuse, kind of a
memory of a thought that it is does not do good to us to have it, but
forgot about the reason. Recently I managed to pin it down - it was from
the pre-acquisition days, when on customers' setups libfuse was either
unavailable or only a fairly out of date version, which was the cause
of many headaches.

So - nothing inherent to libfuse and nothing that would be relevant as
of today.

But then, let me put it like this: what reason could we have to *not* go
with xglfs in 4.0? It's true that the deliverables are present in libfuse and
libgfapi and it's just a thin glue. As such it seems to be almost devoid
of design concerns, it just bridges the two interfaces in a
straightforward manner. Superficially it seems to be a superior approach
- what snag holds us back to embrace it wholeheartedly?

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

Re: [Gluster-devel] reflink support for glusterfs and gluster-block using it for taking snapshots

[Niels de Vos]

On Tue, Nov 07, 2017 at 05:59:32PM +0530, Pranith Kumar Karampuri wrote:
> On Tue, Nov 7, 2017 at 5:16 PM, Niels de Vos  wrote:
> 
> > On Tue, Nov 07, 2017 at 07:43:17AM +0530, Pranith Kumar Karampuri wrote:
> > > hi,
> > >  I just created a github issue for reflink support
> > > (#349) in glusterfs. We
> > > are intending to use this feature to do block snapshots in gluster-block.
> > >
> > > Please let us know your comments on the github issue. I have added the
> > > changes we may need for xlators I know a little bit about. Please help in
> > > identifying gaps in implementing this FOP.
> >
> > For gluster-block it may be easier to have snapshot support in
> > tcmu-runner instead? The qcow2 format would be ideal, and is in use by
> > different Virtual Machine approaches running on Gluster already. There
> > even is an upstream issue open for it:
> >   https://github.com/open-iscsi/tcmu-runner/issues/32
> >
> > Contributing towards this might be quicker than implementing file
> > snapshot support in Gluster?
> >
> 
> We tried that route by talking Fam Zheng, but the solution won't be
> delivered in the timelines we are looking for.
> So we went with this approach.

Ok, I am not sure if adding support for reflink in Gluster has an
immediate benefit. It surely would be a great feature to have, but I do
not know if it will land in enterprise kernels soon.

That said, I opened a GitHub issue to get reliable snapshot support in
gluster-block. It describes an idea of the interface that could be
implemented now already, without relying on reflink.

  https://github.com/gluster/gluster-block/issues/42

Obviously there is a need to sync/freeze data through tcmu-runner. This
might require implementing a fsfreeze(8) like command in targetcli and
tcmu-runner.

Comments most welcome!
Niels
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Coverity covscan for 2017-11-09-9eea2630 (master branch)

[staticanalysis]

GlusterFS Coverity covscan results are available from
http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2017-11-09-9eea2630
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] RFC: FUSE kernel features to be adopted by GlusterFS

[Niels de Vos]

On Thu, Nov 09, 2017 at 01:04:48AM +0100, Csaba Henk wrote:
> Hello list,
> 
> here is an overview of recent additions to the
> FUSE protocol that are not yet supported by
> the GlusterFS FUSE implementation and
> what sh/could be done about them.
> 
> https://docs.google.com/document/d/1VGxMC7Db7Rdd19VXlBe0tI-frdjICJdzxx4EsntuPDU/edit
> 
> Comments on the doc or in this thread are most
> warmly welcome.

I would really love to see us use libfuse (not a forked or bundled
version) with libgfapi. That should make it easier for us to follow
upstream enhancements. A proof of concept was once written by Olegsandr
Natalenko and is available at https://github.com/gluster/xglfs

Maintaining three access xlators/protocols (FUSE, gNFS, gfapi) adds a
lot of overhead. Having a single one (gfapi) with additional projects
for the other 'bindings' to protocols would be much better to maintain.

There was a bug or issue for this somewhere... I'm not able to find it
though.

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

[Gluster-devel] RFC: FUSE kernel features to be adopted by GlusterFS

[Csaba Henk]

Hello list,

here is an overview of recent additions to the
FUSE protocol that are not yet supported by
the GlusterFS FUSE implementation and
what sh/could be done about them.

https://docs.google.com/document/d/1VGxMC7Db7Rdd19VXlBe0tI-frdjICJdzxx4EsntuPDU/edit

Comments on the doc or in this thread are most
warmly welcome.

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

Re: [Gluster-devel] master broken.

[Hari Gowtham]

Thanks. It works now.

Sorry for the late response.

On Wed, Nov 8, 2017 at 12:30 AM, Atin Mukherjee  wrote:
> Please pull in the latest changes. It’s fixed now.
>
> On Tue, 7 Nov 2017 at 23:41, Hari Gowtham  wrote:
>>
>> Hi,
>>
>> I have been trying to install the rebase and i see this error
>>
>>
>> server.c: In function ‘init’:
>> server.c:1205:15: error: too few arguments to function
>> ‘rpcsvc_program_register’
>>  ret = rpcsvc_program_register (conf->rpc,
>> _0_fop_prog);
>>^~~
>> In file included from server.h:17:0,
>>  from server.c:16:
>> ../../../../rpc/rpc-lib/src/rpcsvc.h:426:1: note: declared here
>>  rpcsvc_program_register (rpcsvc_t *svc, rpcsvc_program_t *program,
>>  ^~~
>> make[5]: *** [Makefile:571: server.lo] Error 1
>> make[4]: *** [Makefile:463: all-recursive] Error 1
>> make[3]: *** [Makefile:463: all-recursive] Error 1
>> make[2]: *** [Makefile:471: all-recursive] Error 1
>> make[1]: *** [Makefile:603: all-recursive] Error 1
>> make: *** [Makefile:494: all] Error 2
>>
>> I can see this points to the changes in this patch
>> https://review.gluster.org/#/c/18547/
>> which was merged lately.
>>
>> can someone check thier local master is it install fine to confirm?
>>
>> --
>> Regards,
>> Hari Gowtham.
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
> --
> - Atin (atinm)



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

Re: [Gluster-devel] Tie-breaker logic for blocking inodelks/entrylks

[Pranith Kumar Karampuri]

I got a +1 from Ashish and Xavi for the idea. I will wait for people from
other time zones to comment on the same and will start implementing the
solution tomorrow morning IST. I am kind of in a hurry to get this done,
preferably by end of this week.

Thanks in advance.

On Thu, Nov 9, 2017 at 8:56 AM, Pranith Kumar Karampuri  wrote:

> This github issue  talks
> about the logic for implementing tie-breaker logic for blocking
> inodelks/entrylks. Your comments are welcome on the issue.
>
> --
> Pranith
>



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

[Gluster-devel] Tie-breaker logic for blocking inodelks/entrylks

[Pranith Kumar Karampuri]

This github issue  talks
about the logic for implementing tie-breaker logic for blocking
inodelks/entrylks. Your comments are welcome on the issue.

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