StandardOpenOption.SYNC与StandardOpenOption.DSYNC

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.

Answer 2

Here's an answer specific to the Linux file system.

According to the source for sun.nio.fs.UnixChannelFactory , those options map respectively to the O_SYNC and O_DSYNC options of open() , whose documentation says:

• O_SYNC -- like write(2) followed by a call to fsync(2)
• O_DSYNC -- like write(2) followed a call to fdatasync(2)

The documentation for fdatasync(2) then makes it explicit that anything insubstantial to the retrieval of the file's data, such as last access time and last modification time aren't flushed by O_DSYNC , but anything that is, is:

fsync() transfers ("flushes") all modified in-core data of (ie, modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the system crashed or was rebooted. ... The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)).

fdatasync() is similar to fsync(), but does not flush modified metadata unless that metadata is needed in order to allow a subsequent data retrieval to be correctly handled. For example, changes to st_atime or st_mtime (respectively, time of last access and time of last modification; see stat(2)) do not require flushing because they are not necessary for a subsequent data read to be handled correctly. On the other hand, a change to the file size (st_size, as made by say ftruncate(2)), would require a metadata flush.

So an educated guess is, unless a program uses these not-important-for-data-attributes (and synchronization of their values are important) StandardOpenOption.DSYNC is acceptable. (Although I'm not sure how much performance benefits there are in practice in choosing DSYNC over SYNC .)

Looking through BasicFileAttributes , fields such as creationTime() , lastModifiedTime() , lastAccessTime() probably fall into this "not important for data access" category, while fields such as isDirectory() , isRegularFile() , is*() and size() probably won't, as I can't imagine data being accessible if they are wrong.