(Although I'm not sure how much performance benefits there are in practice in choosing DSYNC over SYNC.) 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. (st_size, as made by say ftruncate(2)), would require a metadata On the other hand, a change to the file size For example,Ĭhanges to st_atime or st_mtime (respectively, time of last accessĪnd time of last modification see stat(2)) do not require flushingīecause they are not necessary for a subsequent data read to be Subsequent data retrieval to be correctly handled. Metadata unless that metadata is needed in order to allow a Information associated with the file (see stat(2)).įdatasync() is similar to fsync(), but does not flush modified So that all changed information can be retrieved even after the Modified buffer cache pages for) the file referred to by the fileĭescriptor fd to the disk device (or other permanent storage device)
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:įsync() transfers ("flushes") all modified in-core data of (i.e.,
Here's an answer specific to the Linux file system.Īccording to the source for .UnixChannelFactory, those options map respectively to the O_SYNC and O_DSYNC options of open(), whose documentation says: 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. SYNC - Slowest, waits until both the file data and file meta are written out and give the thumbs up before returning.DSYNC - Slower, waits until file data is written and returns (let's file meta get saved later).(no option) - Fastest, potential for loss of file data and file meta from 1 or more pending writes that haven't been flushed yet.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. 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. I imagine it could get expensive to try and block the entire write operation until all that work is done.
Looking at modern filesystems using concepts like copy-on-write, shadow-copying, versioning, checksuming, etc.
As for the overhead, I think that is a giant "it depends on the filesystem". 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.
0 kommentar(er)
