[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 <rjoseph at redhat.com> wrote:

>
>
> On Tue, Jun 21, 2016 at 4:24 PM, Pranith Kumar Karampuri <
> pkarampu at 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 <amukherj at redhat.com>
>> 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 at gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
>> --
>> Pranith
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160704/e279039c/attachment-0001.html>