Kadlecsik Jozsef wrote:
You mean the part of the patch
@@ -1503,6 +1503,15 @@ gfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct
error = gfs_glock_nq_init(ip->i_gl, LM_ST_SHARED, LM_FLAG_ANY, &gh);
if (!error) {
generic_fillattr(inode, stat);
+ if (S_ISREG(inode->i_mode) && dentry->d_parent
+ && dentry->d_parent->d_inode) {
+ p_inode = igrab(dentry->d_parent->d_inode);
+ if (p_inode) {
+ pi = get_v2ip(p_inode);
+ pi->i_dir_stats++;
+ iput(p_inode);
+ }
+ }
gfs_glock_dq_uninit(&gh);
}
might cause a deadlock: if the parent directory inode is already locked,
then this part will wait infinitely to get the lock, isn't it?
If I open a directory and then stat a file in it, is that enough to
trigger the deadlock?
No, that's too simple and should have came out much earlier, the patch is
from Nov 6 2008. Something like creating files in a directory by one
process and statting at the same time by another one, in a loop?
It would be a shame if GFS(1/2) ends up losing you as a user - not many
users can delve into the bits and bytes like you.
My suggestion is that you work directly with GFS engineers, particularly
the one who submitted this patch. He is bright and hardworking - one of
the best among young engineers within Red Hat. This patch is a good
"start" to get into the root cause (as gfs readdir is hung on *every*
console logs you generated). Maybe a bugzilla would be a good start ?
I really can't keep spending time on this. As Monday arrives, I'm always
behind few of my tasks....
-- Wendy
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
