ocfs2: free inode when i_count becomes zero
PATCH 2/10 ocfs2: free inode when i_count becomes zero
From: Xue jiufei <[email protected]>
Subject: ocfs2: free inode when i_count becomes zero
Disk inode deletion may be heavily delayed when one node unlink a file after the same dentry is freed on another node(say N1) because of memory shrink but inode is left in memory. This inode can only be freed while N1 doing the orphan scan work.
However, N1 may skip orphan scan for several times because other nodes may do the work earlier. In our tests, it may take 1 hour on 4 nodes cluster and this will cause bad user experience. So we think the inode should be freed when i_count becomes zero to avoid such circumstances.
---
fs/ocfs2/inode.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)
fs/ocfs2/inode.c renamed from fs/ocfs2/inode.c~ocfs2-free-inode-when-i_count-becomes-zero +1 -9
@@ -1192,17 +1192,9 @@ void ocfs2_evict_inode(struct inode *inoint ocfs2_drop_inode (struct inode *inode) {struct ocfs2_inode_info *oi =OCFS2_I (inode); -int res; -trace_ocfs2_drop_inode ((unsigned long long )oi->ip_blkno, inode->i_nlink, oi->ip_flags); - -if (oi->ip_flags &OCFS2_INODE_MAYBE_ORPHANED ) - res =1 ; -else - res =generic_drop_inode (inode); - -return res; +return 1 ; }/*
_
PATCH 2/10 ocfs2: free inode when i_count becomes zero
Quoted 8 lines · Andrew Morton
From: Xue jiufei <[email protected]>
Subject: ocfs2: free inode wheni_countbecomes zeroDisk inode deletion may be heavily delayed when one node unlink a file after the same dentry is freed on another node(say N1) because of memory shrink but inode is left in memory. This inode can only be freed while N1 doing the orphan scan work.
Quoted 4 lines
However, N1 may skip orphan scan for several times because other nodes may do the work earlier. In our tests, it may take 1 hour on 4 nodes cluster and this will cause bad user experience. So we think the inode should be freed when
i_countbecomes zero to avoid such circumstances.
Firstly, thanks for the patch Xue.
I understand your problem and I definitely agree that it hurts the user experience. If the inode is free to be deleted we shouldn't be taking so long to get rid of it.
What I'm worried about is that we're always going to tell the kernel to evict the inode now, which will always cause some sort of cluster locking.
I need to look at this more and think about it a bit. Maybe there's a better way?
--Mark
--
Mark Fasheh
PATCH 2/10 ocfs2: free inode when i_count becomes zero
Quoted 20 lines · Mark Fasheh
Quoted 8 lines · Andrew Morton
From: Xue jiufei <[email protected]>
Subject: ocfs2: free inode wheni_countbecomes zeroDisk inode deletion may be heavily delayed when one node unlink a file after the same dentry is freed on another node(say N1) because of memory shrink but inode is left in memory. This inode can only be freed while N1 doing the orphan scan work.
Quoted 4 lines
However, N1 may skip orphan scan for several times because other nodes may do the work earlier. In our tests, it may take 1 hour on 4 nodes cluster and this will cause bad user experience. So we think the inode should be freed when
i_countbecomes zero to avoid such circumstances.Firstly, thanks for the patch Xue.
I understand your problem and I definitely agree that it hurts the user experience. If the inode is free to be deleted we shouldn't be taking so long to get rid of it.
Quoted 8 lines
What I'm worried about is that we're always going to tell the kernel to evict the inode now, which will always cause some sort of cluster locking.
I need to look at this more and think about it a bit. Maybe there's a better way?
--Mark--
In most cases, the refcount of inode would not be zero because there is one or more dentrys associated with it. So only in this situation that a dentry is force to be freed because of memory pressure but the inode is left, we increase the probability of inode eviction. I think it is acceptable.
Thanks,
Xuejiufei
Quoted 3 lines
Mark Fasheh
.
PATCH 2/10 ocfs2: free inode when i_count becomes zero
Hi
Quoted 21 lines · Xue jiufei
Quoted 20 lines · Mark Fasheh
Quoted 8 lines · Andrew Morton
From: Xue jiufei <[email protected]>
Subject: ocfs2: free inode wheni_countbecomes zeroDisk inode deletion may be heavily delayed when one node unlink a file after the same dentry is freed on another node(say N1) because of memory shrink but inode is left in memory. This inode can only be freed while N1 doing the orphan scan work.
Quoted 4 lines
However, N1 may skip orphan scan for several times because other nodes may do the work earlier. In our tests, it may take 1 hour on 4 nodes cluster and this will cause bad user experience. So we think the inode should be freed when
i_countbecomes zero to avoid such circumstances.Firstly, thanks for the patch Xue.
I understand your problem and I definitely agree that it hurts the user experience. If the inode is free to be deleted we shouldn't be taking so long to get rid of it.
Quoted 7 lines
Quoted 7 lines
What I'm worried about is that we're always going to tell the kernel to evict the inode now, which will always cause some sort of cluster locking.
I need to look at this more and think about it a bit. Maybe there's a better way?
--Mark
I am sorry that I made a mistake. This patch may lead to data loss when i_count becomes zero but there still exists dirty pages in i_mapping, the dirty pages would be freed without flushing the data.
To avoid this problem, we should flush dirty page before dropping the inode, but I don't think it it a good idea to flush page in function ocfs2_drop_inode().
Is there any better way to solve this problem?
Thanks,
Xuejiufei
Quoted 14 lines
Quoted 1 line
--
In most cases, the refcount of inode would not be zero because there is one or more dentrys associated with it. So only in this situation that a dentry is force to be freed because of memory pressure but the inode is left, we increase the probability of inode eviction. I think it is acceptable.
Thanks,
XuejiufeiQuoted 3 lines
Mark Fasheh
.