Re: Deleted parent node in PUFFS lookup

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

YAMAMOTO Takashi <yamt%mwd.biglobe.ne.jp@localhost> wrote:

> what do you expect happens when the machine 1 notices the change?
> i expect an error (probably ESTALE) from getcwd().

That would be reasonable. The problem here is that I cannot cd .. and
re-enter the new directory, I still get ENOENT. The only way to get
things sane again is to unmount and remount the volume.

But further investigation suggests glusterfs may be at fault here, as
lookup still returns the deleted file inode, while readdir shows the
newer one. OTOH I suspect everything would get fixed if the kernel could
send a reclaim for the deleted node. That would cause glusterfs to flush
its stale information.

But the kernel has no reason to send a reclaim, as it does not notice
that the node is gone. There is no way to notice the kernel about that
through the PUFFS API, as far as I can tell. I suspect the way to go
would be to catch ESTALE in kernel PUFFS code and initiate a vrele() or
something like this, but that is still very confuse for me yet. Hints
are welcome.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost