Re: Question on merging zfs snapshot support into the mainline glusterfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> wrote:


On Tue, Jun 21, 2016 at 4:24 PM, Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel



--
Pranith


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

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux