Correct an NFS bug related to ftruncate() operations. When the client

Correct an NFS bug related to ftruncate() operations.  When the client
truncates a file it has to do a lot of magic on the buffer cache to scrap
buffers beyond the new EOF and properly handle the buffer that straddles
the truncation point.  To ease the job the NFS client performs a flush.

This creates a problem, however, because the server includes attribute
information in its RPC replies (for NFSv3) which is then cached by the
client via nfs_loadattrcache().  This information is used by the client
to detect races with other entities modifying the same file but it creates
confusion when the client is in the middle of trying to do an ftruncate(),
especially if some of the buffer flushes prior to the truncate extend the
file.  The server will report file sizes that don't match either the 'before'
or 'after' information that the client has.

To deal with this situation we have to check for mismatches after we flush
and loop if we find any, prior to issuing the setattrrpc().   Such mismatches
are virtually guarenteed to occur even with just a single NFS client working
the file.  We also do a sanity check after issuing the stattrrpc().  This
second sanity check will only be triggered if our NFS client is racing
another client on the same file.

It's quite possible that there are still client-side bugs related to this
issue even with this commit.

Reported-by: Andreas Hauser <andy@splashground.de>