[lkml]   [2005]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: -mm -> 2.6.13 merge status
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-06-27 21:38    [W:0.022 / U:31.500 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site