fdatasync not working as expected on fscq? about fscq HOT 4 CLOSED

This is within the FSCQ fdatasync specification as described in the OSDI 2018 paper. There are (at least) two trees in the tree sequence: one where the file exists and has length 0, and one where the 4000 bytes have been written. The fdatasync ensures that if the system crashes to the second tree, the data will match buf rather than be zeroes (of course in this situation those are the same since buf is all zeros). However, without an fsync the system simply crashes to the old tree.

This doesn't match one reading of the fdatasync(2) man page in Linux (which says metadata is flushed if "needed in order to allow a subsequent data retrieval to be correctly handled" - you could interpret "correctly handled" as meaning all previously written data to the file should be readable), but that isn't the specification FSCQ formalizes.

from fscq.

Thank you @tchajed for the quick answer. A follow-up question: since killall -9 fscq crashes to the old tree, how to make the system crash to the second tree? Or this is not possible?

from fscq.

You'll need an fsync call (for example, use fsync instead of fdatasync to both sync the direct writes to that file and flush the log).

from fscq.

Closing. This isn't a bug in FSCQ, just a difference between our specification and what other filesystems do.

from fscq.