0

I'm currently facing some strange problem on my distributed application. This application generally do the following things:

  • Read and Write Data from an NFSv3 Filesystem
  • Read and Write Data from a tmpfs Filesystem
  • One process generate files on tmpfs and access to them with another process (or another java thread which in the end is a pthread)
  • One process generate files on NFSv3 and access to them with another process (or another java thread which in the end is a pthread)
  • Write data to NFSv3 and read the same data from another machine

We discovered many latency problems with NFSv3 but those problems are known: If you write a file on NFS and than try to read from another machine it can take up to 90 seconds to be available when the stat syscall is executed on the other machine.

So we implemented some retry code to address this issue.

Recently we spotted a similar behaviour also on tmpfs but since it's in ram I thought that at the end of a write the same machine with another thread executed at the end of the write should see the file but we got an error about it.

So we decided to implement again another retry block

The question is: is the tmpfs transactional when the code stop to write on the file ?

And more in general how on the different filesystem this concept is applied ?

Thanks Marco

marcobazzani
  • 373
  • 4
  • 16
  • does the writing side on tmpfs flush its outputstreams before the reading side tries to access the file? – guido Sep 16 '15 at 12:14
  • there is a IOUtils.closeQuitely(file) I dunno if flush is wrapped by that function – marcobazzani Sep 16 '15 at 12:34
  • does the reading side try to open the file after the closeQuitely or before that? most IOUtils write calls will not flush, or at least that's what they state in their documentation – guido Sep 16 '15 at 12:57
  • to be more precise after the closeQuitely another Linux process is executed and that linux process spawn another thread that read that file with another – marcobazzani Sep 16 '15 at 13:21

0 Answers0