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

Tue Jul 19 05:53:43 UTC 2016

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, sriram at 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, <sriram at marirs.net.in> 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, <sriram at marirs.net.in> 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
>>>>>> <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
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Pranith
>>>
>
> _________________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160719/90629f59/attachment-0001.html>