6

I am looking to force synchronisation to disk after files are written at certain points in my application. Since it runs on Linux, I could get away with just running

Runtime.getRuntime().exec("sync");

However, I would rather not introduce Linux specific system calls and would rather use

java.io.FileDescriptor#sync();

However, I use Apache VFS to perform operations on the local file system and to my knowledge it does not provide access to the underlying file descriptor. But do I need access to the actual file descriptor that was just written to to force synchronization? Could I not just use any FileDescriptor to call sync for the same effect, for example

FileDescriptor.in.sync();

Would that be a valid approach, and would the results match that of calling sync in Linux?

Just in case anyone knows if / how it is possible to get access to the underlying FileDescriptor in VFS, it would be useful to know as well.

Edit: it appears that

FileDescriptor.in.sync();

does not want to work on Linux (although it works on my Windows machine when run from Eclipse), but

new FileOutputStream(new File("anyfile")).getFD().sync();

definitely works and the results of calling this match the results of calling the Linux sync command directly. However, it involves opening and closing a redundant file output stream, so it's not exactly ideal. Any other reason this might be a bad idea, as it does seem to work? Is there some other way to get a FileDescriptor that can be used to sync?

Sevas
  • 4,215
  • 3
  • 27
  • 26
  • In my experience on Android calling sync on new FileDescriptor will NOT cause the kernel to sync other FileDescriptor's that were opened on the same path. – Ryan Williams Jul 20 '17 at 00:25

1 Answers1

5

I investigates such issues some time ago: Question 1, Question 2.

In Linux, a java.io.FileDescriptor#sync call ensures that the modified data of the file associated with the descriptor is sent to the disk. (That cheap disk tend to skip the write and only place the data in an unreliable (aka no NVRAM) write cache is a different/additional problem.) It does not guarantee that also modified data of other files is written back. This is just not in the contract of sync or of the underlying fsync POSIX function.

However, in certain circumstances (e.g. ext3 in data=ordered mode), an fsync on a file writes back up modified data of the file system. This is really fun because this may create significant latencies just because some other application has created a ton of dirty blocks.

Community
  • 1
  • 1
dmeister
  • 34,704
  • 19
  • 73
  • 95