4

I'm using RocksDB via the C API.

I have a test program that opens a database, does 1,000 writes (gathering timing data between initiation of write and callback), does 1,000 reads, and shuts down.

This works. Average time to do a write is about 1ms.

I modified the test program to turn on write syncing via this

rocksdb_writeoptions_set_sync(wri_u, 1);

and ran it again. Average time to do a write is about 8ms.

So far, so good.

HOWEVER, I then ran strace on both versions of the program to verify that fsync() or fdatasync() or msync() is getting called.

The no-sync program shows 4 invocations of fsync(), 2 of fdatasync() and 0 of msync(). Reasonable.

...but the sync version of the program shows the same 4, 2, and 0. Odd! Surprising! Worrying!

The sync version DOES show 2 interesting deltas from the no-sync version: (i) 2 calls to nanosleep() per write, (ii) an 80% increase in the time spent in mmap().

One out-of-my-butt theory is that perhaps msync() [ or a stand-in for it ] is actually implemented in terms of nanosleep() ?

This is on a desktop Linux 16.04 

uname -a

Linux mithril 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Anyway, my question is, as per the subject line:

Am I properly forcing RocksDB to use fsync? ... because neither fsync() nor msync() shows in strace

Thanks.

TJIC
  • 190
  • 5

1 Answers1

2

Yes, this is the correct way to turn fsync() on.

The issue is that strace must be used with the -f flag to trace system calls in new threads ... and RocksDB was doing all syncs in other threads.

TJIC
  • 190
  • 5