Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[sriram]

Hi Avra,



Thanks for the reply, 



But the problem I see here is the previous patch set sent would'nt
compile individually. So, I merged the changes into a single patch ,
which i'd posted today. Is it ok to drop all the previous posted patches
and consider from the new one? Please suggest.


Sriram





On Thu, Dec 15, 2016, at 12:45 PM, Avra Sengupta wrote:

> Hi Sriram,

> 

>  I have already provided comments on the new patch. It seems this new
>  patch while addressing merge cloflicts, has undone some previous
>  patches. I suggest you send this patch on top of the previous patchset
>  (http://review.gluster.org/#/c/15554/1) instead of creating a new
>  one. This will allow you to view the diff between the new version and
>  the previous version, and will give u an idea if the diff is
>  something that you added in the patch or got added as part of merge
>  conflict.
> 

>  Regards,

>  Avra

> 

>  On 12/15/2016 12:09 PM, sri...@marirs.net.in wrote:

>> Hi Avra, 

>> 

>> I've update the patch according to the comments below. And created a
>> single patch which does the initial modularization. Fixed the tab-
>> >space issue as well. I've raised a new review request for the same
>> bug ID here:
>> http://review.gluster.org/#/c/16138/

>> 

>> Added, Rajesh and You as the reviewers, let me know if I need to do
>> anything else.
>> 

>> Could you have a look and let me know? 

>> 

>> (Sorry for the delay in creating this) 

>> 

>> Sriram

>> 

>> On Thu, Oct 13, 2016, at 12:15 PM, Avra Sengupta wrote:

>>> Hi Sriram,

>>> 

>>> The point I was trying to make is, that we want that each patch
>>> should compile by itself, and pass regression. So for that to
>>> happen, we need to consolidate these patches(the first three) into
>>> one patch, and have the necessary make file changes into that
>>> patch too.
>>> 

>>> http://review.gluster.org/#/c/15554/

>>> http://review.gluster.org/#/c/1/

>>> http://review.gluster.org/#/c/15556/

>>> 

>>> That will give us one single patch, that contains the changes of
>>> having the current code moved into separate files, and it should get
>>> compiled on it's own, and should pass regression. Also, we use
>>> spaces, and not tabs in the code. So we will need to get those
>>> changed too. Thanks.
>>> 

>>> Regards,

>>> Avra

>>> 

>>> On 10/12/2016 10:46 PM, sri...@marirs.net.in wrote:

 Hi Avra, 

 

 Could you let me know on the below request? 

 

 Sriram

 

 

 On Tue, Oct 4, 2016, at 11:16 AM, sri...@marirs.net.in wrote:

> Hi Avra,

> 

> I checked the comment, the series of patches, (There are nine
> patches) for which I've posted for a review below. They've all the
> necessary makefiles to compile.
> 

> Would you want me to consolidate all'em and post them as a single
> patch? (I thought that would be a little confusing, since it'd
> changes with different intentions).
> 

> Sriram

> 

> 

> On Mon, Oct 3, 2016, at 03:54 PM, Avra Sengupta wrote:

>> Hi Sriram,

>> 

>> I posted a comment into the first patch. It doesn't compile by
>> itself. We need to update the respective makefiles to be able to
>> compile it. Then we can introduce the tabular structure in the
>> same patch to have the framework set for the zfs snapshots.
>> Thanks.
>> 

>> Regards,

>> Avra

>> 

>> On 09/30/2016 10:24 AM, sri...@marirs.net.in wrote:

>>> Hi Avra, 

>>> 

>>> Could you have a look into the below request? 

>>> 

>>> Sriram 

>>> 

>>> 

>>> On Fri, Sep 23, 2016, at 04:10 PM, sri...@marirs.net.in wrote:

 Hi Avra, 

 

 Have submitted the patches for Modularizing snapshot, 

 

 https://bugzilla.redhat.com/show_bug.cgi?id=1377437

 

 This is the patch set: 

 

  http://review.gluster.org/15554 This patch follows the
  discussion from the gluster-devel mail chain of, ...
  http://review.gluster.org/1 Referring to bugID:1377437,
  Modularizing snapshot for plugin based modules.
  http://review.gluster.org/15556 - This is third patch in the
  series for the bug=1377437
  http://review.gluster.org/15557 [BugId:1377437][Patch4]:
  Refering to the bug ID,
  http://review.gluster.org/15558 [BugId:1377437][Patch5]:
  Refering to the bug ID,
  http://review.gluster.org/15559 [BugId:1377437][Patch6]:
  Refering to the bug ID,
  http://review.gluster.org/15560 [BugId:1377437][Patch7]:
  Refering to the bug ID. * This patch has some minor ...
  http://review.gluster.org/15561 [BugId:1377437][Patch8]:
  Refering to the bug ID, this commit has minor fixes ...
  http://review.gluster.org/15562 [BugId:1377437][Patch9]:
  Refering to the bug ID, - Minor header file ...
 

 Primarily, 

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Avra Sengupta]

Hi Sriram,

I have already provided comments on the new patch. It seems this new 
patch while addressing merge cloflicts, has undone some previous 
patches. I suggest you send this patch on top of the previous 
patchset(http://review.gluster.org/#/c/15554/1) instead of creating a 
new one. This will allow you to view the diff between the new version 
and the previous version, and will give u an idea if the diff is 
something that you added in the patch or got added as part of merge 
conflict.


Regards,
Avra

On 12/15/2016 12:09 PM, sri...@marirs.net.in wrote:

Hi Avra,

I've update the patch according to the comments below. And created a 
single patch which does the initial modularization. Fixed the 
tab->space issue as well. I've raised a new review request for the 
same bug ID here:

http://review.gluster.org/#/c/16138/

Added, Rajesh and You as the reviewers, let me know if I need to do 
anything else.


Could you have a look and let me know?

(Sorry for the delay in creating this)

Sriram

On Thu, Oct 13, 2016, at 12:15 PM, Avra Sengupta wrote:

Hi Sriram,

The point I was trying to make is, that we want that each patch 
should compile by itself, and pass regression. So for that to happen, 
we need to consolidate these patches(the first three) into one patch, 
and have the necessary make file changes into that patch too.


http://review.gluster.org/#/c/15554/
http://review.gluster.org/#/c/1/
http://review.gluster.org/#/c/15556/

That will give us one single patch, that contains the changes of 
having the current code moved into separate files, and it should get 
compiled on it's own, and should pass regression. Also, we use 
spaces, and not tabs in the code. So we will need to get those 
changed too. Thanks.


Regards,
Avra

On 10/12/2016 10:46 PM, sri...@marirs.net.in 
 wrote:

Hi Avra,

Could you let me know on the below request?

Sriram


On Tue, Oct 4, 2016, at 11:16 AM, sri...@marirs.net.in 
 wrote:

Hi Avra,

I checked the comment, the series of patches, (There are nine 
patches) for which I've posted for a review below. They've all the 
necessary makefiles to compile.


Would you want me to consolidate all'em and post them as a single 
patch? (I thought that would be a little confusing, since it'd 
changes with different intentions).


Sriram


On Mon, Oct 3, 2016, at 03:54 PM, Avra Sengupta wrote:

Hi Sriram,

I posted a comment into the first patch. It doesn't compile by 
itself. We need to update the respective makefiles to be able to 
compile it. Then we can introduce the tabular structure in the 
same patch to have the framework set for the zfs snapshots. Thanks.


Regards,
Avra

On 09/30/2016 10:24 AM, sri...@marirs.net.in 
 wrote:

Hi Avra,

Could you have a look into the below request?

Sriram


On Fri, Sep 23, 2016, at 04:10 PM, sri...@marirs.net.in 
 wrote:

Hi Avra,

Have submitted the patches for Modularizing snapshot,

https://bugzilla.redhat.com/show_bug.cgi?id=1377437

This is the patch set:

http://review.gluster.org/15554 This patch follows the 
discussion from the gluster-devel mail chain of, ...
http://review.gluster.org/1 Referring to bugID:1377437, 
Modularizing snapshot for plugin based modules.
http://review.gluster.org/15556 - This is third patch in the 
series for the bug=1377437
http://review.gluster.org/15557 [BugId:1377437][Patch4]: 
Refering to the bug ID,
http://review.gluster.org/15558 [BugId:1377437][Patch5]: 
Refering to the bug ID,
http://review.gluster.org/15559 [BugId:1377437][Patch6]: 
Refering to the bug ID,
http://review.gluster.org/15560 [BugId:1377437][Patch7]: 
Refering to the bug ID. * This patch has some minor ...
http://review.gluster.org/15561 [BugId:1377437][Patch8]: 
Refering to the bug ID, this commit has minor fixes ...
http://review.gluster.org/15562 [BugId:1377437][Patch9]: 
Refering to the bug ID, - Minor header file ...


Primarily, focused on moving lvm based implementation into 
plugins. Have spread the commits across nine patches, some of 
them are minors, except a couple of ones which does the real 
work. Others are minors. Followed this method since, it would be 
easy for a review (accept/reject). Let me know if there is 
something off the methods followed with gluster devel. Thanks


Sriram

On Mon, Sep 19, 2016, at 10:58 PM, Avra Sengupta wrote:

Hi Sriram,

I have created a bug for this 
(https://bugzilla.redhat.com/show_bug.cgi?id=1377437). The plan 
is that for the first patch as mentioned below, let's not 
meddle with the zfs code at all. What we are looking at is 
segregating the lvm based code as is today, from the management 
infrastructure (which is addressed in your patch), and creating 
a table based pluggable infra(refer to gd_svc_cli_actors[] in 
xlators/mgmt/glusterd/src/glusterd-handler.c and other similar 
tables in gluster code base to get a understanding of what I am 
conveying), which can be 

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[sriram]

Hi Avra, 



I've update the patch according to the comments below. And created a
single patch which does the initial modularization. Fixed the tab-
>space issue as well. I've raised a new review request for the same
bug ID here:
http://review.gluster.org/#/c/16138/



Added, Rajesh and You as the reviewers, let me know if I need to do
anything else.


Could you have a look and let me know? 



(Sorry for the delay in creating this) 



Sriram



On Thu, Oct 13, 2016, at 12:15 PM, Avra Sengupta wrote:

> Hi Sriram,

> 

>  The point I was trying to make is, that we want that each patch
>  should compile by itself, and pass regression. So for that to happen,
>  we need to consolidate these patches(the first three) into one patch,
>  and have the necessary make file changes into that patch too.
> 

> http://review.gluster.org/#/c/15554/

> http://review.gluster.org/#/c/1/

> http://review.gluster.org/#/c/15556/

> 

>  That will give us one single patch, that contains the changes of
>  having the current code moved into separate files, and it should get
>  compiled on it's own, and should pass regression. Also, we use
>  spaces, and not tabs in the code. So we will need to get those
>  changed too. Thanks.
> 

>  Regards,

>  Avra

> 

>  On 10/12/2016 10:46 PM, sri...@marirs.net.in wrote:

>> Hi Avra, 

>> 

>> Could you let me know on the below request? 

>> 

>> Sriram

>> 

>> 

>> On Tue, Oct 4, 2016, at 11:16 AM, sri...@marirs.net.in wrote:

>>> Hi Avra,

>>> 

>>> I checked the comment, the series of patches, (There are nine
>>> patches) for which I've posted for a review below. They've all the
>>> necessary makefiles to compile.
>>> 

>>> Would you want me to consolidate all'em and post them as a single
>>> patch? (I thought that would be a little confusing, since it'd
>>> changes with different intentions).
>>> 

>>> Sriram

>>> 

>>> 

>>> On Mon, Oct 3, 2016, at 03:54 PM, Avra Sengupta wrote:

 Hi Sriram,

 

 I posted a comment into the first patch. It doesn't compile by
 itself. We need to update the respective makefiles to be able to
 compile it. Then we can introduce the tabular structure in the same
 patch to have the framework set for the zfs snapshots. Thanks.
 

 Regards,

 Avra

 

 On 09/30/2016 10:24 AM, sri...@marirs.net.in wrote:

> Hi Avra, 

> 

> Could you have a look into the below request? 

> 

> Sriram 

> 

> 

> On Fri, Sep 23, 2016, at 04:10 PM, sri...@marirs.net.in wrote:

>> Hi Avra, 

>> 

>> Have submitted the patches for Modularizing snapshot, 

>> 

>> https://bugzilla.redhat.com/show_bug.cgi?id=1377437

>> 

>> This is the patch set: 

>> 

>>  http://review.gluster.org/15554 This patch follows the
>>  discussion from the gluster-devel mail chain of, ...
>>  http://review.gluster.org/1 Referring to bugID:1377437,
>>  Modularizing snapshot for plugin based modules.
>>  http://review.gluster.org/15556 - This is third patch in the
>>  series for the bug=1377437
>>  http://review.gluster.org/15557 [BugId:1377437][Patch4]:
>>  Refering to the bug ID,
>>  http://review.gluster.org/15558 [BugId:1377437][Patch5]:
>>  Refering to the bug ID,
>>  http://review.gluster.org/15559 [BugId:1377437][Patch6]:
>>  Refering to the bug ID,
>>  http://review.gluster.org/15560 [BugId:1377437][Patch7]:
>>  Refering to the bug ID. * This patch has some minor ...
>>  http://review.gluster.org/15561 [BugId:1377437][Patch8]:
>>  Refering to the bug ID, this commit has minor fixes ...
>>  http://review.gluster.org/15562 [BugId:1377437][Patch9]:
>>  Refering to the bug ID, - Minor header file ...
>> 

>> Primarily, focused on moving lvm based implementation into
>> plugins. Have spread the commits across nine patches, some of
>> them are minors, except a couple of ones which does the real
>> work. Others are minors. Followed this method since, it would be
>> easy for a review (accept/reject). Let me know if there is
>> something off the methods followed with gluster devel. Thanks
>> 

>> Sriram

>> 

>> On Mon, Sep 19, 2016, at 10:58 PM, Avra Sengupta wrote:

>>> Hi Sriram,

>>> 

>>> I have created a bug for this
>>> (https://bugzilla.redhat.com/show_bug.cgi?id=1377437).  The plan
>>> is that for the first patch as mentioned below, let's not meddle
>>> with the zfs code at all. What we are looking at is segregating
>>> the lvm based code as is today, from the management
>>> infrastructure (which is addressed in your patch), and creating
>>> a table based pluggable infra(refer to gd_svc_cli_actors[] in
>>> xlators/mgmt/glusterd/src/glusterd-handler.c and other similar
>>> tables in gluster code base to get a understanding of what I am
>>> conveying), which can be used to call this code and still
>>> achieve the same 

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Vijay Bellur]

On Thu, Oct 13, 2016 at 3:20 AM, Gandalf Corvotempesta
 wrote:
> Il 20 giu 2016 8:08 AM, "B.K.Raghuram"  ha scritto:
>>
>> We had hosted some changes to an old version of glusterfs (3.6.1) in order
>> to incorporate ZFS snapshot support for gluster snapshot commands.
>
> Sorry for this OT but can someone explain me what's the meaning for these
> patches?
> Are you trying to merge ZFS snapshot support in gluster by replacing the
> gluster snapshot code, or to make gluster able to create ZFS snapshots when
> gluster is used with  ZFS bricks?
>


The intent is to make snapshotting in gluster more modular and add
support for the latter. Today our snapshotting is pretty much tied to
device mapper and cannot leverage snapshot capabilities present in
other underlying storage subsystems (zfs, btrfs etc.).

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

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Gandalf Corvotempesta]

Il 20 giu 2016 8:08 AM, "B.K.Raghuram"  ha scritto:
>
> We had hosted some changes to an old version of glusterfs (3.6.1) in
order to incorporate ZFS snapshot support for gluster snapshot commands.

Sorry for this OT but can someone explain me what's the meaning for these
patches?
Are you trying to merge ZFS snapshot support in gluster by replacing the
gluster snapshot code, or to make gluster able to create ZFS snapshots when
gluster is used with  ZFS bricks?

I hope it's clear what I'm asking.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Avra Sengupta]

