Joel Becker wrote: > On Tue, Feb 10, 2009 at 09:33:28AM +0800, Wengang Wang wrote: >> one thing is that, the "nfs_sync_lock" will be one in count or more than >> one? >> I think having lots of this kind of lock(one for each meta block) will >> bring us least performance impact for deletions. >> well so much locks eat memory. for balancing, how about setting up 16(or >> 32) such locks? different inode goes to different lock according to its >> block number. and 16(or 32) such locks won't take much memory. --just >> like the idea in my original patch. > > No, we'll have one lock per superblock. There's no performance > impact unless you have stale NFS clients. We take the lock in PR mode > in delete_inode, and the lock caching mechanism will keep it for us. > The lock will only be unlocked when a stale NFS client wants to lookup > its handle. Otherwise, all nodes will share the PR lock.
yes. I know what EX/PR mean and lock caching. for NFS backed on OCFS2, I think there could be stale clients according to the file accessing mode(create, delete on so on) on ocfs2. when a EX lock is held for nfs, all delete_inode()s have to wait. that's a big lock and could be a performance impact. here, I emphasize ALL. I don't think it's simply like rename lock. is that an abnormal case? thanks, wengang. _______________________________________________ Ocfs2-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/ocfs2-devel
