![]() | |||||||||||||
Messages in this thread |
On Mon, Jun 27, 2005 at 06:25:43PM +0400, Vladimir Saveliev wrote: > Sorry, would you please explain what is wrong in having the below > > if (inode->i_nlink != 0 || atomic_read(&inode->i_count) > 1) > > in reiser4_put_inode. Between that atomic_read(&inode->i_count) and the atomic_dec_and_lock(&inode->i_count, &inode_lock)) in iput someone could have grabbed a reference. > The problem is that on file removal reiser4 wants to do > truncate_inode_pages in reiser4_delete_inode. We used reiser4_drop_inode > for that. As long as drop_inode was about to die, we decided to do file drop_inode is not going to die, we need it to support filesystems that want to call generic_delete_inode even for a non-null i_nlink. What's hopefully going to die is the last instance of it that isn't either generic_drop_inode or generic_delete_inode. > You said: > -------- > So what you want is actually to move the truncate_inode_pages out of > generic_delete_inode and into ->delete_inode? > > > Looking at the code another strategt makes more sense: > > - move the truncate_inode_pages at the beginning of clear_inode. > All callers but one already do it just before that call, but > the one that doesn't will require a full audit of all ->delete_inode > instances > - make the first half of clear_inode into a helper (__clear_inode or > whatever), and make ->clear_inode responsible for calling it as first > thing for a normal fs or call it in clear_inode if ->clear_inode > doesn't > exist. that way we can also move the invalidate_inode_buffers out > there > easily later for filesystems that don't use buffer_heads at all. > > p.s. please try to keep -fsdevel Cc'ed on the mail related to core > changes > ------- > > I hoped that we can solve the problem internally in reiser4. If > put_inode is about to be removed we will have to do ssomething like > that. In fact I know from some cluster filesystem folks that have a similar problems as yours. So getting the truncate_inode_pages under control of the filesystems sounds like a very good choice. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-06-27 21:38 [from the cache] ©2003-2008 | |||||||||||||