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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
