phdeniel/nfs-ganesha — Issue #14: "Ghost entries" in NFSv4 mounting FSAL_VFS
Author: phdeniel
Created: 2011-10-21 20:45:16+00:00
State: open

Jim noticed that the FSAL_VFS daemon could behave in weird ways when mounted in NFSv4 : a few entries that exist on the server would not appear when "ls-ing" on the directory, but you could "ls on the entry itself". In other word, in directory d/ you have an entry (let's call it d/f°, you do not see 'f' when 'ls d' but you see f when 'ls f' from d/ .
At the protocol level, the OP4_READDIR is involved in the first case, the OP4_LOOKUP in the second case. What wireshark showed is : there are two OP4_READDIR calls, the second starting at offset<>0 but both ending with flag eof=1. The entry that is a "ghost entry" (becomes invisible) is in the first reply, just before the one which is the first in the second reply.
I talked with Olga at BAT on this, wondering why the client would make a second call if the first has eof=1. Answer is : the client has no buffer big enough to store all of the entries obtained at the first pass, it has to throw the latest ones away, so it does a second call to get the one it loses. That makes sense.

My position right now: there is an overlap in-between the first reply and the second, probably because of a badly set offset in the first call. This would occur only when first call had eof=1.

To Jim : I have an idea why renaming the file made him becoming visible again. I believe renaming (which is a write operation to the directory) has impact on the order of the entries. So the renamed entry becomes visible (not in the "overlapped zone"), but another entry came in that zone and probably became invisible. OR (other hypothesis) : the size of the new name (longer) made the first reply buffer being organized differently, preventing from the issue to occur.