[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] Freeze with cluster-2.03.11

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);
+                       }
+               }
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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]