OpenSolaris

Customer has two f6900 Solaris 10 domains, client A and client B, which are accessing same NFS file
shared by one NFS server.

On client A, single-thread writer program keeps adding 96-bytes non-zero data to the file.
On client B, multiple reader programs which keeps reading the added data of the file.

Now, a writer and readers don't use any file locking for synchronization 
though writer opens the file with O_SYNC option.

Sometimes reader program reads 96 bytes zero-filler data from the NFS file something 
as follows.

od -v -Ax -x errbuff | more
0000000 0000 0000 0000 0000 0000 0000 0000 0000 <--
0000010 0000 0000 0000 0000 0000 0000 0000 0000 <--
0000020 0000 0000 0000 0000 0000 0000 0000 0000 <--
0000030 0000 0000 0000 0000 0000 0000 0000 0000 <--
0000040 0000 0000 0000 0000 0000 0000 0000 0000 <--
0000050 0000 0000 0000 0000 0000 0000 0000 0000 <--
0000060 0002 246b 0205 0607 0809 0a0b 0c0d 0e0f
0000070 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0000080 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0000090 3031 3233 3435 3637 3839 3a3b 3c3d 3e3f
...

But, when cu checks the NFS file later, no zero-filled data on it.

Customer first saw this issue when he uses third vendor NAS box for NFS server.
But customer and Sun reproduced it with Solaris 10 NFS server on both
NFSv3 and NFSv4.

Frank Hofmann has suggested a valid workaround for this issue.

<snip of work around>
For our customer's situation, forcedirectio on the readonly client(s) will
do what they want - the client will always check with the server for data
and not perform client-side caching.
<end of snip of work around>

N/A