Tarantool development patches archive
 help / color / mirror / Atom feed
From: "Konstantin Belyavskiy" <k.belyavskiy@tarantool.org>
To: tarantool-patches@freelists.org
Subject: [tarantool-patches] Re: [tarantool-patches] Re: [PATCH v3 2/2] replication: force gc to clean xdir on ENOSPC err
Date: Fri, 29 Jun 2018 00:55:42 +0300	[thread overview]
Message-ID: <1530222942.499248560@f344.i.mail.ru> (raw)
In-Reply-To: <20180628152530.GA6042@chai>

[-- Attachment #1: Type: text/plain, Size: 3593 bytes --]


Thank you for the review.

>Четверг, 28 июня 2018, 18:25 +03:00 от Konstantin Osipov <kostja@tarantool.org>:
>
>* Konstantin Belyavskiy < k.belyavskiy@tarantool.org > [18/06/28 18:13]:
>> 
>> +void
>> +gc_xdir_clean_notify()
>> +{
>> +	/*
>> +	 * Compare the current time with the time of the last run.
>> +	 * This is needed in case of multiple failures to prevent
>> +	 * from deleting all replicas.
>> +	 */
>> +	static int prev_time = 0;
>> +	int cur_time = time(NULL);
>> +	if (cur_time - prev_time < 1)
>
>Please use fiber time. 
Fixed.
>
>
>> +	/**
>> +	 * Mark consumer with least recent vclock as "dead" and
>> +	 * invoke garbage collection. If nothing to delete find
>> +	 * next alive consumer etc. Originally created for
>> +	 * cases with running out of disk space because of
>> +	 * disconnected replica.
>> +	 */
>> +	struct gc_consumer *leftmost =
>> +	    gc_tree_first(&gc.consumers);
>> +	/*
>> +	 * Exit if no consumers left or if this consumer is
>> +	 * not associated with replica (backup for example).
>> +	 */
>
>You should delete the consumer *only* if it's going to help with
>garbage. Running out of space should not lead to deletion of all
>replicas as consumers if they are not lagging behind. 
Here I delete only the consumer with the least recent vclock
(or consumers if they share the same value) since gc_tree use
vclock signature for comparison (see gc_consumer_cmp).
>
>> +	if (leftmost == NULL || leftmost->replica == NULL)
>> +		return;
>> +	int64_t signature = leftmost->signature;
>> +	while (true) {
>> +		gc_consumer_unregister(leftmost);
>> +		leftmost = gc_tree_first(&gc.consumers);
>> +		if (leftmost == NULL || leftmost->replica == NULL ||
>> +		    leftmost->signature > signature) {
>> +			gc_run();
>> +			return;
>> +		}
>> +	}
>> +}
>> +
>
><cut>
>
>>  const char *wal_mode_STRS[] = { "none", "write", "fsync", NULL };
>> @@ -64,6 +65,8 @@ struct wal_thread {
>>  	 * priority pipe and DOES NOT support yield.
>>  	 */
>>  	struct cpipe tx_prio_pipe;
>> +	/** Return pipe from 'wal' to tx' */
>> +	struct cpipe tx_pipe;
>
>Why do you need a new pipe? 
Since operations with file (like deleting of old xlogs) requires yield and
tx_prio does not support it.
'tx' is a fiber pool, but 'tx_prio' is an endpoint and supports only callbacks
without 'yield'.
>
>> 
>> +static void
>> +gc_status_update(struct cmsg *msg)
>> +{
>> +	gc_xdir_clean_notify();
>> +	delete(msg);
>
>delete()?! 
Sorry, my fault.
>
>
>>  {
>> @@ -655,6 +665,15 @@ done:
>>  		/* Until we can pass the error to tx, log it and clear. */
>>  		error_log(error);
>>  		diag_clear(diag_get());
>> +		if (errno == ENOSPC) {
>> +			struct cmsg *msg =
>> +			    (struct cmsg*)calloc(1, sizeof(struct cmsg));
>
>Please check calloc() return value and do nothing 
>in case it's NULL. 
Done.
>
>> +			static const struct cmsg_hop route[] = {
>> +				{gc_status_update, NULL}
>> +			};
>> +			cmsg_init(msg, route);
>> +			cpipe_push(&wal_thread.tx_pipe, msg);
>> +		}
>> 
>> index 895d938d5..11f1b7fdc 100644
>> +...
>> +-- add a little timeout so gc could finish job
>> +require('fiber').sleep(0.01)
>
>Please never sleep in a test case unconditionally. It doesn't work
>reliably, especially in parallel runs.
>
>The test case should test that replicas which are severely behind 
>are abandoned, and replicas which are running well are not. 
Ok, will replace it with new test case.
>
>
>-- 
>Konstantin Osipov, Moscow, Russia,  +7 903 626 22 32
>http://tarantool.io -  www.twitter.com/kostja_osipov
>


Best regards,
Konstantin Belyavskiy
k.belyavskiy@tarantool.org

[-- Attachment #2: Type: text/html, Size: 5959 bytes --]

  reply	other threads:[~2018-06-28 21:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-28 15:07 [tarantool-patches] [PATCH v3 0/2] " Konstantin Belyavskiy
2018-06-28 15:07 ` [tarantool-patches] [PATCH v3 1/2] replication: rename thread from tx to tx_prio Konstantin Belyavskiy
2018-06-28 15:07 ` [tarantool-patches] [PATCH v3 2/2] replication: force gc to clean xdir on ENOSPC err Konstantin Belyavskiy
2018-06-28 15:25   ` [tarantool-patches] " Konstantin Osipov
2018-06-28 21:55     ` Konstantin Belyavskiy [this message]
2018-07-03  8:56       ` Kirill Yukhin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1530222942.499248560@f344.i.mail.ru \
    --to=k.belyavskiy@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='[tarantool-patches] Re: [tarantool-patches] Re: [PATCH v3 2/2] replication: force gc to clean xdir on ENOSPC err' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox