1

I have a diskless host 'A', that has a directory NFS mounted on server 'B'. A process on A writes to two files F1 and F2 in that directory, and a process on B monitors these files for changes. Assume that B polls for changes faster than A is expected to make them. Process A seeks the head of the files, writes data, and flushes. Process B seeks the head of the files and does reads.

Are there any guarantees about how the order of the changes performed by A will be detected at B?

Specifically, if A alternately writes to one file, and then the other, is it reasonable to expect that B will notice alternating changes to F1 and F2? Or could B conceivably detect a series of changes on F1 and then a series on F2?

I know there are a lot of assumptions embedded in the question. For instance, I am virtually certain that, even operating on just one file, if A performs 100 operations on the file, B may see a smaller number of changes that give the same result, due to NFS caching some of the actions on A before they are communicated to B. And of course there would be issues with concurrent file access even if NFS weren't involved and both the reading and the writing process were running on the same real file system.

The reason I'm even putting the question up here is that it seems like most of the time, the setup described above does detect the changes at B in the same order they are made at A, but that occasionally some events come through in transposed order. So, is it worth trying to make this work? Is there some way to tune NFS to make it work, perhaps cache settings or something? Or is fine-grained behavior like this just too much expect from NFS?

JustJeff
  • 295
  • 2
  • 13

3 Answers3

2

I wouldn't rely on consistent ordering across the network. NFS itself generally only guarantees that after one client closes a file, another client opening it should see those changes. (And this says nothing about the observed behavior on the server's filesystem.)

What are your NFS client, server, and protocol versions, though? The Linux kernel NFS client, for example, changed (default) attribute caching behaviors around 2.6.18, and you can mount with -o sync for no write caching at all (data or attribute). NFSv4 also allows more control over caching behavior than NFSv3.

ephemient
  • 1,420
  • 1
  • 11
  • 8
  • i don't have the exact version numbers, but the actual setup involved embedded systems with NFS pinned down at version 2 something. – JustJeff Mar 12 '10 at 23:06
1

This

Assume that B polls for changes

and

Specifically, if A alternately writes to one file, and then the other, is it reasonable to expect that B will notice alternating changes to F1 and F2? Or could B conceivably detect a series of changes on F1 and then a series on F2?

mean that no matter what guarantees the filesystem makes there is a race condition here.

That is: you can't count count on the order in which process B detects the changes.

Consider what happens if

  1. B polls Foo
  2. A writes to Foo
  3. A writes to Bar
  4. B polls Bar
dmckee --- ex-moderator kitten
  • 1,403
  • 1
  • 12
  • 13
  • Not sure that if A does ..12121212.., that this sort of race would allow B to see anything stranger than ..11221122.., but you are certainly right about B observing at least some transposition of events. Which, as it turns out, is enough to invalidate the code I was looking at. – JustJeff Mar 12 '10 at 23:04
0

You might like to see the answer to another question, which links to a description of Transactional NTFS. It's really cool, and might help your situation.

Community
  • 1
Michael Rodrigues
  • 63
  • 6