[Bugs] [Bug 1224650] SIGNING FAILURE Error messages are poping up in the bitd log

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1224650



--- Comment #3 from Anand Avati <aavati at redhat.com> ---
COMMIT: http://review.gluster.org/10900 committed in release-3.7 by Venky
Shankar (vshankar at redhat.com) 
------
commit 06710aa1085a7c5f3259af6b63d23ac5f51bef18
Author: Venky Shankar <vshankar at redhat.com>
Date:   Fri May 29 10:00:13 2015 +0530

    features/bitrot: serialize versioning

        Backport of http://review.gluster.org/10832

    Current signing interface (fsetxattr()) had couple of issues:

    One, a signing request (by bitrot daemon) is denied if the version
    against which an object is to be signed is unequal to the current
    version of the object (cases where another subsequent modification
    increments the version). Such request(s) are rejected with EINVAL
    sent back to the signer resulting in a bunch of errors (in logs)
    reported by bitrot daemon. Although, the object would be eventaully
    signed with the version matching the current version, the "lagging"
    request should be correctly handled.

    Two, more than one signing request could race against each other
    with the object getting signed with a version depending on which
    request ended up last in the race. Although harmless to some extent,
    such a case could end up marking the object's signature as stale
    for infinity (if the object is *never* touched) thereby resulting
    in scrubber skipping the object during verification.

    This patch fixes these issues by ordering signing request(s) and
    fixing version comparison checks at the time of signing.

    Change-Id: I9fa83dfa3be664ba4db61d7f2edc408f4bde77dd
    BUG: 1224650
    Signed-off-by: Venky Shankar <vshankar at redhat.com>
    Tested-by: Gluster Build System <jenkins at build.gluster.com>
    Reviewed-on: http://review.gluster.org/10900
    Tested-by: NetBSD Build System <jenkins at build.gluster.org>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the Docs Contact for the bug.