Question

1. What is the difference between StandardOpenOption.SYNC and StandardOpenOption.DSYNC?
2. What kind of data loss can occur with DSYNC?
3. What use-cases is DSYNC suited for? If you already decided to sync the file contents, why would you want to forgo syncing of the file metadata? Wouldn’t the relative difference in overhead be negligible?

Answer 1

Gili,

DSYNC is a subset of SYNC.

SYNC requires that all data (file data and file metadata managed by the filesystem) get written out synchronously while DSYNC requires that only the file data get written out synchronously. As for the overhead, I think that is a giant “it depends on the filesystem”. Looking at modern filesystems using concepts like copy-on-write, shadow-copying, versioning, checksuming, etc… I imagine it could get expensive to try and block the entire write operation until all that work is done.

Potential for data loss is a more confusing answer to provide; the advantages of asynchronous file I/O is that the underlying filesystem or disk can actually batch or order writes to avoid random I/O and structure the writes in a more sequential manner.

That is great, but to answer your question of data loss, it would be any pending writes that are sitting in the cache before a flush that could be potentially lost. In short, it is hard to say.

In short, the ordering looks like:

1. (no option) – Fastest, potential for loss of file data and file meta from 1 or more pending writes that haven’t been flushed yet.
2. DSYNC – Slower, waits until file data is written and returns (let’s file meta get saved later)
3. SYNC – Slowest, waits until both the file data and file meta are written out and give the thumbs up before returning.

I should say I am assuming all these questions pertain to the new AsynchronousFileChannel in Java 7; my apologies if that isn’t the case.