[Gluster-devel] no dentry for non-root inode

[Amar Tumballi]

Hello Emmanuel,
>>> [2011-11-05 03:12:47.856612] W [inode.c:1044:inode_path]
>>> 0-/export/wd3e/inode: no dentry for non-root inode
>>> -9091625530591748852: d968c71c-9c3f-471e-81d4-0ebfda34dd0c

This log is not a 'error', but warning. What that means is, this 
condition need not be causing the error seen by the user.

One of the case why this warning would come up is from below set of 
operations:

machine 1 --> user creates a file  (inode created, fd on inode is 
created, dentry with filename is linked to parent inode).

machine 2 --> just do a 'cat' on file (inode is looked up, updated in 
inode_table).

machine 3 --> delete the file (dentry is unlinked from inode, inode 
still valid as there is fd open on it)

machine 2 --> try to perform some operation on the file (inode is tried 
to looked up, inode is valid on server as there is a 'fd' open on it, 
but there is no 'PATH' for it, as dentry is unlinked), user gets error 
ENOENT. (this is when you can see such logs in server).

machine 1 --> perform operations on 'fd' --> succeeds as fd is still valid.

machine 1 --> close the fd.. (inode gets destroyed on server, no more 
valid inode for that gfid).

Hope you can now relate this type of pattern in your testing.

> The error message seems a bit misleading: what is missing is not a true
> dentry, but a GlusterFS-internal simulacrum of one, which seems to be
> gone because the parent inode was forgotten.  I also see that the
> message comes from __inode_path, which is only called from three of the
> performance translators in non-essential code to dump fd contexts.  The
> first thing I'd do is try to figure out which code path is actually
> involved, and why anyone's dumping that context in the first place.
> I'll bet there's a platform-specific reason, requiring a
> platform-specific tweak to avoid the underlying issue.
>
>
Jeff, Thanks for answering this part. Hope my answer gives some idea on 
why inode_path is used (internal terms wise, just to populate 'loc_t *' 
on server, as storage/posix works based on paths).

Regards,
Amar