[PATCH] CTDB changes
amitay at gmail.com
Thu Sep 4 22:46:30 MDT 2014
On Fri, Aug 22, 2014 at 1:36 PM, Amitay Isaacs <amitay at gmail.com> wrote:
> On Wed, Aug 20, 2014 at 1:55 PM, Amitay Isaacs <amitay at gmail.com> wrote:
>> Hi All,
>> Here are some more CTDB locking changes. These changes add a TALLOC_CTX
>> to all the locking calls. So the requests are correctly created using the
>> specified TALLOC_CTX and freeing the context will automatically clean up
>> lock context associated with it.
>> This patch series also includes a patch to fix one of the long standing
>> issues of high hopcounts. In some case, a lock request will keep bouncing
>> back and forth between two nodes very quickly. This occurs during a small
>> window when a record is migrated from one node to other node and the
>> migrated record has not yet been written to the database. During this time
>> the dmaster information on both the nodes is inconsistent and each node
>> points to the other node as dmaster. This issue was further complicated by
>> ctdb lock wait processes getting starved when waiting for robust mutex lock
>> for the migrated record. We need to ensure that ctdb lock wait processes
>> run with higher priority than smbd, so ctdb can finish migration of records
>> quickly. Also, hold off all the record requests if there is record
>> migration in progress. This will avoid record requests bouncing between
>> the nodes like crazy.
>> The patches are in my ctdb-wip branch and are also attached.
>> Please review and push if ok.
> Found a memory leak in the deferral code.
> diff --git a/ctdb/server/ctdb_call.c b/ctdb/server/ctdb_call.c
> index 7a8b508..956b3e8 100644
> --- a/ctdb/server/ctdb_call.c
> +++ b/ctdb/server/ctdb_call.c
> @@ -428,6 +428,7 @@ static void dmaster_defer_reprocess(struct
> tevent_context *ev,
> private_data, struct dmaster_defer_call);
> ctdb_input_pkt(call->ctdb, call->hdr);
> + talloc_free(call);
> static int dmaster_defer_queue_destructor(struct dmaster_defer_queue *ddq)
> Updated patches attached. Please review.
Here's the updated patchset with an additional patch. Deferring dmaster
request/reply packets has a nasty interaction with database recovery. If
there are any deferred requests when recovery happens, we have to drop all
the deferred requests. Those requests are tracked as pending requests on
each node and will be re-sent with correct generation anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 25640 bytes
Desc: not available
More information about the samba-technical