[Bugs] [Bug 1335373] cyclic dentry loop in inode table

bugzilla at redhat.com bugzilla at redhat.com
Sat May 11 13:19:19 UTC 2019


https://bugzilla.redhat.com/show_bug.cgi?id=1335373



--- Comment #11 from Raghavendra G <rgowdapp at redhat.com> ---
Stale dentries on client itable can end up making both src and dst exist after
a "mv src dst" succeeds and they resolve to same inode.

>From one of the production setups using SAS:

md-cache doesn't resolve a (parent, basename) pair to an inode. Instead its the
access layers (fuse, gfapi) that resolve the path to an inode. md-cache just
gives back the stat stored in the context of inode. Which means both,
* (Nodeid:139842860710128, dm_errori.sas7bdat)
* (Nodeid:139842860710128, dm_errori.sas7bdat.lck)

are resolving to same inode. Since they resolve to same inode, lookup is served
from same cache and hence identical stats. When md-cache is turned off, both
lookups go on same inode, but server-resolver on brick ignores the gfid sent by
client. Instead it resolves the entry freshly and hence will get a different
inode for each lookup.

So the actual problem is in fuse inode table, where there are two dentries for
the same inode. How did we end up in that situation? Its likely that a lookup
(Nodeid:139842860710128, dm_errori.sas7bdat.lck) was racing with rename
(dm_errori.sas7bdat, dm_errori.sas7bdat.lck) and rename updated inode table on
client first. The lookup which hit storage/posix before rename relinked the
stale dentry. Without lookups reaching bricks, client never got a chance to
flush its stale dentry. The problem is exactly the same DFS is trying to solve
on brick stack.

So, the role of stat-prefetch here is that it is preventing lookups from
reaching bricks. Once lookups reach bricks, stale dentry from inode table will
be purged and the error condition goes away.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Bugs mailing list