From: "Konstantin Belyavskiy" <k.belyavskiy@tarantool.org> To: "Vladimir Davydov" <vdavydov.dev@gmail.com> Cc: georgy@tarantool.org, tarantool-patches@freelists.org Subject: Re[2]: [tarantool-patches] [PATCH v3] replication: force gc to clean xdir on ENOSPC err Date: Wed, 27 Jun 2018 19:11:55 +0300 [thread overview] Message-ID: <1530115915.875536818@f107.i.mail.ru> (raw) In-Reply-To: <20180618123523.tsxxaedwm5262qj3@esperanza> [-- Attachment #1.1: Type: text/plain, Size: 6882 bytes --] Please take a look at updated patch ticket: https://github.com/tarantool/tarantool/issues/3397 branch: https://github.com/tarantool/tarantool/tree/kbelyavs/gh-3397-force-del-logs-on-no-disk-space >Понедельник, 18 июня 2018, 15:35 +03:00 от Vladimir Davydov <vdavydov.dev@gmail.com>: > >On Sat, Jun 09, 2018 at 05:05:10PM +0300, Konstantin Belyavskiy wrote: >> Garbage collector do not delete xlog unless replica do not notify >> master with newer vclock. This can lead to running out of disk >> space error and this is not right behaviour since it will stop the >> master. > >AFAIU this is the second iteration of this patch. If so, you should >have appended the version number to the subject prefix (i.e. PATCH v2) >according to our guideline: > >https://tarantool.io/en/doc/1.9/dev_guide/developer_guidelines.html#how-to-submit-a-patch-for-review > >> >> List of changes: >> - Promoting error from wal_thread to tx via cpipe. >> - Introduce states for gc_consumers (OK and OFF). GC does not >> take into account consumers with state OFF. >> - Add an error injection and a test. > >The list of changes between different versions of the same patch should >go after the link to the branch and the ticket. For example see > >https://www.freelists.org/post/tarantool-patches/PATCH-v2-box-make-gc-info-public > >> >> Closes #3397 >> --- >> ticket: https://github.com/tarantool/tarantool/issues/3397 >> branch: https://github.com/tarantool/tarantool/tree/kbelyavs/gh-3397-force-del-logs-on-no-disk-space >> >> src/box/gc.c | 52 ++++++++++- >> src/box/gc.h | 13 +++ >> src/box/wal.cc | 56 +++++++++-- >> src/errinj.h | 1 + >> src/fio.c | 7 ++ >> test/box/errinj.result | 2 + >> test/replication/force_gc_on_err_nospace.result | 107 ++++++++++++++++++++++ >> test/replication/force_gc_on_err_nospace.test.lua | 38 ++++++++ >> 8 files changed, 265 insertions(+), 11 deletions(-) >> create mode 100644 test/replication/force_gc_on_err_nospace.result >> create mode 100644 test/replication/force_gc_on_err_nospace.test.lua >> >> diff --git a/src/box/gc.c b/src/box/gc.c >> index 12e68f3dc..efe033aaf 100644 >> --- a/src/box/gc.c >> +++ b/src/box/gc.c >> @@ -59,6 +59,8 @@ struct gc_consumer { >> gc_node_t node; >> /** Human-readable name. */ >> char *name; >> + /** Dead or alive. GC ignores dead consumers. */ >> + enum gc_consumer_state state; > >Keeping dead consumers around is pointless. A consumer must be removed >from the tree as soon as it is evicted. Fixed > >> +void >> +gc_xdir_clean_notify(bool force_clean) >> +{ >> + if (force_clean == gc.force_clean_flag) >> + return; // nothing to do >> + else if (force_clean) { // xdir clean required >> + gc.force_clean_flag = true; > >We don't use C++ style comments in the code. 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_alive(&gc.consumers); >> + if (leftmost == NULL) >> + return; // do nothing >> + int64_t signature = leftmost->signature; >> + while (true) { >> + leftmost->state = CONSUMER_OFF; >> + leftmost = gc_tree_first_alive(&gc.consumers); >> + if (leftmost == NULL || >> + leftmost->signature > signature) { >> + gc_run(); >> + return; > >A consumer may correspond to a backup procedure, in which case it must >not be evicted, even on ENOSPC. Fixed > > >> + } >> + } >> + } else >> + gc.force_clean_flag = false; >> +} > >> diff --git a/src/box/wal.cc b/src/box/wal.cc >> index 099c70caa..9dd8347d5 100644 >> --- a/src/box/wal.cc >> +++ b/src/box/wal.cc >> @@ -59,6 +62,11 @@ struct wal_thread { >> struct cord cord; >> /** A pipe from 'tx' thread to 'wal' */ >> struct cpipe wal_pipe; >> + /** >> + * Return pipe from 'wal' to tx'. This is a >> + * priority pipe and DOES NOT support yield. >> + */ >> + struct cpipe tx_prio_pipe; >> /** Return pipe from 'wal' to tx' */ >> struct cpipe tx_pipe; >> }; >> @@ -154,7 +166,7 @@ static void >> tx_schedule_commit(struct cmsg *msg); >> >> static struct cmsg_hop wal_request_route[] = { >> - {wal_write_to_disk, &wal_thread.tx_pipe}, >> + {wal_write_to_disk, &wal_thread.tx_prio_pipe}, > >AFAICS you rename wal_thread.tx_pipe to tx_prio_pipe and create a new >pipe called wal_thread.tx_pipe to be used for garbage collection, all in >one patch. This is very difficult to review. Provided you really need >it, renaming should be done in a separate patch with a good explanation >why you're doing what you're doing. Currently, I fail to see a reason. > >> +static void >> +gc_status_update(struct cmsg *msg) >> +{ >> + msg->route = NULL; >> + say_info("QQQ: gc_status_update"); > >What is this? Sorry, my fault (use to find in logs). > > >> + gc_xdir_clean_notify(static_cast<gc_msg*>(msg)->io_err); >> +} >> + >> static void >> wal_write_to_disk(struct cmsg *msg) >> { >> @@ -647,11 +667,29 @@ wal_write_to_disk(struct cmsg *msg) >> last_committed = stailq_last(&wal_msg->commit); >> >> done: >> + bool need_send = false; >> struct error *error = diag_last_error(diag_get()); >> if (error) { >> /* Until we can pass the error to tx, log it and clear. */ >> error_log(error); >> diag_clear(diag_get()); >> + if (errno == ENOSPC) { >> + err_nospace = true; >> + need_send = true; >> + } >> + } else if (err_nospace) { >> + /** Clear flag and send message to gc. */ >> + err_nospace = false; >> + need_send = true; >> + } >> + if (need_send) { > >This joggling with flags looks confusing. What are you trying to achieve >here? Avoid invoking garbage collector twice on ENOSPC error? At the >very least, this code should be accompanied by a comment. > >Also, AFAICS you fail a transaction that hit ENOSPC and triggered >garbage collection. I don't think it's good. I see two ways of >rectifying this: either retry WAL write after invoking garbage >collection or use fallocate to reserve some space beyond the end of >the file before writing to WAL. Fixed by comparing current timestamp with the previous one. > > >> + struct gc_msg msg; >> + static const struct cmsg_hop route[] = { >> + {gc_status_update, NULL} >> + }; >> + cmsg_init(&msg, route); >> + msg.io_err = err_nospace; >> + cpipe_push(&wal_thread.tx_pipe, &msg); >> } > >Pushing a message defined on stack to a pipe and not waiting for it to >be delivered doesn't look right. Fixed Best regards, Konstantin Belyavskiy k.belyavskiy@tarantool.org [-- Attachment #1.2: Type: text/html, Size: 9699 bytes --] [-- Attachment #2: 0000-cover-letter.patch --] [-- Type: application/x-patch, Size: 1479 bytes --] [-- Attachment #3: 0001-replication-rename-thread-from-tx-to-tx_prio.patch --] [-- Type: application/x-patch, Size: 4042 bytes --] [-- Attachment #4: 0002-replication-force-gc-to-clean-xdir-on-ENOSPC-err.patch --] [-- Type: application/x-patch, Size: 13071 bytes --]
next prev parent reply other threads:[~2018-06-27 16:11 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-06-09 14:05 [tarantool-patches] [PATCH] " Konstantin Belyavskiy 2018-06-18 12:35 ` Vladimir Davydov 2018-06-27 16:11 ` Konstantin Belyavskiy [this message] 2018-06-28 8:17 ` [tarantool-patches] [PATCH v3] " Vladimir Davydov 2018-06-28 12:53 ` [tarantool-patches] Re[2]: " Konstantin Osipov
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=1530115915.875536818@f107.i.mail.ru \ --to=k.belyavskiy@tarantool.org \ --cc=georgy@tarantool.org \ --cc=tarantool-patches@freelists.org \ --cc=vdavydov.dev@gmail.com \ --subject='Re: Re[2]: [tarantool-patches] [PATCH v3] 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