Hi Sriram,

The point I was trying to make is, that we want that each patch should 
compile by itself, and pass regression. So for that to happen, we need 
to consolidate these patches(the first three) into one patch, and have 
the necessary make file changes into that patch too.


http://review.gluster.org/#/c/15554/
http://review.gluster.org/#/c/1/
http://review.gluster.org/#/c/15556/

That will give us one single patch, that contains the changes of having 
the current code moved into separate files, and it should get compiled 
on it's own, and should pass regression. Also, we use spaces, and not 
tabs in the code. So we will need to get those changed too. Thanks.


Regards,
Avra

On 10/12/2016 10:46 PM, sri...@marirs.net.in wrote:

Hi Avra,

Could you let me know on the below request?

Sriram


On Tue, Oct 4, 2016, at 11:16 AM, sri...@marirs.net.in 
 wrote:

Hi Avra,

I checked the comment, the series of patches, (There are nine 
patches) for which I've posted for a review below. They've all the 
necessary makefiles to compile.


Would you want me to consolidate all'em and post them as a single 
patch? (I thought that would be a little confusing, since it'd 
changes with different intentions).


Sriram


On Mon, Oct 3, 2016, at 03:54 PM, Avra Sengupta wrote:

Hi Sriram,

I posted a comment into the first patch. It doesn't compile by 
itself. We need to update the respective makefiles to be able to 
compile it. Then we can introduce the tabular structure in the same 
patch to have the framework set for the zfs snapshots. Thanks.


Regards,
Avra

On 09/30/2016 10:24 AM, sri...@marirs.net.in 
 wrote:

Hi Avra,

Could you have a look into the below request?

Sriram


On Fri, Sep 23, 2016, at 04:10 PM, sri...@marirs.net.in 
 wrote:

Hi Avra,

Have submitted the patches for Modularizing snapshot,

https://bugzilla.redhat.com/show_bug.cgi?id=1377437

This is the patch set:

http://review.gluster.org/15554 This patch follows the discussion 
from the gluster-devel mail chain of, ...
http://review.gluster.org/1 Referring to bugID:1377437, 
Modularizing snapshot for plugin based modules.
http://review.gluster.org/15556 - This is third patch in the 
series for the bug=1377437
http://review.gluster.org/15557 [BugId:1377437][Patch4]: Refering 
to the bug ID,
http://review.gluster.org/15558 [BugId:1377437][Patch5]: Refering 
to the bug ID,
http://review.gluster.org/15559 [BugId:1377437][Patch6]: Refering 
to the bug ID,
http://review.gluster.org/15560 [BugId:1377437][Patch7]: Refering 
to the bug ID. * This patch has some minor ...
http://review.gluster.org/15561 [BugId:1377437][Patch8]: Refering 
to the bug ID, this commit has minor fixes ...
http://review.gluster.org/15562 [BugId:1377437][Patch9]: Refering 
to the bug ID, - Minor header file ...


Primarily, focused on moving lvm based implementation into 
plugins. Have spread the commits across nine patches, some of them 
are minors, except a couple of ones which does the real work. 
Others are minors. Followed this method since, it would be easy 
for a review (accept/reject). Let me know if there is something 
off the methods followed with gluster devel. Thanks


Sriram

On Mon, Sep 19, 2016, at 10:58 PM, Avra Sengupta wrote:

Hi Sriram,

