DB_TXN_WRITE_NOSYNC not keeping its contract?

Question

Dear forum,
I'm using bsddb (4.6 on Debian) in a program where it is rather critical that each write not take very much time. For that purpose, I'm specifying DB_TXN_WRITE_NOSYNC when creating a transaction, so as to avoid the time it takes to sync to disk physically (perfect durability is not my foremost concern anyway). In spite of that, however, bsddb still calls fdatasync on what I think is the log file when I commit the transaction (as seen using strace). Why might this be? Do I need to do something else in order to avoid that and, in that case, what does DB_TXN_WRITE_NOSYNC really mean? From reading the docs, it is described as precisely what I want: "Write, but do not synchronously flush, the log when this transaction commits."
Thank you for reading!

Answer 1

Alexander.Gorrod wrote:
It's also worth being aware that there are events other than transaction commit that can trigger a flush. For example a checkpoint operation causes a flush, as does switching to a new log file.Interestingly enough, there seems to be something to this. I just thought of the bright idea to attach gdb to the process and break on fdatasync, and it shows that the flushing actually does not happen when committing the transaction, but on a put operation itself. Here's what the traceback looks like:
#0 __fdatasync (fd=12) at ../sysdeps/unix/sysv/linux/fdatasync.c:56
#1 0xb7ee3090 in __os_fsync (env=0x84d3a58, fhp=0x84d3180) at ../dist/../os/os_fsync.c:92
#2 0xb7ecde25 in __log_flush_int (dblp=0x84e4cf0, lsnp=0xbfffe604, release=1) at ../dist/../log/log_put.c:1036
#3 0xb7ece17d in __log_flush (env=0x84d3a58, lsn=0xbfffe604) at ../dist/../log/log_put.c:863
#4 0xb7ed1ac0 in __memp_pgwrite (env=<value optimized out>, dbmfp=<value optimized out>, hp=0xb4c1a718, bhp=0xb4c2b084) at ../dist/../mp/mp_bh.c:328
#5 0xb7ed1dfd in __memp_bhwrite (dbmp=0x84d3078, hp=0xb4c1a718, mfp=0xb4c1ac74, bhp=0xb4c2b084, open_extents=0) at ../dist/../mp/mp_bh.c:168
#6 0xb7ed0b85 in __memp_alloc (dbmp=0x84d3078, infop=0x84d31e0, mfp=0xb4c1ac74, len=16436, offsetp=0x0, retp=0xbfffe840) at ../dist/../mp/mp_alloc.c:423
#7 0xb7ed337e in __memp_fget (dbmfp=0x84e5538, pgnoaddr=0x84e5844, ip=0x0, txn=0x84d3988, flags=<value optimized out>, addrp=0x84e5838) at ../dist/../mp/mp_fget.c:615
#8 0xb7e100e4 in __ham_get_cpage (dbc=0x84e56e8, mode=DB_LOCK_WRITE) at ../dist/../hash/hash_page.c:2433
#9 0xb7e0223b in __ham_lookup (dbc=0x84e56e8, key=<value optimized out>, sought=56, mode=DB_LOCK_WRITE, pgnop=0xbfffea98) at ../dist/../hash/hash.c:1803
#10 0xb7e025e3 in __hamc_put (dbc=0x84e56e8, key=0xbfffee94, data=0xbfffee78, flags=<value optimized out>, pgnop=0xbfffea98) at ../dist/../hash/hash.c:1056
#11 0xb7e823be in __dbc_iput (dbc=0xc, key=0xbfffee94, data=0xbfffee78, flags=14) at ../dist/../db/db_cam.c:2103
#12 0xb7e8482d in __dbc_put (dbc=0x84e56e8, key=0xbfffee94, data=0xbfffee78, flags=14) at ../dist/../db/db_cam.c:2016
#13 0xb7e759d2 in __db_put (dbp=0x84e5170, ip=0x0, txn=0x84d3988, key=0xbfffee94, data=0xbfffee78, flags=139348856) at ../dist/../db/db_am.c:477
#14 0xb7e8cd6b in __db_put_pp (dbp=0x84e5170, txn=0x84d3988, key=0xbfffee94, data=0xbfffee78, flags=<value optimized out>) at ../dist/../db/db_iface.c:1579
#15 0x08059ce3 in idmapdbput (db=0x821b990, key=5443030432385861072, buf=0x82686cc) at utils.c:485
idmapdbput is my own function which calls DB->put, and 12 is the FD on which the logfile is opened. I just did add the DB_TXN_WRITE_NOSYNC flag to the DB_ENV itself, by the way.
Is it supposed to be that way? Is there any way I can avoid it?