From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 17 Oct 2018 11:44:06 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] Re: [PATCH v2 09/11] vinyl: do not account zero dump bandwidth Message-ID: <20181017084406.jt3lmsiawfsvbjar@esperanza> References: <13fecfb17369a9d4819eb82115722c37245b2db0.1538155645.git.vdavydov.dev@gmail.com> <20181012132721.vbshvexo2igrhtur@esperanza> <20181016182518.GC5454@chai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181016182518.GC5454@chai> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Tue, Oct 16, 2018 at 09:25:18PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [18/10/12 21:23]: > > Turns out this isn't enough. We'd better not account too small dumps, > > because such dumps have too high overhead associated with file creation. > > Our tests create a lot of small dumps using box.snapshot(). Taking them > > into account may slow down the overall test execution time or even break > > some tests. Let's ignore all dumps of size less than 1 MB for bandwidth > > estimation. The new patch is below. > > Let's talk face to face, but this entire clutch seems to be > becoming too huge with this patch. What's wrong with it? If you create a 100 MB file then the time it takes to allocate an inode is negligible comparing to the write time. This is a typical use case. However, if you create a 1 KB file, then you'll spend much more time on inode bookkeeping than actually writing anything. This is unlikely in practice (who'd write such small files?), but this is done very often by our tests. This results in enabling throttling and slowing down test execution time.