I have created a bug for this 
(https://bugzilla.redhat.com/show_bug.cgi?id=1377437). The plan 
is that for the first patch as mentioned below, let's not meddle 
with the zfs code at all. What we are looking at is segregating 
the lvm based code as is today, from the management 
infrastructure (which is addressed in your patch), and creating a 
table based pluggable infra(refer to gd_svc_cli_actors[] in 
xlators/mgmt/glusterd/src/glusterd-handler.c and other similar 
tables in gluster code base to get a understanding of what I am 
conveying), which can be used to call this code and still achieve 
the same results as we do today.


Once this code is merged, we can use the same infra to start 
pushing in the zfs code (rest of your current patch). Please let 
me know if you have further queries regarding this. Thanks.


Regards,
Avra

On 09/19/2016 07:52 PM, sri...@marirs.net.in 
 wrote:

Hi Avra,

Do you have a bug id for this changes? Or may I raise a new one?

Sriram


On Fri, Sep 16, 2016, at 11:37 AM, sri...@marirs.net.in 
 wrote:

Thanks Avra,

I'll send this patch to gluster master in a while.

Sriram


On Wed, Sep 14, 2016, at 03:08 PM, Avra Sengupta wrote:

Hi Sriram,

Sorry for the delay in response. I started going through the 
commits in the github repo. I finished going through the first 
commit, where you create a plugin structure and move code. 
Following is the commit link:


https://github.com/sriramster/glusterfs/commit/7bf157525539541ebf0aa36a380bbedb2cae5440

FIrst of all, the overall approach of using plugins, and 
maintaining plugins that is used in the patch 

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[sriram]

Hi Avra,

Could you let me know on the below request?

Sriram


On Tue, Oct 4, 2016, at 11:16 AM, sri...@marirs.net.in wrote:
> Hi Avra,
>
> I checked the comment, the series of patches, (There are nine patches)
> for which I've posted for a review below. They've all the necessary
> makefiles to compile.
>
> Would you want me to consolidate all'em and post them as a single
> patch? (I thought that would be a little confusing, since it'd changes
> with different intentions).
>
> Sriram
>
>
> On Mon, Oct 3, 2016, at 03:54 PM, Avra Sengupta wrote:
>> Hi Sriram,
>>
>> I posted a comment into the first patch. It doesn't compile by
>> itself. We need to update the respective makefiles to be able to
>> compile it. Then we can introduce the tabular structure in the same
>> patch to have the framework set for the zfs snapshots. Thanks.
>>
>> Regards,
>> Avra
>>
>> On 09/30/2016 10:24 AM, sri...@marirs.net.in wrote:
>>> Hi Avra,
>>>
>>> Could you have a look into the below request?
>>>
>>> Sriram
>>>
>>>
>>> On Fri, Sep 23, 2016, at 04:10 PM, sri...@marirs.net.in wrote:
 Hi Avra,

 Have submitted the patches for Modularizing snapshot,

 https://bugzilla.redhat.com/show_bug.cgi?id=1377437

 This is the patch set:

  http://review.gluster.org/15554 This patch follows the discussion
  from the gluster-devel mail chain of, ...
  http://review.gluster.org/1 Referring to bugID:1377437,
  Modularizing snapshot for plugin based modules.
  http://review.gluster.org/15556 - This is third patch in the
  series for the bug=1377437
  http://review.gluster.org/15557 [BugId:1377437][Patch4]: Refering
  to the bug ID,
  http://review.gluster.org/15558 [BugId:1377437][Patch5]: Refering
  to the bug ID,
  http://review.gluster.org/15559 [BugId:1377437][Patch6]: Refering
  to the bug ID,
  http://review.gluster.org/15560 [BugId:1377437][Patch7]: Refering
  to the bug ID. * This patch has some minor ...
  http://review.gluster.org/15561 [BugId:1377437][Patch8]: Refering
  to the bug ID, this commit has minor fixes ...
  http://review.gluster.org/15562 [BugId:1377437][Patch9]: Refering
  to the bug ID, - Minor header file ...

 Primarily, focused on moving lvm based implementation into plugins.
 Have spread the commits across nine patches, some of them are
 minors, except a couple of ones which does the real work. Others
 are minors. Followed this method since, it would be easy for a
 review (accept/reject). Let me know if there is something off the
 methods followed with gluster devel. Thanks

 Sriram

 On Mon, Sep 19, 2016, at 10:58 PM, Avra Sengupta wrote:
> Hi Sriram,
>
> I have created a bug for this
> (https://bugzilla.redhat.com/show_bug.cgi?id=1377437). The plan is
> that for the first patch as mentioned below, let's not meddle with
> the zfs code at all. What we are looking at is segregating the lvm
> based code as is today, from the management infrastructure (which
> is addressed in your patch), and creating a table based pluggable
> infra(refer to gd_svc_cli_actors[] in xlators/mgmt/glusterd/src/glusterd-
> handler.c and other similar tables in gluster code base to get a
> understanding of what I am conveying), which can be used to call
> this code and still achieve the same results as we do today.
>
> Once this code is merged, we can use the same infra to start
> pushing in the zfs code (rest of your current patch). Please let
> me know if you have further queries regarding this. Thanks.
>
> Regards,
> Avra
>
> On 09/19/2016 07:52 PM, sri...@marirs.net.in wrote:
>> Hi Avra,
>>
>> Do you have a bug id for this changes? Or may I raise a new one?
>>
>> Sriram
>>
>>
>> On Fri, Sep 16, 2016, at 11:37 AM, sri...@marirs.net.in wrote:
>>> Thanks Avra,
>>>
>>> I'll send this patch to gluster master in a while.
>>>
>>> Sriram
>>>
>>>
>>> On Wed, Sep 14, 2016, at 03:08 PM, Avra Sengupta wrote:
 Hi Sriram,

 Sorry for the delay in response. I started going through the
 commits in the github repo. I finished going through the first
 commit, where you create a plugin structure and move code.
 Following is the commit link:

 https://github.com/sriramster/glusterfs/commit/7bf157525539541ebf0aa36a380bbedb2cae5440

 FIrst of all, the overall approach of using plugins, and
 maintaining plugins that is used in the patch is in sync with
 what we had discussed. There are some gaps though, like in the
 zfs functions the snap brick is mounted without updating
 labels, and in restore you perform a zfs rollback, which
 significantly changes the behavior between how a lvm based
 snapshot and a zfs based snapshot.

 

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[sriram]

Hi Avra,

I checked the comment, the series of patches, (There are nine patches)
for which I've posted for a review below. They've all the necessary
makefiles to compile.

Would you want me to consolidate all'em and post them as a single patch?
(I thought that would be a little confusing, since it'd changes with
different intentions).

Sriram


On Mon, Oct 3, 2016, at 03:54 PM, Avra Sengupta wrote:
> Hi Sriram,
>
>  I posted a comment into the first patch. It doesn't compile by
>  itself. We need to update the respective makefiles to be able to
>  compile it. Then we can introduce the tabular structure in the same
>  patch to have the framework set for the zfs snapshots. Thanks.
>
>  Regards,
>  Avra
>
>  On 09/30/2016 10:24 AM, sri...@marirs.net.in wrote:
>> Hi Avra,
>>
>> Could you have a look into the below request?
>>
>> Sriram
>>
>>
>> On Fri, Sep 23, 2016, at 04:10 PM, sri...@marirs.net.in wrote:
>>> Hi Avra,
>>>
>>> Have submitted the patches for Modularizing snapshot,
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1377437
>>>
>>> This is the patch set:
>>>
>>>  http://review.gluster.org/15554 This patch follows the discussion
>>>  from the gluster-devel mail chain of, ...
>>>  http://review.gluster.org/1 Referring to bugID:1377437,
>>>  Modularizing snapshot for plugin based modules.
>>>  http://review.gluster.org/15556 - This is third patch in the series
>>>  for the bug=1377437
>>>  http://review.gluster.org/15557 [BugId:1377437][Patch4]: Refering
>>>  to the bug ID,
>>>  http://review.gluster.org/15558 [BugId:1377437][Patch5]: Refering
>>>  to the bug ID,
>>>  http://review.gluster.org/15559 [BugId:1377437][Patch6]: Refering
>>>  to the bug ID,
>>>  http://review.gluster.org/15560 [BugId:1377437][Patch7]: Refering
>>>  to the bug ID. * This patch has some minor ...
>>>  http://review.gluster.org/15561 [BugId:1377437][Patch8]: Refering
>>>  to the bug ID, this commit has minor fixes ...
>>>  http://review.gluster.org/15562 [BugId:1377437][Patch9]: Refering
>>>  to the bug ID, - Minor header file ...
>>>
>>> Primarily, focused on moving lvm based implementation into plugins.
>>> Have spread the commits across nine patches, some of them are
>>> minors, except a couple of ones which does the real work. Others are
>>> minors. Followed this method since, it would be easy for a review
>>> (accept/reject). Let me know if there is something off the methods
>>> followed with gluster devel. Thanks
>>>
>>> Sriram
>>>
>>> On Mon, Sep 19, 2016, at 10:58 PM, Avra Sengupta wrote:
 Hi Sriram,

 I have created a bug for this
 (https://bugzilla.redhat.com/show_bug.cgi?id=1377437). The plan is
 that for the first patch as mentioned below, let's not meddle with
 the zfs code at all. What we are looking at is segregating the lvm
 based code as is today, from the management infrastructure (which
 is addressed in your patch), and creating a table based pluggable
 infra(refer to gd_svc_cli_actors[] in xlators/mgmt/glusterd/src/glusterd-
 handler.c and other similar tables in gluster code base to get a
 understanding of what I am conveying), which can be used to call
 this code and still achieve the same results as we do today.

 Once this code is merged, we can use the same infra to start
 pushing in the zfs code (rest of your current patch). Please let me
 know if you have further queries regarding this. Thanks.

 Regards,
 Avra

 On 09/19/2016 07:52 PM, sri...@marirs.net.in wrote:
> Hi Avra,
>
> Do you have a bug id for this changes? Or may I raise a new one?
>
> Sriram
>
>
> On Fri, Sep 16, 2016, at 11:37 AM, sri...@marirs.net.in wrote:
>> Thanks Avra,
>>
>> I'll send this patch to gluster master in a while.
>>
>> Sriram
>>
>>
>> On Wed, Sep 14, 2016, at 03:08 PM, Avra Sengupta wrote:
>>> Hi Sriram,
>>>
>>> Sorry for the delay in response. I started going through the
>>> commits in the github repo. I finished going through the first
>>> commit, where you create a plugin structure and move code.
>>> Following is the commit link:
>>>
>>> https://github.com/sriramster/glusterfs/commit/7bf157525539541ebf0aa36a380bbedb2cae5440
>>>
>>> FIrst of all, the overall approach of using plugins, and
>>> maintaining plugins that is used in the patch is in sync with
>>> what we had discussed. There are some gaps though, like in the
>>> zfs functions the snap brick is mounted without updating labels,
>>> and in restore you perform a zfs rollback, which significantly
>>> changes the behavior between how a lvm based snapshot and a zfs
>>> based snapshot.
>>>
>>> But before we get into these details, I would request you to
>>> kindly send this particular patch to the gluster master branch,
>>> as that is how we formally review patches, and I would say this
>>> particular patch in itself is ready for 

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Avra Sengupta]

Hi Sriram,

I posted a comment into the first patch. It doesn't compile by itself. 
We need to update the respective makefiles to be able to compile it. 
Then we can introduce the tabular structure in the same patch to have 
the framework set for the zfs snapshots. Thanks.


Regards,
Avra

On 09/30/2016 10:24 AM, sri...@marirs.net.in wrote:

Hi Avra,

Could you have a look into the below request?

Sriram


On Fri, Sep 23, 2016, at 04:10 PM, sri...@marirs.net.in 
 wrote:

Hi Avra,

Have submitted the patches for Modularizing snapshot,

https://bugzilla.redhat.com/show_bug.cgi?id=1377437

This is the patch set:

http://review.gluster.org/15554 This patch follows the discussion 
from the gluster-devel mail chain of, ...
http://review.gluster.org/1 Referring to bugID:1377437, 
Modularizing snapshot for plugin based modules.
http://review.gluster.org/15556 - This is third patch in the series 
for the bug=1377437
http://review.gluster.org/15557 [BugId:1377437][Patch4]: Refering to 
the bug ID,
http://review.gluster.org/15558 [BugId:1377437][Patch5]: Refering to 
the bug ID,
http://review.gluster.org/15559 [BugId:1377437][Patch6]: Refering to 
the bug ID,
http://review.gluster.org/15560 [BugId:1377437][Patch7]: Refering to 
the bug ID. * This patch has some minor ...
http://review.gluster.org/15561 [BugId:1377437][Patch8]: Refering to 
the bug ID, this commit has minor fixes ...
http://review.gluster.org/15562 [BugId:1377437][Patch9]: Refering to 
the bug ID, - Minor header file ...


Primarily, focused on moving lvm based implementation into plugins. 
Have spread the commits across nine patches, some of them are minors, 
except a couple of ones which does the real work. Others are minors. 
Followed this method since, it would be easy for a review 
(accept/reject). Let me know if there is something off the methods 
followed with gluster devel. Thanks


Sriram

On Mon, Sep 19, 2016, at 10:58 PM, Avra Sengupta wrote:

Hi Sriram,

I have created a bug for this 
(https://bugzilla.redhat.com/show_bug.cgi?id=1377437). The plan is 
that for the first patch as mentioned below, let's not meddle with 
the zfs code at all. What we are looking at is segregating the lvm 
based code as is today, from the management infrastructure (which is 
addressed in your patch), and creating a table based pluggable 
infra(refer to gd_svc_cli_actors[] in 
xlators/mgmt/glusterd/src/glusterd-handler.c and other similar 
tables in gluster code base to get a understanding of what I am 
conveying), which can be used to call this code and still achieve 
the same results as we do today.


Once this code is merged, we can use the same infra to start pushing 
in the zfs code (rest of your current patch). Please let me know if 
you have further queries regarding this. Thanks.


Regards,
Avra

On 09/19/2016 07:52 PM, sri...@marirs.net.in 
 wrote:

Hi Avra,

Do you have a bug id for this changes? Or may I raise a new one?

Sriram


On Fri, Sep 16, 2016, at 11:37 AM, sri...@marirs.net.in 
 wrote:

Thanks Avra,

I'll send this patch to gluster master in a while.

Sriram


On Wed, Sep 14, 2016, at 03:08 PM, Avra Sengupta wrote:

Hi Sriram,

Sorry for the delay in response. I started going through the 
commits in the github repo. I finished going through the first 
commit, where you create a plugin structure and move code. 
Following is the commit link:


https://github.com/sriramster/glusterfs/commit/7bf157525539541ebf0aa36a380bbedb2cae5440

FIrst of all, the overall approach of using plugins, and 
maintaining plugins that is used in the patch is in sync with 
what we had discussed. There are some gaps though, like in the 
zfs functions the snap brick is mounted without updating labels, 
and in restore you perform a zfs rollback, which significantly 
changes the behavior between how a lvm based snapshot and a zfs 
based snapshot.


But before we get into these details, I would request you to 
kindly send this particular patch to the gluster master branch, 
as that is how we formally review patches, and I would say this 
particular patch in itself is ready for a formal review. Once we 
straighten out the quirks in this patch, we can significantly 
start moving the other dependent patches to master and reviewing 
them. Thanks.


Regards,
Avra

P.S : Adding gluster-devel

On 09/13/2016 01:14 AM, sri...@marirs.net.in 
 wrote:

Hi Avra,

You'd time to look into the below request?

Sriram


On Thu, Sep 8, 2016, at 01:20 PM, sri...@marirs.net.in 
 wrote:

Hi Avra,

Thank you. Please, let me know your feedback. It would be 
helpful on continuing from then.


Sriram


On Thu, Sep 8, 2016, at 01:18 PM, Avra Sengupta wrote:

Hi Sriram,

Rajesh is on a vacation, and will be available towards the end 
of next week. He will be sharing his feedback once he is back. 
Meanwhile I will have a look at the patch and share my 

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[sriram]

Hi Avra,

Have submitted the patches for Modularizing snapshot,

https://bugzilla.redhat.com/show_bug.cgi?id=1377437

This is the patch set:

 http://review.gluster.org/15554 This patch follows the discussion from
 the gluster-devel mail chain of, ...
 http://review.gluster.org/1 Referring to bugID:1377437,
 Modularizing snapshot for plugin based modules.
 http://review.gluster.org/15556 - This is third patch in the series for
 the bug=1377437
 http://review.gluster.org/15557 [BugId:1377437][Patch4]: Refering to
 the bug ID,
 http://review.gluster.org/15558 [BugId:1377437][Patch5]: Refering to
 the bug ID,
 http://review.gluster.org/15559 [BugId:1377437][Patch6]: Refering to
 the bug ID,
 http://review.gluster.org/15560 [BugId:1377437][Patch7]: Refering to
 the bug ID. * This patch has some minor ...
 http://review.gluster.org/15561 [BugId:1377437][Patch8]: Refering to
 the bug ID, this commit has minor fixes ...
 http://review.gluster.org/15562 [BugId:1377437][Patch9]: Refering to
 the bug ID, - Minor header file ...

Primarily, focused on moving lvm based implementation into plugins.
Have spread the commits across nine patches, some of them are minors,
except a couple of ones which does the real work. Others are minors.
Followed this method since, it would be easy for a review
(accept/reject). Let me know if there is something off the methods
followed with gluster devel. Thanks

Sriram

On Mon, Sep 19, 2016, at 10:58 PM, Avra Sengupta wrote:
> Hi Sriram,
>
>  I have created a bug for this
>  (https://bugzilla.redhat.com/show_bug.cgi?id=1377437). The plan is
>  that for the first patch as mentioned below, let's not meddle with
>  the zfs code at all. What we are looking at is segregating the lvm
>  based code as is today, from the management infrastructure (which is
>  addressed in your patch), and creating a table based pluggable
>  infra(refer to gd_svc_cli_actors[] in xlators/mgmt/glusterd/src/glusterd-
>  handler.c and other similar tables in gluster code base to get a
>  understanding of what I am conveying), which can be used to call this
>  code and still achieve the same results as we do today.
>
>  Once this code is merged, we can use the same infra to start pushing
>  in the zfs code (rest of your current patch). Please let me know if
>  you have further queries regarding this. Thanks.
>
>  Regards,
>  Avra
>
>  On 09/19/2016 07:52 PM, sri...@marirs.net.in wrote:
>> Hi Avra,
>>
>> Do you have a bug id for this changes? Or may I raise a new one?
>>
>> Sriram
>>
>>
>> On Fri, Sep 16, 2016, at 11:37 AM, sri...@marirs.net.in wrote:
>>> Thanks Avra,
>>>
>>> I'll send this patch to gluster master in a while.
>>>
>>> Sriram
>>>
>>>
>>> On Wed, Sep 14, 2016, at 03:08 PM, Avra Sengupta wrote:
 Hi Sriram,

 Sorry for the delay in response. I started going through the
 commits in the github repo. I finished going through the first
 commit, where you create a plugin structure and move code.
 Following is the commit link:

 https://github.com/sriramster/glusterfs/commit/7bf157525539541ebf0aa36a380bbedb2cae5440

 FIrst of all, the overall approach of using plugins, and
 maintaining plugins that is used in the patch is in sync with what
 we had discussed. There are some gaps though, like in the zfs
 functions the snap brick is mounted without updating labels, and in
 restore you perform a zfs rollback, which significantly changes the
 behavior between how a lvm based snapshot and a zfs based snapshot.

 But before we get into these details, I would request you to kindly
 send this particular patch to the gluster master branch, as that is
 how we formally review patches, and I would say this particular
 patch in itself is ready for a formal review. Once we straighten
 out the quirks in this patch, we can significantly start moving the
 other dependent patches to master and reviewing them. Thanks.

 Regards,
 Avra

 P.S : Adding gluster-devel

 On 09/13/2016 01:14 AM, sri...@marirs.net.in wrote:
> Hi Avra,
>
> You'd time to look into the below request?
>
> Sriram
>
>
> On Thu, Sep 8, 2016, at 01:20 PM, sri...@marirs.net.in wrote:
>> Hi Avra,
>>
>> Thank you. Please, let me know your feedback. It would be helpful
>> on continuing from then.
>>
>> Sriram
>>
>>
>> On Thu, Sep 8, 2016, at 01:18 PM, Avra Sengupta wrote:
>>> Hi Sriram,
>>>
>>> Rajesh is on a vacation, and will be available towards the end
>>> of next week. He will be sharing his feedback once he is back.
>>> Meanwhile I will have a look at the patch and share my feedback
>>> with you. But it will take me some time to go through it.
>>> Thanks.
>>>
>>> Regards,
>>> Avra
>>>
>>> On 09/08/2016 01:09 PM, sri...@marirs.net.in wrote:
 Hello Rajesh,

 Sorry to bother. Could you have a look at the below 

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Avra Sengupta]

Hi Sriram,

I have created a bug for this 
(https://bugzilla.redhat.com/show_bug.cgi?id=1377437). The plan is that 
for the first patch as mentioned below, let's not meddle with the zfs 
code at all. What we are looking at is segregating the lvm based code as 
is today, from the management infrastructure (which is addressed in your 
patch), and creating a table based pluggable infra(refer to 
gd_svc_cli_actors[] in xlators/mgmt/glusterd/src/glusterd-handler.c and 
other similar tables in gluster code base to get a understanding of what 
I am conveying), which can be used to call this code and still achieve 
the same results as we do today.


Once this code is merged, we can use the same infra to start pushing in 
the zfs code (rest of your current patch). Please let me know if you 
have further queries regarding this. Thanks.


Regards,
Avra

On 09/19/2016 07:52 PM, sri...@marirs.net.in wrote:

Hi Avra,

Do you have a bug id for this changes? Or may I raise a new one?

Sriram


On Fri, Sep 16, 2016, at 11:37 AM, sri...@marirs.net.in 
 wrote:

Thanks Avra,

I'll send this patch to gluster master in a while.

Sriram


On Wed, Sep 14, 2016, at 03:08 PM, Avra Sengupta wrote:

Hi Sriram,

Sorry for the delay in response. I started going through the commits 
in the github repo. I finished going through the first commit, where 
you create a plugin structure and move code. Following is the commit 
link:


https://github.com/sriramster/glusterfs/commit/7bf157525539541ebf0aa36a380bbedb2cae5440

FIrst of all, the overall approach of using plugins, and maintaining 
plugins that is used in the patch is in sync with what we had 
discussed. There are some gaps though, like in the zfs functions the 
snap brick is mounted without updating labels, and in restore you 
perform a zfs rollback, which significantly changes the behavior 
between how a lvm based snapshot and a zfs based snapshot.


But before we get into these details, I would request you to kindly 
send this particular patch to the gluster master branch, as that is 
how we formally review patches, and I would say this particular 
patch in itself is ready for a formal review. Once we straighten out 
the quirks in this patch, we can significantly start moving the 
other dependent patches to master and reviewing them. Thanks.


Regards,
Avra

P.S : Adding gluster-devel

On 09/13/2016 01:14 AM, sri...@marirs.net.in 
 wrote:

Hi Avra,

You'd time to look into the below request?

Sriram


On Thu, Sep 8, 2016, at 01:20 PM, sri...@marirs.net.in 
 wrote:

Hi Avra,

Thank you. Please, let me know your feedback. It would be helpful 
on continuing from then.


Sriram


On Thu, Sep 8, 2016, at 01:18 PM, Avra Sengupta wrote:

Hi Sriram,

Rajesh is on a vacation, and will be available towards the end of 
next week. He will be sharing his feedback once he is back. 
Meanwhile I will have a look at the patch and share my feedback 
with you. But it will take me some time to go through it. Thanks.


Regards,
Avra

On 09/08/2016 01:09 PM, sri...@marirs.net.in 
 wrote:

Hello Rajesh,

Sorry to bother. Could you have a look at the below request?

Sriram


On Tue, Sep 6, 2016, at 11:27 AM, sri...@marirs.net.in 
 wrote:

Hello Rajesh,

Sorry for the delayed mail, was on leave. Could you let me know 
the feedback?


Sriram


On Fri, Sep 2, 2016, at 10:08 AM, Rajesh Joseph wrote:

+ Avra
Hi Srirram,

Sorry, I was on leave therefore could not reply.
Added Avra who is also working on the snapshot component for 
review.

Will take a look at your changes today.
Thanks & Regards,
Rajesh


On Thu, Sep 1, 2016 at 1:22 PM, > wrote:



Hello Rajesh,

Could you've a look at the below request?

Sriram

On Tue, Aug 30, 2016, at 01:03 PM, sri...@marirs.net.in
 wrote:

Hi Rajesh,

Continuing from the discussion we've had below and
suggestions made by you, had created a plugin like
structure (A generic plugin model) and added snapshot to
be the first plugin implementation. Could you've a look
if the approach is fine? I've not raised a official
review request yet. Could you give an initial review of
the model?

https://github.com/sriramster/glusterfs/tree/sriram_dev

Things done,

- Created a new folder for glusterd plugins and added
snapshot as a plugin. Like this,

$ROOT/xlators/mgmt/glusterd/plugins +
|
+ __ snapshot/src

Moved LVM related snapshot implementation to
xlators/mgmt/glusterd/plugins/snapshot/src/lvm-snapshot.c

- Mostly isolated, glusterd code from snapshot
implementation by using logging, error codes and messages
from glusterd and libglusterfs.
- This way, i though we could get complete isolation of
snapshot plugin implementation which avoids most of

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[sriram]

Hi Avra,

Do you have a bug id for this changes? Or may I raise a new one?

Sriram


On Fri, Sep 16, 2016, at 11:37 AM, sri...@marirs.net.in wrote:
> Thanks Avra,
>
> I'll send this patch to gluster master in a while.
>
> Sriram
>
>
> On Wed, Sep 14, 2016, at 03:08 PM, Avra Sengupta wrote:
>> Hi Sriram,
>>
>> Sorry for the delay in response. I started going through the
>> commits in the github repo. I finished going through the first
>> commit, where you create a plugin structure and move code.
>> Following is the commit link:
>>
>> https://github.com/sriramster/glusterfs/commit/7bf157525539541ebf0aa36a380bbedb2cae5440
>>
>> FIrst of all, the overall approach of using plugins, and maintaining
>> plugins that is used in the patch is in sync with what we had
>> discussed. There are some gaps though, like in the zfs functions the
>> snap brick is mounted without updating labels, and in restore you
>> perform a zfs rollback, which significantly changes the behavior
>> between how a lvm based snapshot and a zfs based snapshot.
>>
>> But before we get into these details, I would request you to kindly
>> send this particular patch to the gluster master branch, as that is
>> how we formally review patches, and I would say this particular patch
>> in itself is ready for a formal review. Once we straighten out the
>> quirks in this patch, we can significantly start moving the other
>> dependent patches to master and reviewing them. Thanks.
>>
>> Regards,
>> Avra
>>
>> P.S : Adding gluster-devel
>>
>> On 09/13/2016 01:14 AM, sri...@marirs.net.in wrote:
>>> Hi Avra,
>>>
>>> You'd time to look into the below request?
>>>
>>> Sriram
>>>
>>>
>>> On Thu, Sep 8, 2016, at 01:20 PM, sri...@marirs.net.in wrote:
 Hi Avra,

 Thank you. Please, let me know your feedback. It would be helpful
 on continuing from then.

 Sriram


 On Thu, Sep 8, 2016, at 01:18 PM, Avra Sengupta wrote:
> Hi Sriram,
>
> Rajesh is on a vacation, and will be available towards the end of
> next week. He will be sharing his feedback once he is back.
> Meanwhile I will have a look at the patch and share my feedback
> with you. But it will take me some time to go through it. Thanks.
>
> Regards,
> Avra
>
> On 09/08/2016 01:09 PM, sri...@marirs.net.in wrote:
>> Hello Rajesh,
>>
>> Sorry to bother. Could you have a look at the below request?
>>
>> Sriram
>>
>>
>> On Tue, Sep 6, 2016, at 11:27 AM, sri...@marirs.net.in wrote:
>>> Hello Rajesh,
>>>
>>> Sorry for the delayed mail, was on leave. Could you let me know
>>> the feedback?
>>>
>>> Sriram
>>>
>>>
>>> On Fri, Sep 2, 2016, at 10:08 AM, Rajesh Joseph wrote:
 + Avra
 Hi Srirram,

 Sorry, I was on leave therefore could not reply.
 Added Avra who is also working on the snapshot component for
 review.
 Will take a look at your changes today.
 Thanks & Regards,
 Rajesh


 On Thu, Sep 1, 2016 at 1:22 PM,  wrote:
>
> Hello Rajesh,
>
> Could you've a look at the below request?
>
> Sriram
>
> On Tue, Aug 30, 2016, at 01:03 PM, sri...@marirs.net.in wrote:
>> Hi Rajesh,
>>
>> Continuing from the discussion we've had below and
>> suggestions made by you, had created a plugin like structure
>> (A generic plugin model) and added snapshot to be the first
>> plugin implementation. Could you've a look if the approach is
>> fine? I've not raised a official review request yet. Could
>> you give an initial review of the model?
>>
>> https://github.com/sriramster/glusterfs/tree/sriram_dev
>>
>> Things done,
>>
>> - Created a new folder for glusterd plugins and added
>>   snapshot as a plugin. Like this,
>>
>> $ROOT/xlators/mgmt/glusterd/plugins+
>>  
>>   |

>>  
>>   +
__ snapshot/src
>>
>> Moved LVM related snapshot implementation to
>> xlators/mgmt/glusterd/plugins/snapshot/src/lvm-snapshot.c
>>
>> - Mostly isolated, glusterd code from snapshot implementation
>>   by using logging, error codes and messages from glusterd
>>   and libglusterfs.
>> - This way, i though we could get complete isolation of
>>   snapshot plugin implementation which avoids most of
>>   compiler and linking dependency issues.
>> - Created a library of the above like libgsnapshot.so and
>>   linking it with glusterd.so to get this working.
>> - The complete isolation also makes us to avoid reverse

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[sriram]

Thanks Avra,

I'll send this patch to gluster master in a while.

Sriram


On Wed, Sep 14, 2016, at 03:08 PM, Avra Sengupta wrote:
> Hi Sriram,
>
>  Sorry for the delay in response. I started going through the
>  commits in the github repo. I finished going through the first
>  commit, where you create a plugin structure and move code.
>  Following is the commit link:
>
> https://github.com/sriramster/glusterfs/commit/7bf157525539541ebf0aa36a380bbedb2cae5440
>
>  FIrst of all, the overall approach of using plugins, and maintaining
>  plugins that is used in the patch is in sync with what we had
>  discussed. There are some gaps though, like in the zfs functions the
>  snap brick is mounted without updating labels, and in restore you
>  perform a zfs rollback, which significantly changes the behavior
>  between how a lvm based snapshot and a zfs based snapshot.
>
>  But before we get into these details, I would request you to kindly
>  send this particular patch to the gluster master branch, as that is
>  how we formally review patches, and I would say this particular patch
>  in itself is ready for a formal review. Once we straighten out the
>  quirks in this patch, we can significantly start moving the other
>  dependent patches to master and reviewing them. Thanks.
>
>  Regards,
>  Avra
>
>  P.S : Adding gluster-devel
>
>  On 09/13/2016 01:14 AM, sri...@marirs.net.in wrote:
>> Hi Avra,
>>
>> You'd time to look into the below request?
>>
>> Sriram
>>
>>
>> On Thu, Sep 8, 2016, at 01:20 PM, sri...@marirs.net.in wrote:
>>> Hi Avra,
>>>
>>> Thank you. Please, let me know your feedback. It would be helpful on
>>> continuing from then.
>>>
>>> Sriram
>>>
>>>
>>> On Thu, Sep 8, 2016, at 01:18 PM, Avra Sengupta wrote:
 Hi Sriram,

 Rajesh is on a vacation, and will be available towards the end of
 next week. He will be sharing his feedback once he is back.
 Meanwhile I will have a look at the patch and share my feedback
 with you. But it will take me some time to go through it. Thanks.

 Regards,
 Avra

 On 09/08/2016 01:09 PM, sri...@marirs.net.in wrote:
> Hello Rajesh,
>
> Sorry to bother. Could you have a look at the below request?
>
> Sriram
>
>
> On Tue, Sep 6, 2016, at 11:27 AM, sri...@marirs.net.in wrote:
>> Hello Rajesh,
>>
>> Sorry for the delayed mail, was on leave. Could you let me know
>> the feedback?
>>
>> Sriram
>>
>>
>> On Fri, Sep 2, 2016, at 10:08 AM, Rajesh Joseph wrote:
>>> + Avra
>>> Hi Srirram,
>>>
>>> Sorry, I was on leave therefore could not reply.
>>> Added Avra who is also working on the snapshot component for
>>> review.
>>> Will take a look at your changes today.
>>> Thanks & Regards,
>>> Rajesh
>>>
>>>
>>> On Thu, Sep 1, 2016 at 1:22 PM,  wrote:

 Hello Rajesh,

 Could you've a look at the below request?

 Sriram

 On Tue, Aug 30, 2016, at 01:03 PM, sri...@marirs.net.in wrote:
> Hi Rajesh,
>
> Continuing from the discussion we've had below and suggestions
> made by you, had created a plugin like structure (A generic
> plugin model) and added snapshot to be the first plugin
> implementation. Could you've a look if the approach is fine?
> I've not raised a official review request yet. Could you give
> an initial review of the model?
>
> https://github.com/sriramster/glusterfs/tree/sriram_dev
>
> Things done,
>
> - Created a new folder for glusterd plugins and added snapshot
>   as a plugin. Like this,
>
> $ROOT/xlators/mgmt/glusterd/plugins+
>   
>  |

>   
>  +
__ snapshot/src
>
> Moved LVM related snapshot implementation to
> xlators/mgmt/glusterd/plugins/snapshot/src/lvm-snapshot.c
>
> - Mostly isolated, glusterd code from snapshot implementation
>   by using logging, error codes and messages from glusterd and
>   libglusterfs.
> - This way, i though we could get complete isolation of
>   snapshot plugin implementation which avoids most of compiler
>   and linking dependency issues.
> - Created a library of the above like libgsnapshot.so and
>   linking it with glusterd.so to get this working.
> - The complete isolation also makes us to avoid reverse
>   dependency like some api's inside plugin/snapshot being
>   dependent on glusterd.so
>
> TODO's :
>
> - Need to create glusterd_snapshot_ops structure which would
>   be used to register snapshot related API's with 

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Avra Sengupta]

Hi Sriram,

Sorry for the delay in response. I started going through the commits in 
the github repo. I finished going through the first commit, where you 
create a plugin structure and move code. Following is the commit link:


https://github.com/sriramster/glusterfs/commit/7bf157525539541ebf0aa36a380bbedb2cae5440

FIrst of all, the overall approach of using plugins, and maintaining 
plugins that is used in the patch is in sync with what we had discussed. 
There are some gaps though, like in the zfs functions the snap brick is 
mounted without updating labels, and in restore you perform a zfs 
rollback, which significantly changes the behavior between how a lvm 
based snapshot and a zfs based snapshot.


But before we get into these details, I would request you to kindly send 
this particular patch to the gluster master branch, as that is how we 
formally review patches, and I would say this particular patch in itself 
is ready for a formal review. Once we straighten out the quirks in this 
patch, we can significantly start moving the other dependent patches to 
master and reviewing them. Thanks.


Regards,
Avra

P.S : Adding gluster-devel

On 09/13/2016 01:14 AM, sri...@marirs.net.in wrote:

Hi Avra,

You'd time to look into the below request?

Sriram


On Thu, Sep 8, 2016, at 01:20 PM, sri...@marirs.net.in 
 wrote:

Hi Avra,

Thank you. Please, let me know your feedback. It would be helpful on 
continuing from then.


Sriram


On Thu, Sep 8, 2016, at 01:18 PM, Avra Sengupta wrote:

Hi Sriram,

Rajesh is on a vacation, and will be available towards the end of 
next week. He will be sharing his feedback once he is back. 
Meanwhile I will have a look at the patch and share my feedback with 
you. But it will take me some time to go through it. Thanks.


Regards,
Avra

On 09/08/2016 01:09 PM, sri...@marirs.net.in 
 wrote:

Hello Rajesh,

Sorry to bother. Could you have a look at the below request?

Sriram


On Tue, Sep 6, 2016, at 11:27 AM, sri...@marirs.net.in 
 wrote:

Hello Rajesh,

Sorry for the delayed mail, was on leave. Could you let me know 
the feedback?


Sriram


On Fri, Sep 2, 2016, at 10:08 AM, Rajesh Joseph wrote:

+ Avra
Hi Srirram,

Sorry, I was on leave therefore could not reply.
Added Avra who is also working on the snapshot component for review.
Will take a look at your changes today.
Thanks & Regards,
Rajesh


On Thu, Sep 1, 2016 at 1:22 PM, > wrote:



Hello Rajesh,

Could you've a look at the below request?

Sriram

On Tue, Aug 30, 2016, at 01:03 PM, sri...@marirs.net.in
 wrote:

Hi Rajesh,

Continuing from the discussion we've had below and
suggestions made by you, had created a plugin like structure
(A generic plugin model) and added snapshot to be the first
plugin implementation. Could you've a look if the approach
is fine? I've not raised a official review request yet.
Could you give an initial review of the model?

https://github.com/sriramster/glusterfs/tree/sriram_dev


Things done,

- Created a new folder for glusterd plugins and added
snapshot as a plugin. Like this,

$ROOT/xlators/mgmt/glusterd/plugins +
|
+ __ snapshot/src

Moved LVM related snapshot implementation to
xlators/mgmt/glusterd/plugins/snapshot/src/lvm-snapshot.c

- Mostly isolated, glusterd code from snapshot
implementation by using logging, error codes and messages
from glusterd and libglusterfs.
- This way, i though we could get complete isolation of
snapshot plugin implementation which avoids most of compiler
and linking dependency issues.
- Created a library of the above like libgsnapshot.so and
linking it with glusterd.so to get this working.
- The complete isolation also makes us to avoid reverse
dependency like some api's inside plugin/snapshot being
dependent on glusterd.so

TODO's :

- Need to create glusterd_snapshot_ops structure which would
be used to register snapshot related API's with glusterd.so.
- Add command line snapshot plugin option, so that it picks
up on compilation.
- If any missed implementation for plugin.
- Cleanup and get a review ready branch.

Let me know if this looks ok? Or need to any more into the
list.

Sriram

On Fri, Jul 22, 2016, at 02:43 PM, Rajesh Joseph wrote:



On Thu, Jul 21, 2016 at 3:07 AM, Vijay Bellur
> wrote:

On 07/19/2016 11:01 AM, Atin Mukherjee wrote:



On Tue, Jul 19, 2016 at 7:29 PM, Rajesh Joseph

>> wrote:



On Tue, Jul 19, 2016 at 11:23 

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Rajesh Joseph]

On Thu, Jul 21, 2016 at 3:07 AM, Vijay Bellur  wrote:

> On 07/19/2016 11:01 AM, Atin Mukherjee wrote:
>
>>
>>
>> On Tue, Jul 19, 2016 at 7:29 PM, Rajesh Joseph > > wrote:
>>
>>
>>
>> On Tue, Jul 19, 2016 at 11:23 AM, > > wrote:
>>
>> __
>> Hi Rajesh,
>>
>> I'd thought about moving the zfs specific implementation to
>> something like
>>
>> xlators/mgmt/glusterd/src/plugins/zfs-specifs-stuffs for the
>> inital go. Could you let me know if this works or in sync with
>> what you'd thought about?
>>
>> Sriram
>>
>>
>> Hi Sriram,
>>
>> Sorry, I was not able to send much time on this. I would prefer you
>> move the code to
>>
>> xlators/mgmt/glusterd/plugins/src/zfs-specifs-stuffs
>>
>>
>>
>> How about having it under
>> xlators/mgmt/glusterd/plugins/snapshot/src/zfs-specifs-stuffs such that
>> in future if we have to write plugins for other features they can be
>> segregated?
>>
>>
> It would be nicer to avoid "specific-stuff" or similar from the naming. We
> can probably leave it at xlators/mgmt/glusterd/plugins/snapshot/src/zfs.
> The naming would be sufficient to indicate that code is specific to zfs
> snapshots.
>

I don't think the directory would be named "zfs-specific_stuffs, instead
zfs specific source file will come directly under
"xlators/mgmt/glusterd/plugins/snapshot/src/".
I think I should have been more clear, my bad.

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

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Vijay Bellur]

On 07/19/2016 11:01 AM, Atin Mukherjee wrote:



On Tue, Jul 19, 2016 at 7:29 PM, Rajesh Joseph > wrote:



On Tue, Jul 19, 2016 at 11:23 AM, > wrote:

__
Hi Rajesh,

I'd thought about moving the zfs specific implementation to
something like

xlators/mgmt/glusterd/src/plugins/zfs-specifs-stuffs for the
inital go. Could you let me know if this works or in sync with
what you'd thought about?

Sriram


Hi Sriram,

Sorry, I was not able to send much time on this. I would prefer you
move the code to

xlators/mgmt/glusterd/plugins/src/zfs-specifs-stuffs



How about having it under
xlators/mgmt/glusterd/plugins/snapshot/src/zfs-specifs-stuffs such that
in future if we have to write plugins for other features they can be
segregated?



It would be nicer to avoid "specific-stuff" or similar from the naming. 
We can probably leave it at 
xlators/mgmt/glusterd/plugins/snapshot/src/zfs. The naming would be 
sufficient to indicate that code is specific to zfs snapshots.


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

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Atin Mukherjee]

