From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp41.i.mail.ru (smtp41.i.mail.ru [94.100.177.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id E06B2469719 for ; Sat, 15 Feb 2020 01:48:29 +0300 (MSK) References: From: Vladislav Shpilevoy Message-ID: <701f259d-b9fd-c688-9602-7281e0dc2f0d@tarantool.org> Date: Fri, 14 Feb 2020 23:48:28 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH 0/4] Safe truncation and deletion List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ilya Kosarev , tarantool-patches@dev.tarantool.org Thanks for the patchset! On 14/02/2020 20:40, Ilya Kosarev wrote: > This patchset is an experiment on reserve tech used for safe truncation > and the demonstration of the possible space:delete() fail on reserve. > The idea of the 3rd patch (memtx: use reserved slab for truncation) was > to prealloc a slab on arena to be used only for truncation tuples. > This approach didn't really solve the problem. After we are getting the > reserved slab with slab_map, we have a choice to put or not to put it > on slab lists. In case we do put it, the problem is that any next > operation, using mempool_alloc, will be able to use our slab, not only > truncation. This will lead to it's fast exhaustion. On the other hand, > if we skip all this lists (as it is done), we will fail at the garbage > collection when trying to free those tuples, as far as their slab won't > be found. See backtrace at > https://gitlab.com/tarantool/tarantool/-/jobs/438082894. It doesn't > look like there is any acceptable way to tune garbage collector > behavior. > In the 4th patch the stress_delete test with errinj is introduced to > show how it may fail on reserve. It uses errinj to simulate the case > where the num of reserved extents for memtx_index_extent_reserve won't > be enough, setting target amount as current amount + 1. > > Not aimed to be pushed to master! > > Branch: https://github.com/tarantool/tarantool/tree/i.kosarev/gh-3807-safe-alloc-on-truncation > Issue: https://github.com/tarantool/tarantool/issues/3807 This is not a correct link. You pushed this patchset into https://github.com/tarantool/tarantool/tree/i.kosarev/gh-3807-reserve-on-truncation Overall the patchset looks ... ghm, I would say not really good. It consists of crutches more than completely. I don't think that approach works, if this is what Kostja proposed.