On Mon, Jun 20, 2016 at 5:58 PM, B.K.Raghuram <bkrram@xxxxxxxxx> 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 <rjoseph@xxxxxxxxxx> wrote:On Mon, Jun 20, 2016 at 12:33 PM, Kaushal M <kshlmster@xxxxxxxxx> wrote:Thanks for sharing this Ram!On Mon, Jun 20, 2016 at 11:38 AM, B.K.Raghuram <bkrram@xxxxxxxxx> 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..
>
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 missedto 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 hereinstead 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 likewe do need some amount of cleanup to the code before it can be taken in. I also need to see how well it willwork 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@xxxxxxxxxxx
> http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