On Tue, Jul 19, 2016 at 7:29 PM, Rajesh Joseph  wrote:

>
>
> On Tue, Jul 19, 2016 at 11:23 AM,  wrote:
>
>> Hi Rajesh,
>>
>> I'd thought about moving the zfs specific implementation to something
>> like
>>
>> xlators/mgmt/glusterd/src/plugins/zfs-specifs-stuffs for the inital go.
>> Could you let me know if this works or in sync with what you'd thought
>> about?
>>
>> Sriram
>>
>
> Hi Sriram,
>
> Sorry, I was not able to send much time on this. I would prefer you move
> the code to
>
> xlators/mgmt/glusterd/plugins/src/zfs-specifs-stuffs
>


How about having it under
xlators/mgmt/glusterd/plugins/snapshot/src/zfs-specifs-stuffs such that in
future if we have to write plugins for other features they can be
segregated?


> atinm and others do let us know if you have any objection to this.
>
> I captured our initial discussions on an etherpad (
> https://public.pad.fsfe.org/p/gluster-volume-snapshots). I will update it
> further, meanwhile you can also
> capture more details in the etherpad if needed.
>
> Best Regards,
> Rajesh
>
>
>
>>
>> On Tue, Jul 12, 2016, at 03:52 PM, sri...@marirs.net.in wrote:
>>
>> Hi Rajesh,
>>
>> Sure thanks.
>>
>> Sriram
>>
>>
>> On Tue, Jul 12, 2016, at 03:07 PM, Rajesh Joseph wrote:
>>
>> Hi Sriram,
>> The interface is not yet finalized. May be this is the right time to
>> re-ignite discussion on this.
>> I can create an etherpad which will explain the initial thoughts and
>> design ideas on the same.
>> Thanks & Regards,
>> Rajesh
>>
>> On Mon, Jul 11, 2016 at 11:57 PM,  wrote:
>>
>>
>> Hi Rajesh,
>>
>> Could you let us know the idea on how to go about this?
>>
>> Sriram
>>
>>
>> On Wed, Jul 6, 2016, at 03:18 PM, Pranith Kumar Karampuri wrote:
>>
>> I believe Rajesh already has something here. May be he can post an
>> outline so that we can take it from there?
>>
>> On Tue, Jul 5, 2016 at 10:52 PM,  wrote:
>>
>>
>> Hi,
>>
>> I tried to go through the patch and find the reason behind the question
>> posted. But could'nt get any concrete details about the same.
>>
>> When going through the mail chain, there were mentions of generic
>> snapshot interface. I'd be interested in doing the changes if you guys
>> could fill me with some initial information. Thanks.
>>
>> Sriram
>>
>>
>> On Mon, Jul 4, 2016, at 01:59 PM, B.K.Raghuram wrote:
>>
>> Hi Rajesh,
>> I did not want to respond to the question that you'd posed on the zfs
>> snapshot code (about the volume backend backup) as I am not too familiar
>> with the code and the person who's coded it is not with us anymore. This
>> was done in bit of a hurry so it could be that it was just kept for later..
>>
>> However, Sriram who is cc'd on this email, has been helping us by
>> starting to look at the gluster code  and has expressed an interest in
>> taking the zfs code changes on. So he can probably dig out an answer to
>> your question. Sriram, Rajesh had a question on one of the zfs related
>> patches - (
>> https://github.com/fractalio/glusterfs/commit/39a163eca338b6da146f72f380237abd4c671db2#commitcomment-18109851
>> )
>>
>> Sriram is also interested in contributing to the process of creating a
>> generic snapshot interface in the gluster code which you and Pranith
>> mentioned above. If this is ok with you all, could you fill him in on what
>> your thoughts are on that and how he could get started?
>> Thanks!
>> -Ram
>>
>> On Wed, Jun 22, 2016 at 11:45 AM, Rajesh Joseph 
>> wrote:
>>
>>
>>
>> On Tue, Jun 21, 2016 at 4:24 PM, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>> hi,
>>   Is there a plan to come up with an interface for snapshot
>> functionality? For example, in handling different types of sockets in
>> gluster all we need to do is to specify which interface we want to use and
>> ib,network-socket,unix-domain sockets all implement the interface. The code
>> doesn't have to assume anything about underlying socket type. Do you guys
>> think it is a worthwhile effort to separate out the logic of interface and
>> the code which uses snapshots? I see quite a few of if (strcmp ("zfs",
>> fstype)) code which can all be removed if we do this. Giving btrfs
>> snapshots in future will be a breeze as well, this way? All we need to do
>> is implementing snapshot interface using btrfs snapshot commands. I am not
>> talking about this patch per se. Just wanted to seek your inputs about
>> future plans for ease of maintaining the feature.
>>
>>
>>
>> As I said in my previous mail this is in plan and we will be doing it.
>> But due to other priorities this was not taken in yet.
>>
>>
>>
>>
>>
>> On Tue, Jun 21, 2016 at 11:46 AM, Atin Mukherjee 
>> wrote:
>>
>>
>>
>> On 06/21/2016 11:41 AM, Rajesh Joseph wrote:
>> > What kind of locking issues you see? If you can provide some more
>> > information I can be able to help you.
>>
>> That's related to stale lock issues on GlusterD which are there 

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Rajesh Joseph]

