New subject: ndmpcopy?

22 Jul 1998


      Ok, so the behavior acts like this:
1) On client A, which had the filesystem mounted before the ndmpcopy,
   the new data does not show up in directory X.
2) On client B, which mounts after the ndmpcopy starts, the data shows
   up.
3) On client A, after you unmount and remount, the data shows up.
I have a theory based on the nfs protocol which might explain the behavior.
Have your flamers ready because this could be wrong wrong wrong.  Keep in
mind that I've never actually read any nfs client source code...so set
your expectations accordingly...
When you do a ls on a directory you've never accessed before from a client,
you get the data block for the directory and put it in your buffer cache.
Later, if somebody does an ls on the same directory on the nfs client,
the client needs to see if the buffer cache's data is valid.  It does
this by executing a getattr() nfs call.  If the timestamp on the server
has not changed, then the client will think that it's buffer cache is valid
and not actually get the directory data.
(this is why latex takes so long in nfsv2 even if the whole thing is
in your buffer cache, depending on how much latex stuff you have you
might have to do 10,000 getattr() calls to validate your buffer caches--
whereas if you're running on local disk you _know_ the buffer caches are
valid).
So, if the ndmpcopy is not updating the timestamp on that directory until
the end, the client will happily believe that the directory's contents
(as listed incorrectly in the clients buffer cache) is correct.
But if you unmount and remount, that invalidates that part of the buffer
cache, causing the data to magically appear.
And if you mount on another client after the ndmpcopy is in progress, you
don't have an incorrect buffer cache entry.
This theory explains the behavior.  Here are experiments to increase
confidence in the theory:
1) packet trace between the server and the client, to watch for the
   getattr(), but not the actual read of that directory.
2) Manually create a file in the directory during the ndmpcopy from a second
   client (which causes the directory timestamp to update, which will mean
   when the first client does it's buffer cache validation with getattr() it
   will realize that it's buffer cache is out-of-date.
3) Check the timestamp on the directory from client 1 before the ndmpcopy,
   and from both clients during the ndmpcopy.
Of course, this isn't important enough for me to try these experiments.
If this is true, then it's a simple netapp bug which can be fixed by
updating the timestamp on the target directory at the beginning of
the ndmpcopy.
Of course, if it's wrong then it's wrong :-)
Darrell Root
rootd@nas.nasa.gov

Re: ndmpcopy?