Hmmm... if we modify GF_OPTION_RECONF in such a way that as soon as
something succeeds we update the dictionary, then that may work. Not sure
if it is clean though. But it is not as bad as allocation/free in all
xlators.
On Thu, Jul 14, 2016 at 7:25 PM, Pranith Kumar Karampuri <
pkara...@redhat.co
The problem with approach is if partial reconfigure succeeds/fails we don't
know which keys to update and which ones to not update.
On Thu, Jul 14, 2016 at 5:42 PM, Mohammed Rafi K C
wrote:
> How about storing the same data variable(from new_xl options dict) with a
> ref in the options dictiona
How about storing the same data variable(from new_xl options dict) with
a ref in the options dictionary of old xlator.
Regards
Rafi KC
On 07/14/2016 08:28 AM, Pranith Kumar Karampuri wrote:
> hi,
> I wanted to remove 'get_new_dict()', 'dict_destroy()' usage
> through out the code base to
hi,
I wanted to remove 'get_new_dict()', 'dict_destroy()' usage through
out the code base to prevent people from using it wrong. Regression for
that patch http://review.gluster.org/13183 kept failing and I found that
the 'xl->options' dictionary is created using get_new_dict() i.e. it
doesn