Description of problem: ======================== Disperse eager lock option currently has following issues: 1)the help is not sufficient 2) the disperse eager lock must be allowed to be enabled only on an ec volume and not on afr or distribute volume 3) once enabled,user must not be allowed to re-enabled . same with disable 4) the input allowed should be boolean and none other. allow on/off 1/0 true/false This case was executed while testing Bug 1320412 - disperse: Provide an option to enable/disable eager lock fix Version-Release number of selected component (if applicable): ======= 3.7.9-2 Steps to Reproduce: TC#7: CLI sanity of disperse eager lock 1.Create an EC volume 2.Now try to set the eager lock option by turning on disperse.eager-lock by using different inputs. Only booleans like 1 or 0 true or false and on/off must be allowed 3. try to enable the option on already enabled volume It must fail, saying it is already enabled 4. Try to disable on already disable volume It must fail, saying it is already disabled 5. check for the help the help must have sufficent data to be useful
Sunil, https://bugzilla.redhat.com/show_bug.cgi?id=1327171 bug has already been fixed and duplicate to this issue.
Fix is already part of 3.9 and 3.10 upstream release. ********************************** Option: cluster.eager-lock Default Value: on Description: Enable/Disable eager lock for replica volume. Lock phase of a transaction has two sub-phases. First is an attempt to acquire locks in parallel by broadcasting non-blocking lock requests. If lock acquisition fails on any server, then the held locks are unlocked and we revert to a blocking locks mode sequentially on one server after another. If this option is enabled the initial broadcasting lock request attempts to acquire a full lock on the entire file. If this fails, we revert back to the sequential "regional" blocking locks as before. In the case where such an "eager" lock is granted in the non-blocking phase, it gives rise to an opportunity for optimization. i.e, if the next write transaction on the same FD arrives before the unlock phase of the first transaction, it "takes over" the full file lock. Similarly if yet another data transaction arrives before the unlock phase of the "optimized" transaction, that in turn "takes over" the lock as well. The actual unlock now happens at the end of the last "optimized" transaction. Option: disperse.eager-lock Default Value: on Description: Enable/Disable eager lock for disperse volume. If a fop takes a lock and completes its operation, it waits for next 1 second before releasing the lock, to see if the lock can be reused for next fop from the same client. If ec finds any lock contention within 1 second it releases the lock immediately before time expires. This improves the performance of file operations.However, as it takes lock on first brick, for few operations like read, discovery of lock contention might take long time and can actually degrade the performance. If eager lock is disabled, lock will be released as soon as fop completes. **********************************
*** This bug has been marked as a duplicate of bug 1327171 ***