On Tue, Jul 19, 2016 at 11:23 AM,  wrote:

> Hi Rajesh,
>
> I'd thought about moving the zfs specific implementation to something like
>
> xlators/mgmt/glusterd/src/plugins/zfs-specifs-stuffs for the inital go.
> Could you let me know if this works or in sync with what you'd thought
> about?
>
> Sriram
>

Hi Sriram,

Sorry, I was not able to send much time on this. I would prefer you move
the code to

xlators/mgmt/glusterd/plugins/src/zfs-specifs-stuffs

atinm and others do let us know if you have any objection to this.

I captured our initial discussions on an etherpad (
https://public.pad.fsfe.org/p/gluster-volume-snapshots). I will update it
further, meanwhile you can also
capture more details in the etherpad if needed.

Best Regards,
Rajesh



>
> On Tue, Jul 12, 2016, at 03:52 PM, sri...@marirs.net.in wrote:
>
> Hi Rajesh,
>
> Sure thanks.
>
> Sriram
>
>
> On Tue, Jul 12, 2016, at 03:07 PM, Rajesh Joseph wrote:
>
> Hi Sriram,
> The interface is not yet finalized. May be this is the right time to
> re-ignite discussion on this.
> I can create an etherpad which will explain the initial thoughts and
> design ideas on the same.
> Thanks & Regards,
> Rajesh
>
> On Mon, Jul 11, 2016 at 11:57 PM,  wrote:
>
>
> Hi Rajesh,
>
> Could you let us know the idea on how to go about this?
>
> Sriram
>
>
> On Wed, Jul 6, 2016, at 03:18 PM, Pranith Kumar Karampuri wrote:
>
> I believe Rajesh already has something here. May be he can post an outline
> so that we can take it from there?
>
> On Tue, Jul 5, 2016 at 10:52 PM,  wrote:
>
>
> Hi,
>
> I tried to go through the patch and find the reason behind the question
> posted. But could'nt get any concrete details about the same.
>
> When going through the mail chain, there were mentions of generic snapshot
> interface. I'd be interested in doing the changes if you guys could fill me
> with some initial information. Thanks.
>
> Sriram
>
>
> On Mon, Jul 4, 2016, at 01:59 PM, B.K.Raghuram wrote:
>
> Hi Rajesh,
> I did not want to respond to the question that you'd posed on the zfs
> snapshot code (about the volume backend backup) as I am not too familiar
> with the code and the person who's coded it is not with us anymore. This
> was done in bit of a hurry so it could be that it was just kept for later..
>
> However, Sriram who is cc'd on this email, has been helping us by starting
> to look at the gluster code  and has expressed an interest in taking the
> zfs code changes on. So he can probably dig out an answer to your question.
> Sriram, Rajesh had a question on one of the zfs related patches - (
> https://github.com/fractalio/glusterfs/commit/39a163eca338b6da146f72f380237abd4c671db2#commitcomment-18109851
> )
>
> Sriram is also interested in contributing to the process of creating a
> generic snapshot interface in the gluster code which you and Pranith
> mentioned above. If this is ok with you all, could you fill him in on what
> your thoughts are on that and how he could get started?
> Thanks!
> -Ram
>
> On Wed, Jun 22, 2016 at 11:45 AM, Rajesh Joseph 
> wrote:
>
>
>
> On Tue, Jun 21, 2016 at 4:24 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
> hi,
>   Is there a plan to come up with an interface for snapshot
> functionality? For example, in handling different types of sockets in
> gluster all we need to do is to specify which interface we want to use and
> ib,network-socket,unix-domain sockets all implement the interface. The code
> doesn't have to assume anything about underlying socket type. Do you guys
> think it is a worthwhile effort to separate out the logic of interface and
> the code which uses snapshots? I see quite a few of if (strcmp ("zfs",
> fstype)) code which can all be removed if we do this. Giving btrfs
> snapshots in future will be a breeze as well, this way? All we need to do
> is implementing snapshot interface using btrfs snapshot commands. I am not
> talking about this patch per se. Just wanted to seek your inputs about
> future plans for ease of maintaining the feature.
>
>
>
> As I said in my previous mail this is in plan and we will be doing it. But
> due to other priorities this was not taken in yet.
>
>
>
>
>
> On Tue, Jun 21, 2016 at 11:46 AM, Atin Mukherjee 
> wrote:
>
>
>
> On 06/21/2016 11:41 AM, Rajesh Joseph wrote:
> > What kind of locking issues you see? If you can provide some more
> > information I can be able to help you.
>
> That's related to stale lock issues on GlusterD which are there in 3.6.1
> since the fixes landed in the branch post 3.6.1. I have already provided
> the workaround/way to fix them [1]
>
> [1]
> http://www.gluster.org/pipermail/gluster-users/2016-June/thread.html#26995
>
> ~Atin
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
>
>
>
>
> --
> Pranith
>
>
>
>
>
>
>
>
>
> 

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[sriram]

Hi Rajesh,
 
I'd thought about moving the zfs specific implementation to
something like
 
xlators/mgmt/glusterd/src/plugins/zfs-specifs-stuffs for the inital
go. Could you let me know if this works or in sync with what you'd
thought about?
 
Sriram
 
 
On Tue, Jul 12, 2016, at 03:52 PM, sri...@marirs.net.in wrote:
> Hi Rajesh,
>
> Sure thanks.
>
> Sriram
>
>
> On Tue, Jul 12, 2016, at 03:07 PM, Rajesh Joseph wrote:
>> Hi Sriram,
>> The interface is not yet finalized. May be this is the right time to
>> re-ignite discussion on this.
>> I can create an etherpad which will explain the initial thoughts and
>> design ideas on the same.
>> Thanks & Regards,
>> Rajesh
>>
>> On Mon, Jul 11, 2016 at 11:57 PM,  wrote:
>>> __
>>> Hi Rajesh,
>>>
>>> Could you let us know the idea on how to go about this?
>>>
>>> Sriram
>>>
>>>
>>> On Wed, Jul 6, 2016, at 03:18 PM, Pranith Kumar Karampuri wrote:
 I believe Rajesh already has something here. May be he can post an
 outline so that we can take it from there?

 On Tue, Jul 5, 2016 at 10:52 PM,  wrote:
> __
> Hi,
>
> I tried to go through the patch and find the reason behind the
> question posted. But could'nt get any concrete details about the
> same.
>
> When going through the mail chain, there were mentions of generic
> snapshot interface. I'd be interested in doing the changes if you
> guys could fill me with some initial information. Thanks.
>
> Sriram
>
>
> On Mon, Jul 4, 2016, at 01:59 PM, B.K.Raghuram wrote:
>> Hi Rajesh,
>> I did not want to respond to the question that you'd posed on the
>> zfs snapshot code (about the volume backend backup) as I am not
>> too familiar with the code and the person who's coded it is not
>> with us anymore. This was done in bit of a hurry so it could be
>> that it was just kept for later..
>>
>> However, Sriram who is cc'd on this email, has been helping us by
>> starting to look at the gluster code  and has expressed an
>> interest in taking the zfs code changes on. So he can probably
>> dig out an answer to your question. Sriram, Rajesh had a question
>> on one of the zfs related patches -
>> (https://github.com/fractalio/glusterfs/commit/39a163eca338b6da146f72f380237abd4c671db2#commitcomment-18109851)
>>
>> Sriram is also interested in contributing to the process of
>> creating a generic snapshot interface in the gluster code which
>> you and Pranith mentioned above. If this is ok with you all,
>> could you fill him in on what your thoughts are on that and how
>> he could get started?
>> Thanks!
>> -Ram
>>
>> On Wed, Jun 22, 2016 at 11:45 AM, Rajesh Joseph
>>  wrote:
>>>
>>>
>>> On Tue, Jun 21, 2016 at 4:24 PM, Pranith Kumar Karampuri
>>>  wrote:
 hi,
   Is there a plan to come up with an interface for snapshot
   functionality? For example, in handling different types
   of sockets in gluster all we need to do is to specify
   which interface we want to use and ib,network-socket,unix-
   domain sockets all implement the interface. The code
   doesn't have to assume anything about underlying socket
   type. Do you guys think it is a worthwhile effort to
   separate out the logic of interface and the code which
   uses snapshots? I see quite a few of if (strcmp ("zfs",
   fstype)) code which can all be removed if we do this.
   Giving btrfs snapshots in future will be a breeze as
   well, this way? All we need to do is implementing
   snapshot interface using btrfs snapshot commands. I am
   not talking about this patch per se. Just wanted to seek
   your inputs about future plans for ease of maintaining
   the feature.
>>>
>>>
>>> As I said in my previous mail this is in plan and we will be
>>> doing it. But due to other priorities this was not taken in yet.
>>>
>>>


 On Tue, Jun 21, 2016 at 11:46 AM, Atin Mukherjee
  wrote:
>
>
> On 06/21/2016 11:41 AM, Rajesh Joseph wrote:
>  > What kind of locking issues you see? If you can provide
>  > some more information I can be able to help you.
>
> That's related to stale lock issues on GlusterD which are
> there in 3.6.1 since the fixes landed in the branch post
> 3.6.1. I have already provided the workaround/way to fix them
> [1]
>
>  
> [1]http://www.gluster.org/pipermail/gluster-users/2016-June/thread.html#26995
>
>  ~Atin
>
> ___
>  Gluster-devel mailing 

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Rajesh Joseph]

Hi Sriram,

The interface is not yet finalized. May be this is the right time to
re-ignite discussion on this.
I can create an etherpad which will explain the initial thoughts and design
ideas on the same.

Thanks & Regards,
Rajesh

On Mon, Jul 11, 2016 at 11:57 PM,  wrote:

> Hi Rajesh,
>
> Could you let us know the idea on how to go about this?
>
> Sriram
>
>
> On Wed, Jul 6, 2016, at 03:18 PM, Pranith Kumar Karampuri wrote:
>
> I believe Rajesh already has something here. May be he can post an outline
> so that we can take it from there?
>
> On Tue, Jul 5, 2016 at 10:52 PM,  wrote:
>
>
> Hi,
>
> I tried to go through the patch and find the reason behind the question
> posted. But could'nt get any concrete details about the same.
>
> When going through the mail chain, there were mentions of generic snapshot
> interface. I'd be interested in doing the changes if you guys could fill me
> with some initial information. Thanks.
>
> Sriram
>
>
> On Mon, Jul 4, 2016, at 01:59 PM, B.K.Raghuram wrote:
>
> Hi Rajesh,
> I did not want to respond to the question that you'd posed on the zfs
> snapshot code (about the volume backend backup) as I am not too familiar
> with the code and the person who's coded it is not with us anymore. This
> was done in bit of a hurry so it could be that it was just kept for later..
>
> However, Sriram who is cc'd on this email, has been helping us by starting
> to look at the gluster code  and has expressed an interest in taking the
> zfs code changes on. So he can probably dig out an answer to your question.
> Sriram, Rajesh had a question on one of the zfs related patches - (
> https://github.com/fractalio/glusterfs/commit/39a163eca338b6da146f72f380237abd4c671db2#commitcomment-18109851
> )
>
> Sriram is also interested in contributing to the process of creating a
> generic snapshot interface in the gluster code which you and Pranith
> mentioned above. If this is ok with you all, could you fill him in on what
> your thoughts are on that and how he could get started?
> Thanks!
> -Ram
>
> On Wed, Jun 22, 2016 at 11:45 AM, Rajesh Joseph 
> wrote:
>
>
>
> On Tue, Jun 21, 2016 at 4:24 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
> hi,
>   Is there a plan to come up with an interface for snapshot
> functionality? For example, in handling different types of sockets in
> gluster all we need to do is to specify which interface we want to use and
> ib,network-socket,unix-domain sockets all implement the interface. The code
> doesn't have to assume anything about underlying socket type. Do you guys
> think it is a worthwhile effort to separate out the logic of interface and
> the code which uses snapshots? I see quite a few of if (strcmp ("zfs",
> fstype)) code which can all be removed if we do this. Giving btrfs
> snapshots in future will be a breeze as well, this way? All we need to do
> is implementing snapshot interface using btrfs snapshot commands. I am not
> talking about this patch per se. Just wanted to seek your inputs about
> future plans for ease of maintaining the feature.
>
>
>
> As I said in my previous mail this is in plan and we will be doing it. But
> due to other priorities this was not taken in yet.
>
>
>
>
>
> On Tue, Jun 21, 2016 at 11:46 AM, Atin Mukherjee 
> wrote:
>
>
>
> On 06/21/2016 11:41 AM, Rajesh Joseph wrote:
> > What kind of locking issues you see? If you can provide some more
> > information I can be able to help you.
>
> That's related to stale lock issues on GlusterD which are there in 3.6.1
> since the fixes landed in the branch post 3.6.1. I have already provided
> the workaround/way to fix them [1]
>
> [1]
> http://www.gluster.org/pipermail/gluster-users/2016-June/thread.html#26995
>
> ~Atin
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
>
>
>
>
> --
> Pranith
>
>
>
>
>
>
>
>
>
> --
> Pranith
>
>
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[sriram]

Hi Rajesh,
 
Could you let us know the idea on how to go about this?
 
Sriram
 
 
On Wed, Jul 6, 2016, at 03:18 PM, Pranith Kumar Karampuri wrote:
> I believe Rajesh already has something here. May be he can post an
> outline so that we can take it from there?
>
> On Tue, Jul 5, 2016 at 10:52 PM,  wrote:
>> __
>> Hi,
>>
>> I tried to go through the patch and find the reason behind the
>> question posted. But could'nt get any concrete details about
>> the same.
>>
>> When going through the mail chain, there were mentions of generic
>> snapshot interface. I'd be interested in doing the changes if you
>> guys could fill me with some initial information. Thanks.
>>
>> Sriram
>>
>>
>> On Mon, Jul 4, 2016, at 01:59 PM, B.K.Raghuram wrote:
>>> Hi Rajesh,
>>> I did not want to respond to the question that you'd posed on the
>>> zfs snapshot code (about the volume backend backup) as I am not too
>>> familiar with the code and the person who's coded it is not with us
>>> anymore. This was done in bit of a hurry so it could be that it was
>>> just kept for later..
>>>
>>> However, Sriram who is cc'd on this email, has been helping us by
>>> starting to look at the gluster code  and has expressed an interest
>>> in taking the zfs code changes on. So he can probably dig out an
>>> answer to your question. Sriram, Rajesh had a question on one of the
>>> zfs related patches -
>>> (https://github.com/fractalio/glusterfs/commit/39a163eca338b6da146f72f380237abd4c671db2#commitcomment-18109851)
>>>
>>> Sriram is also interested in contributing to the process of creating
>>> a generic snapshot interface in the gluster code which you and
>>> Pranith mentioned above. If this is ok with you all, could you fill
>>> him in on what your thoughts are on that and how he could get
>>> started?
>>> Thanks!
>>> -Ram
>>>
>>> On Wed, Jun 22, 2016 at 11:45 AM, Rajesh Joseph 
>>> wrote:


 On Tue, Jun 21, 2016 at 4:24 PM, Pranith Kumar Karampuri
  wrote:
> hi,
>   Is there a plan to come up with an interface for snapshot
>   functionality? For example, in handling different types of
>   sockets in gluster all we need to do is to specify which
>   interface we want to use and ib,network-socket,unix-domain
>   sockets all implement the interface. The code doesn't have
>   to assume anything about underlying socket type. Do you guys
>   think it is a worthwhile effort to separate out the logic of
>   interface and the code which uses snapshots? I see quite a
>   few of if (strcmp ("zfs", fstype)) code which can all be
>   removed if we do this. Giving btrfs snapshots in future will
>   be a breeze as well, this way? All we need to do is
>   implementing snapshot interface using btrfs snapshot
>   commands. I am not talking about this patch per se. Just
>   wanted to seek your inputs about future plans for ease of
>   maintaining the feature.


 As I said in my previous mail this is in plan and we will be doing
 it. But due to other priorities this was not taken in yet.


>
>
> On Tue, Jun 21, 2016 at 11:46 AM, Atin Mukherjee
>  wrote:
>>
>>
>> On 06/21/2016 11:41 AM, Rajesh Joseph wrote:
>>  > What kind of locking issues you see? If you can provide some
>>  > more information I can be able to help you.
>>
>> That's related to stale lock issues on GlusterD which are there
>> in 3.6.1 since the fixes landed in the branch post 3.6.1. I have
>> already provided the workaround/way to fix them [1]
>>
>>  
>> [1]http://www.gluster.org/pipermail/gluster-users/2016-June/thread.html#26995
>>
>>  ~Atin
>>
>> ___
>>  Gluster-devel mailing list Gluster-devel@gluster.org
>>  http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Pranith
>

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

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[sriram]

Hi,
 
I tried to go through the patch and find the reason behind the question
posted. But could'nt get any concrete details about the same.
 
When going through the mail chain, there were mentions of generic
snapshot interface. I'd be interested in doing the changes if you guys
could fill me with some initial information. Thanks.
 
Sriram
 
 
On Mon, Jul 4, 2016, at 01:59 PM, B.K.Raghuram wrote:
> Hi Rajesh,
> I did not want to respond to the question that you'd posed on the zfs
> snapshot code (about the volume backend backup) as I am not too
> familiar with the code and the person who's coded it is not with us
> anymore. This was done in bit of a hurry so it could be that it was
> just kept for later..
>
> However, Sriram who is cc'd on this email, has been helping us by
> starting to look at the gluster code  and has expressed an interest in
> taking the zfs code changes on. So he can probably dig out an answer
> to your question. Sriram, Rajesh had a question on one of the zfs
> related patches -
> (https://github.com/fractalio/glusterfs/commit/39a163eca338b6da146f72f380237abd4c671db2#commitcomment-18109851)
>
> Sriram is also interested in contributing to the process of creating a
> generic snapshot interface in the gluster code which you and Pranith
> mentioned above. If this is ok with you all, could you fill him in on
> what your thoughts are on that and how he could get started?
> Thanks!
> -Ram
>
> On Wed, Jun 22, 2016 at 11:45 AM, Rajesh Joseph
>  wrote:
>>
>>
>> On Tue, Jun 21, 2016 at 4:24 PM, Pranith Kumar Karampuri
>>  wrote:
>>> hi,
>>>   Is there a plan to come up with an interface for snapshot
>>>   functionality? For example, in handling different types of
>>>   sockets in gluster all we need to do is to specify which
>>>   interface we want to use and ib,network-socket,unix-domain
>>>   sockets all implement the interface. The code doesn't have to
>>>   assume anything about underlying socket type. Do you guys
>>>   think it is a worthwhile effort to separate out the logic of
>>>   interface and the code which uses snapshots? I see quite a few
>>>   of if (strcmp ("zfs", fstype)) code which can all be removed
>>>   if we do this. Giving btrfs snapshots in future will be a
>>>   breeze as well, this way? All we need to do is implementing
>>>   snapshot interface using btrfs snapshot commands. I am not
>>>   talking about this patch per se. Just wanted to seek your
>>>   inputs about future plans for ease of maintaining the feature.
>>
>>
>> As I said in my previous mail this is in plan and we will be doing
>> it. But due to other priorities this was not taken in yet.
>>
>>
>>>
>>>
>>> On Tue, Jun 21, 2016 at 11:46 AM, Atin Mukherjee
>>>  wrote:


 On 06/21/2016 11:41 AM, Rajesh Joseph wrote:
  > What kind of locking issues you see? If you can provide some
  > more information I can be able to help you.

 That's related to stale lock issues on GlusterD which are there in
 3.6.1 since the fixes landed in the branch post 3.6.1. I have
 already provided the workaround/way to fix them [1]

  
 [1]http://www.gluster.org/pipermail/gluster-users/2016-June/thread.html#26995

  ~Atin

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

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

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[B.K.Raghuram]

Hi Rajesh,

I did not want to respond to the question that you'd posed on the zfs
snapshot code (about the volume backend backup) as I am not too familiar
with the code and the person who's coded it is not with us anymore. This
was done in bit of a hurry so it could be that it was just kept for later..

However, Sriram who is cc'd on this email, has been helping us by starting
to look at the gluster code  and has expressed an interest in taking the
zfs code changes on. So he can probably dig out an answer to your question.
Sriram, Rajesh had a question on one of the zfs related patches - (
https://github.com/fractalio/glusterfs/commit/39a163eca338b6da146f72f380237abd4c671db2#commitcomment-18109851
)

Sriram is also interested in contributing to the process of creating a
generic snapshot interface in the gluster code which you and Pranith
mentioned above. If this is ok with you all, could you fill him in on what
your thoughts are on that and how he could get started?

Thanks!
-Ram

On Wed, Jun 22, 2016 at 11:45 AM, Rajesh Joseph  wrote:

>
>
> On Tue, Jun 21, 2016 at 4:24 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> hi,
>>   Is there a plan to come up with an interface for snapshot
>> functionality? For example, in handling different types of sockets in
>> gluster all we need to do is to specify which interface we want to use and
>> ib,network-socket,unix-domain sockets all implement the interface. The code
>> doesn't have to assume anything about underlying socket type. Do you guys
>> think it is a worthwhile effort to separate out the logic of interface and
>> the code which uses snapshots? I see quite a few of if (strcmp ("zfs",
>> fstype)) code which can all be removed if we do this. Giving btrfs
>> snapshots in future will be a breeze as well, this way? All we need to do
>> is implementing snapshot interface using btrfs snapshot commands. I am not
>> talking about this patch per se. Just wanted to seek your inputs about
>> future plans for ease of maintaining the feature.
>>
>
> As I said in my previous mail this is in plan and we will be doing it. But
> due to other priorities this was not taken in yet.
>
>
>>
>> On Tue, Jun 21, 2016 at 11:46 AM, Atin Mukherjee 
>> wrote:
>>
>>>
>>>
>>> On 06/21/2016 11:41 AM, Rajesh Joseph wrote:
>>> > What kind of locking issues you see? If you can provide some more
>>> > information I can be able to help you.
>>>
>>> That's related to stale lock issues on GlusterD which are there in 3.6.1
>>> since the fixes landed in the branch post 3.6.1. I have already provided
>>> the workaround/way to fix them [1]
>>>
>>> [1]
>>>
>>> http://www.gluster.org/pipermail/gluster-users/2016-June/thread.html#26995
>>>
>>> ~Atin
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
>> --
>> Pranith
>>
>
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Pranith Kumar Karampuri]

Cool. Nice to know it is on the cards.

On Wed, Jun 22, 2016 at 11:45 AM, Rajesh Joseph  wrote:

>
>
> On Tue, Jun 21, 2016 at 4:24 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> hi,
>>   Is there a plan to come up with an interface for snapshot
>> functionality? For example, in handling different types of sockets in
>> gluster all we need to do is to specify which interface we want to use and
>> ib,network-socket,unix-domain sockets all implement the interface. The code
>> doesn't have to assume anything about underlying socket type. Do you guys
>> think it is a worthwhile effort to separate out the logic of interface and
>> the code which uses snapshots? I see quite a few of if (strcmp ("zfs",
>> fstype)) code which can all be removed if we do this. Giving btrfs
>> snapshots in future will be a breeze as well, this way? All we need to do
>> is implementing snapshot interface using btrfs snapshot commands. I am not
>> talking about this patch per se. Just wanted to seek your inputs about
>> future plans for ease of maintaining the feature.
>>
>
> As I said in my previous mail this is in plan and we will be doing it. But
> due to other priorities this was not taken in yet.
>
>
>>
>> On Tue, Jun 21, 2016 at 11:46 AM, Atin Mukherjee 
>> wrote:
>>
>>>
>>>
>>> On 06/21/2016 11:41 AM, Rajesh Joseph wrote:
>>> > What kind of locking issues you see? If you can provide some more
>>> > information I can be able to help you.
>>>
>>> That's related to stale lock issues on GlusterD which are there in 3.6.1
>>> since the fixes landed in the branch post 3.6.1. I have already provided
>>> the workaround/way to fix them [1]
>>>
>>> [1]
>>>
>>> http://www.gluster.org/pipermail/gluster-users/2016-June/thread.html#26995
>>>
>>> ~Atin
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
>> --
>> Pranith
>>
>
>


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

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Rajesh Joseph]

On Tue, Jun 21, 2016 at 4:24 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

> hi,
>   Is there a plan to come up with an interface for snapshot
> functionality? For example, in handling different types of sockets in
> gluster all we need to do is to specify which interface we want to use and
> ib,network-socket,unix-domain sockets all implement the interface. The code
> doesn't have to assume anything about underlying socket type. Do you guys
> think it is a worthwhile effort to separate out the logic of interface and
> the code which uses snapshots? I see quite a few of if (strcmp ("zfs",
> fstype)) code which can all be removed if we do this. Giving btrfs
> snapshots in future will be a breeze as well, this way? All we need to do
> is implementing snapshot interface using btrfs snapshot commands. I am not
> talking about this patch per se. Just wanted to seek your inputs about
> future plans for ease of maintaining the feature.
>

As I said in my previous mail this is in plan and we will be doing it. But
due to other priorities this was not taken in yet.


>
> On Tue, Jun 21, 2016 at 11:46 AM, Atin Mukherjee 
> wrote:
>
>>
>>
>> On 06/21/2016 11:41 AM, Rajesh Joseph wrote:
>> > What kind of locking issues you see? If you can provide some more
>> > information I can be able to help you.
>>
>> That's related to stale lock issues on GlusterD which are there in 3.6.1
>> since the fixes landed in the branch post 3.6.1. I have already provided
>> the workaround/way to fix them [1]
>>
>> [1]
>> http://www.gluster.org/pipermail/gluster-users/2016-June/thread.html#26995
>>
>> ~Atin
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Pranith
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[B.K.Raghuram]

Second that. That kind of interface would be a great idea although I don't
know how much work that would involve in the snapshot interface redesign..

On Tue, Jun 21, 2016 at 4:24 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

> hi,
>   Is there a plan to come up with an interface for snapshot
> functionality? For example, in handling different types of sockets in
> gluster all we need to do is to specify which interface we want to use and
> ib,network-socket,unix-domain sockets all implement the interface. The code
> doesn't have to assume anything about underlying socket type. Do you guys
> think it is a worthwhile effort to separate out the logic of interface and
> the code which uses snapshots? I see quite a few of if (strcmp ("zfs",
> fstype)) code which can all be removed if we do this. Giving btrfs
> snapshots in future will be a breeze as well, this way? All we need to do
> is implementing snapshot interface using btrfs snapshot commands. I am not
> talking about this patch per se. Just wanted to seek your inputs about
> future plans for ease of maintaining the feature.
>
> On Tue, Jun 21, 2016 at 11:46 AM, Atin Mukherjee 
> wrote:
>
>>
>>
>> On 06/21/2016 11:41 AM, Rajesh Joseph wrote:
>> > What kind of locking issues you see? If you can provide some more
>> > information I can be able to help you.
>>
>> That's related to stale lock issues on GlusterD which are there in 3.6.1
>> since the fixes landed in the branch post 3.6.1. I have already provided
>> the workaround/way to fix them [1]
>>
>> [1]
>> http://www.gluster.org/pipermail/gluster-users/2016-June/thread.html#26995
>>
>> ~Atin
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
>
> --
> Pranith
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Pranith Kumar Karampuri]

