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.
On 09/19/2016 07:52 PM, sri...@marirs.net.in wrote:
Do you have a bug id for this changes? Or may I raise a new one?
On Fri, Sep 16, 2016, at 11:37 AM, sri...@marirs.net.in
I'll send this patch to gluster master in a while.
On Wed, Sep 14, 2016, at 03:08 PM, Avra Sengupta wrote:
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
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.
P.S : Adding gluster-devel
On 09/13/2016 01:14 AM, sri...@marirs.net.in
You'd time to look into the below request?
On Thu, Sep 8, 2016, at 01:20 PM, sri...@marirs.net.in
Thank you. Please, let me know your feedback. It would be helpful
on continuing from then.
On Thu, Sep 8, 2016, at 01:18 PM, Avra Sengupta wrote:
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.
On 09/08/2016 01:09 PM, sri...@marirs.net.in
Sorry to bother. Could you have a look at the below request?
On Tue, Sep 6, 2016, at 11:27 AM, sri...@marirs.net.in
Sorry for the delayed mail, was on leave. Could you let me know
On Fri, Sep 2, 2016, at 10:08 AM, Rajesh Joseph wrote:
Sorry, I was on leave therefore could not reply.
Added Avra who is also working on the snapshot component for
Will take a look at your changes today.
Thanks & Regards,
On Thu, Sep 1, 2016 at 1:22 PM, <sri...@marirs.net.in
Could you've a look at the below request?
On Tue, Aug 30, 2016, at 01:03 PM, sri...@marirs.net.in
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
- Created a new folder for glusterd plugins and added
snapshot as a plugin. Like this,
+ __ snapshot/src
Moved LVM related snapshot implementation to
- 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
- Need to create glusterd_snapshot_ops structure which
would be used to register snapshot related API's with
- 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
On Fri, Jul 22, 2016, at 02:43 PM, Rajesh Joseph wrote:
On Thu, Jul 21, 2016 at 3:07 AM, Vijay Bellur
<vbel...@redhat.com <mailto:vbel...@redhat.com>> wrote:
On 07/19/2016 11:01 AM, Atin Mukherjee wrote:
On Tue, Jul 19, 2016 at 7:29 PM, Rajesh Joseph
On Tue, Jul 19, 2016 at 11:23 AM,
I'd thought about moving the zfs specific
inital go. Could you let me know if this works
or in sync with
what you'd thought about?
Sorry, I was not able to send much time on this.
I would prefer you
move the code to
How about having it under
in future if we have to write plugins for other
features they can be
It would be nicer to avoid "specific-stuff" or
similar from the naming. We can probably leave it at
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.
Gluster-devel mailing list
Gluster-devel mailing list
Gluster-devel mailing list