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

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



On Mon, 6 Apr 2009, Kadlecsik Jozsef wrote:

> 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:

Darn, it's not EXPORTED! Anyway, I'll patch the kernel and will test it.

Best regards,
Jzosef
--
E-mail : kadlec mail kfki hu, kadlec blackhole kfki hu
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


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