[Bugs] [Bug 1170075] [RFE] : BitRot detection in glusterfs

bugzilla at redhat.com bugzilla at redhat.com
Thu Mar 19 01:22:40 UTC 2015


--- Comment #21 from Anand Avati <aavati at redhat.com> ---
COMMIT: http://review.gluster.org/9708 committed in master by Vijay Bellur
(vbellur at redhat.com) 
commit 4737584fffcd25dbe35d17b076c95bf90a422cf2
Author: Venky Shankar <vshankar at redhat.com>
Date:   Tue Feb 3 19:22:16 2015 +0530

    features/changelog: RPC'fy {libgf}changelog

    This patch introduces RPC based communication between the changelog
    translator and libgfchangelog. It replaces the old pathetic stream
    based interaction that existed earlier (due to time constraints :-/).

    Changelog, upon initialization starts a RPC server (rpcsvc) allowing
    clients to invoke a probe API as a bootup mechanism to request for
    event notifications. During probe, clients can choose an event
    filter specifying the type(s) of events they are interested in. As
    of now there is no way to change the event notification set once
    the probe RPC call is made, but that is easier to implement.

    The actual event notifications is done on a separate RPC session.
    The client (libgfchangelog) itself starts and RPC server which the
    changelog translator "connects back" during probe. Notifications
    are dispatched by a bunch of threads from the server (translator)
    and the client optionally orders them if ordered notifications
    are requried. FOPs fill in their respective event details in a
    buffer (rot-buffs to be particular) and a bunch of threads
    (consumers) swap the buffers out of roatation and dispatch them
    via RPC. To avoid writer starvation, then number of dispatcher
    threads is one less than the number of buffer list in rot-buffs.x

    libgfchangelog becomes purely callback based -- upon event
    notification from the server (and re-ordering them if required)
    invoke a callback routine specified by consumer(s).

    A major part of the patch is also aimed at providing backward
    compatibility for geo-replication, which was one of the main
    consumer of the stream based API. Also, this patch does not\
    "turn on" event notifications for all fops, just a bunch which
    is currently in requirement. Another pain point is that the
    server does not filter events before dispatching it to the
    clients. That load is taken up by the client itself (although
    it's done at the library layer rather than making it hard on
    the callback implementor). This needs improvement and care
    needs to be taken to not load the server up with expensive
    filtering mechanisms.

    Change-Id: Ibf60a432b68f2dfa60c6f9add2bcfd37a9c41395
    BUG: 1170075
    Signed-off-by: Venky Shankar <vshankar at redhat.com>
    Reviewed-on: http://review.gluster.org/9708
    Reviewed-by: Jeff Darcy <jdarcy at redhat.com>
    Tested-by: Gluster Build System <jenkins at build.gluster.com>
    Reviewed-by: Vijay Bellur <vbellur at redhat.com>

You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=EQDPiNGNcI&a=cc_unsubscribe

More information about the Bugs mailing list