Hi Chuck,

On Sep 08 05:15 PM, Chuck Lever wrote:
quoted text
> This seems to correspond with the strace logs, which show that you
> stopped the bad run before it generated more writes.

Yes.  Sorry.   I stopped the writer once the reader saw the NULL bytes.

quoted text
> Normally this isn't a big deal, as NFS likes applications to serialize
> access to shared files.  However, in this case we expect the .flush()
> to force all dirty bytes out at once, and this is definitely not
> occurring....
>=20
> The third thing is that I don't see any flush or fsync system calls in
> the strace logs, even though the writer.py script invokes fp.flush().
> I'm not terribly familiar with Python's flush().  How do you expect
> the flush() method to work?

I think fp.flush() in Python is equivalent to fflush() i.e. it only
flushes the stdio buffer.  It doesn't actually call fsync or fdatasync
or anything like that.

We can pretty easily change the Python code to use the syscall
write()/etc methods.

quoted text
> I wonder why the client is using FILE_SYNC writes and not
> UNSTABLE+COMMIT. Are the clients using the "sync" mount option?  I
> don't see O_SYNC on the open.

I've exported them on the server as sync e.g. in exports:

  /export		192.168.0.0/24(rw,sync)

However I don't give any special options when mounting e.e. on the
client:

  mount machine:/export  mntpnt

Anyway thanks for looking at this and let me know if I can do anything
else!


					=3Da=3D


--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Aaron Straus
aaron@merfinllc.com