hi,
  Is there a plan to come up with an interface for snapshot
functionality? For example, in handling different types of sockets in
gluster all we need to do is to specify which interface we want to use and
ib,network-socket,unix-domain sockets all implement the interface. The code
doesn't have to assume anything about underlying socket type. Do you guys
think it is a worthwhile effort to separate out the logic of interface and
the code which uses snapshots? I see quite a few of if (strcmp ("zfs",
fstype)) code which can all be removed if we do this. Giving btrfs
snapshots in future will be a breeze as well, this way? All we need to do
is implementing snapshot interface using btrfs snapshot commands. I am not
talking about this patch per se. Just wanted to seek your inputs about
future plans for ease of maintaining the feature.

On Tue, Jun 21, 2016 at 11:46 AM, Atin Mukherjee 
wrote:

>
>
> On 06/21/2016 11:41 AM, Rajesh Joseph wrote:
> > What kind of locking issues you see? If you can provide some more
> > information I can be able to help you.
>
> That's related to stale lock issues on GlusterD which are there in 3.6.1
> since the fixes landed in the branch post 3.6.1. I have already provided
> the workaround/way to fix them [1]
>
> [1]
> http://www.gluster.org/pipermail/gluster-users/2016-June/thread.html#26995
>
> ~Atin
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



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

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[Rajesh Joseph]

