Re: [tarantool-patches] Re: [PATCH 0/5] Delete old WAL files if running out of disk space

[Vladimir Davydov <vdavydov.dev@gmail.com>]

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> <write_count> <write_size> <alloc_size>
> 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().