[Ocfs2-devel] [PATCH 1/1] OCFS2: anti stale inode for nfs (V2).
Wengang Wang
wen.gang.wang at oracle.com
Mon Feb 9 19:43:45 PST 2009
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.
More information about the Ocfs2-devel
mailing list