On Mon, Jun 20, 2016 at 5:58 PM, B.K.Raghuram  wrote:

> Thanks Rajesh,
>
> I was looking at 3.6 only to check on some locking issues that we were
> seeing.
>

What kind of locking issues you see? If you can provide some more
information I can be able to help you.


> However, we would like to see this in master. Please feel free to suggest
> modifications/modify the code as you see fit.
>

Sure, I will review the code and let you know what needs to be changed.


> Are there plans of having a more general way of integrating other
> underlying snapshotting mechanisms such as btrfs/lxd as well?
>

We do have this in our backlog, but due to manpower and other priorities it
was never picked up. Hope this get sorted in the
coming future and also it would be great to get contributions from other
community members in this area.

Best Regards,
Rajesh


>
> On Mon, Jun 20, 2016 at 3:16 PM, Rajesh Joseph  wrote:
>
>>
>>
>> On Mon, Jun 20, 2016 at 12:33 PM, Kaushal M  wrote:
>>
>>> On Mon, Jun 20, 2016 at 11:38 AM, B.K.Raghuram  wrote:
>>> > We had hosted some changes to an old version of glusterfs (3.6.1) in
>>> order
>>> > to incorporate ZFS snapshot support for gluster snapshot commands.
>>> These
>>> > have been done quite a while back and were not forward ported to newer
>>> > versions of glusterfs. I have a couple of questions on this :
>>> >
>>> > 1. If one needs to incorporate these changes in their current or
>>> modified
>>> > form into the glusterfs master, what is the procedure to do so?
>>> >
>>> > 2. Since the above process may take longer to roll in, we would like
>>> to get
>>> > the changes into at least the latest version of the 3.6 branch. In
>>> order to
>>> > do this, I tried the following and needed some help :
>>> >
>>> > I tried to apply the two ZFS relates commits
>>> > (https://github.com/fractalio/glusterfs/commits/release-3.6) to the
>>> latest
>>> > gluster code in the  guster-3.6 branch. I hit  one merge conflict per
>>> > commit, both in xlators/mgmt/glusterd/src/glusterd-snapshot.c. The
>>> attached
>>> > glusterd-snapshot.c_1 is the file with the merge conflicts after
>>> applying
>>> > the first commit and  glusterd-snapshot.c_2 is the one applying the
>>> second
>>> > commit. In order to process, I removed the HEAD changes in each of the
>>> merge
>>> > conflicts and proceeded just to see if anything else breaks but it went
>>> > through. glusterd-snapshot.c_1_corrected and
>>> glusterd-snapshot.c_2_corrected
>>> > and the corresponding files after removing the merge conflicts.
>>> >
>>> > The question I had is, are the changes that I made to correct the merge
>>> > conflicts safe? If not, could someone provide some suggestions on how
>>> to
>>> > correct the two conflicts?
>>> >
>>> > The file cmd_log contains the history of commands that I went through
>>> in the
>>> > process..
>>> >
>>>
>>> Thanks for sharing this Ram!
>>>
>>> Rajesh is the right person to answer your questions. As a GlusterD
>>> maintainer, I'll go through this and see if I can answer as well.
>>>
>>>
>> Overall the merge resolution seems fine, except few mistakes. e.g. in
>> glusterd-snapshot.c_2 you missed
>> to add "(unmount == _gf_true)" in the while loop in function
>> "glusterd_do_lvm_snapshot_remove".
>>
>> In function "glusterd_lvm_snapshot_remove" wrong chunk of code added. The
>> "if" condition should break here
>> instead of continuing from here.
>>
>> Also I think it would be better to rebase the change against master
>> instead of 3.6.
>>
>> Apart from this I am yet to review the complete change. I have taken an
>> initial look and seems like
>> we do need some amount of cleanup to the code before it can be taken in.
>> I also need to see how well it will
>> work the existing framework. I will go through it and provide a detailed
>> comments later.
>>
>> Thanks & Regards,
>> Rajesh
>>
>>
>>
>>> > Thanks,
>>> > -Ram
>>> >
>>> > ___
>>> > Gluster-devel mailing list
>>> > Gluster-devel@gluster.org
>>> > http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

[B.K.Raghuram]

Thanks Rajesh,

I was looking at 3.6 only to check on some locking issues that we were
seeing. However, we would like to see this in master. Please feel free to
suggest modifications/modify the code as you see fit. Are there plans of
having a more general way of integrating other underlying snapshotting
mechanisms such as btrfs/lxd as well?

On Mon, Jun 20, 2016 at 3:16 PM, Rajesh Joseph  wrote:

>
>
> On Mon, Jun 20, 2016 at 12:33 PM, Kaushal M  wrote:
>
>> On Mon, Jun 20, 2016 at 11:38 AM, B.K.Raghuram  wrote:
>> > We had hosted some changes to an old version of glusterfs (3.6.1) in
>> order
>> > to incorporate ZFS snapshot support for gluster snapshot commands. These
>> > have been done quite a while back and were not forward ported to newer
>> > versions of glusterfs. I have a couple of questions on this :
>> >
>> > 1. If one needs to incorporate these changes in their current or
>> modified
>> > form into the glusterfs master, what is the procedure to do so?
>> >
>> > 2. Since the above process may take longer to roll in, we would like to
>> get
>> > the changes into at least the latest version of the 3.6 branch. In
>> order to
>> > do this, I tried the following and needed some help :
>> >
>> > I tried to apply the two ZFS relates commits
>> > (https://github.com/fractalio/glusterfs/commits/release-3.6) to the
>> latest
>> > gluster code in the  guster-3.6 branch. I hit  one merge conflict per
>> > commit, both in xlators/mgmt/glusterd/src/glusterd-snapshot.c. The
>> attached
>> > glusterd-snapshot.c_1 is the file with the merge conflicts after
>> applying
>> > the first commit and  glusterd-snapshot.c_2 is the one applying the
>> second
>> > commit. In order to process, I removed the HEAD changes in each of the
>> merge
>> > conflicts and proceeded just to see if anything else breaks but it went
>> > through. glusterd-snapshot.c_1_corrected and
>> glusterd-snapshot.c_2_corrected
>> > and the corresponding files after removing the merge conflicts.
>> >
>> > The question I had is, are the changes that I made to correct the merge
>> > conflicts safe? If not, could someone provide some suggestions on how to
>> > correct the two conflicts?
>> >
>> > The file cmd_log contains the history of commands that I went through
>> in the
>> > process..
>> >
>>
>> Thanks for sharing this Ram!
>>
>> Rajesh is the right person to answer your questions. As a GlusterD
>> maintainer, I'll go through this and see if I can answer as well.
>>
>>
> Overall the merge resolution seems fine, except few mistakes. e.g. in
> glusterd-snapshot.c_2 you missed
> to add "(unmount == _gf_true)" in the while loop in function
> "glusterd_do_lvm_snapshot_remove".
>
> In function "glusterd_lvm_snapshot_remove" wrong chunk of code added. The
> "if" condition should break here
> instead of continuing from here.
>
> Also I think it would be better to rebase the change against master
> instead of 3.6.
>
> Apart from this I am yet to review the complete change. I have taken an
> initial look and seems like
> we do need some amount of cleanup to the code before it can be taken in. I
> also need to see how well it will
> work the existing framework. I will go through it and provide a detailed
> comments later.
>
> Thanks & Regards,
> Rajesh
>
>
>
>> > Thanks,
>> > -Ram
>> >
>> > ___
>> > Gluster-devel mailing list
>> > Gluster-devel@gluster.org
>> > http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel