[Gluster-devel] regarding afr changelog options

Vijay Bellur vbellur at redhat.com
Mon Jan 13 09:21:51 UTC 2014


On 01/13/2014 02:28 PM, Pranith Kumar Karampuri wrote:
>
>
> ----- Original Message -----
>> From: "Vijay Bellur" <vbellur at redhat.com>
>> To: "Pranith Kumar Karampuri" <pkarampu at redhat.com>, "Anand Avati" <aavati at redhat.com>
>> Cc: gluster-devel at nongnu.org, "Ravishankar Narayanankutty" <ranaraya at redhat.com>
>> Sent: Monday, January 13, 2014 2:23:37 PM
>> Subject: Re: regarding afr changelog options
>>
>> On 01/13/2014 12:25 PM, Pranith Kumar Karampuri wrote:
>>> Afr depends on the following options to be enabled to work correctly. I am
>>> not sure why they are exposed as user configurable options.
>>> I am thinking of dis-allowing these options from being modified. Please let
>>> us know your views.
>>>
>>> Option: cluster.entry-change-log
>>> Description: Entry fops like create/unlink will not perform pre/post fop
>>> changelog operations in afr transaction if this option is disabled
>>> Option: cluster.data-change-log
>>> Description: Data fops like write/truncate will not perform pre/post fop
>>> changelog operations in afr transaction if this option is disabled
>>> Option: cluster.metadata-change-log
>>> Description: Metadata fops like setattr/setxattr will not perform pre/post
>>> fop changelog operations in afr transaction if this option is disabled
>>>
>>
>> Some of these options are useful in testing and troubleshooting. It is
>> probably better to mark the type for these options as NO_DOC so that it
>> doesn't surface in volume set help.
>
> But that is the problem, if they are disabled, afr functionality does not work as expected. In the last 2 years on afr I never had to disable these for testing anything. I am curious to know what it is useful for. If there is value in use-cases with them disabled, I should probably start testing for these as well in my testing or automate some use-cases.
>

Useful in determining performance overhead of changelogs etc. Yes, it 
would be good to have some unit testing coverage for these.

-Vijay





More information about the Gluster-devel mailing list