[Bugs] [Bug 1318068] features.barrier is not set to "disable" after barrier timeout expires
bugzilla at redhat.com
bugzilla at redhat.com
Wed Mar 16 04:26:05 UTC 2016
https://bugzilla.redhat.com/show_bug.cgi?id=1318068
Atin Mukherjee <amukherj at redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(amukherj at redhat.c |
|om) |
|needinfo?(jack.wong at laserfi |
|che.com) |
--- Comment #3 from Atin Mukherjee <amukherj at redhat.com> ---
(In reply to SATHEESARAN from comment #1)
> I think the barrier option is turned off internally when barrier-timeout is
> met, but not reflected anywhere else.
>
> If you take a brick statedump ( by using gluster volume statedump <volname>
> all ), you can see that barrier is turned off after barrier-timeout seconds
> # gluster volume statedump <vol> all
> # grep barrier.enabled
> /var/run/gluster/<brickpath>.<brick-pid>.dump.<timestamp>
>
> Since the state of barrier is not restored in volume options, volume get is
> also returning the old value which is 'enable', but its actually disabled
>
> Atin, do you think the state of barrier should be dynamically obtained from
> 'gluster volume get' ?
That could be better but it involves lot of work. In volume get work flow by
default we pick up the value from volume's dictionary, if its not there then we
load the xlator dynamically and fetch it from there. In this case we'd have to
handle this in a special way otherwise. My take is since barrier as a feature
is been used internally by snapshot I think we can still live up with it.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
More information about the Bugs
mailing list