From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 23 Oct 2018 11:37:34 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] Re: [PATCH 0/5] Delete old WAL files if running out of disk space Message-ID: <20181023083734.pkgdqhvyp3bvepgh@esperanza> References: <20181016190522.GH5454@chai> <20181017082058.ebdyx3kwk42ln5tw@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181017082058.ebdyx3kwk42ln5tw@esperanza> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Wed, Oct 17, 2018 at 11:20:58AM +0300, Vladimir Davydov wrote: > Anyway, you seem to be unaware of the fact that one of fallocate use > cases is speeding writes by reducing the number of file size updates > (which require a write to the inode table). I wrote a simple test that > demonstrates that, see below. > > vlad@esperanza test$ gcc -O2 fallocate_test.c -o fallocate_test > vlad@esperanza test$ ./fallocate_test > Usage: ./fallocate_test > filename - test file > write_count - number of writes (append) > write_size - write(2) size > alloc_size - fallocate(2) size > returns time in seconds > vlad@esperanza test$ ./fallocate_test dummy 1000000 100 0 > 1.548161 > vlad@esperanza test$ ./fallocate_test dummy 1000000 100 0 > 1.505698 > vlad@esperanza test$ ./fallocate_test dummy 1000000 100 100000 > 1.195223 > vlad@esperanza test$ ./fallocate_test dummy 1000000 100 100000 > 1.137996 > > I have stock ext4 over hdd on my laptop, configured by Debian, no > tuning. The code is right below. That is for an append-only workload > similar to WAL fallocate yields ~25% gain. Alas, I was wrong. Even though the synthetic test shows a great improvement when fallocate() is used, there's practically no difference in case of nosqlbench. So the feature doesn't seem to be worthwhile. I guess I'll reimplement WAL auto-removal without fallocate().