On Sun, 5 Apr 2009, Wendy Cheng wrote:
> Based on code reading ...
> 1. iput() gets inode_lock (a spin lock)
> 2. iput() calls iput_final()
> 3. iput_final() calls gfs_drop_inode() that calls
> generic_drop_inode()
> 4. generic_drop_inode() unlocks inode_lock.
>
> In theory, this logic violates the usage of spin lock as it is expected
> to lock for a short period of time but gfs_drop_inode() could take a
> while to finish. It has a blocking write page that need to make sure the
> data gets sync-ed to storage before it can returns. Make matter worse is
> that inode_lock is a global lock that could block non-GFS threads. One
> would think a quick fix is to drop the inode_lock at the beginning of
> gfs_drop_inode() and then re-acquires it after gfs sync the page.
> Unfortunately, inode_lock is not an exported symbol and GFS is an
> out-of-tree filesystem that has to be compiled as a kernel module. So
> this trick won't work for GFS.
Actually, it can work. inode_lock is not private and gfs can unlock/lock
it:
--- gfs-orig/ops_super.c 2009-01-22 13:33:51.000000000 +0100
+++ gfs/ops_super.c 2009-04-06 13:07:06.000000000 +0200
@@ -9,6 +9,7 @@
#include <linux/statfs.h>
#include <linux/seq_file.h>
#include <linux/mount.h>
+#include <linux/writeback.h>
#include "gfs.h"
#include "dio.h"
@@ -68,8 +69,11 @@
if (ip &&
!inode->i_nlink &&
S_ISREG(inode->i_mode) &&
- !sdp->sd_args.ar_localcaching)
+ !sdp->sd_args.ar_localcaching) {
+ spin_unlock(&inode_lock);
gfs_sync_page_i(inode, DIO_START | DIO_WAIT);
+ spin_lock(&inode_lock);
+ }
generic_drop_inode(inode);
}
Tomorrow I'll give it a try, there's no time to test it today.
> With a flight to catch tomorrow and a flu-infected body, I lose the will
> to think over what the correct fix should and/or will be.
A speedy recover! And thank you all your efforts!
Best regards,
Jozsef
--
E-mail : kadlec@xxxxxxxxxxxx, kadlec@xxxxxxxxxxxxxxxxx
PGP key: http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address: KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
