On Fri, Feb 13, 2009 at 09:32:53AM +1100, Dave Chinner wrote:
> > Yes, I agree. I just don't have the time to hunt it down. I see
> > there's a call to xfs_idestroy_fork() in xfs_ireclaim() for directories
> > but xfs_ireclaim() gets called after xfs_iflush() in xfs_reclaim_inode().
>
> I suspect it should be in xfs_inactive() if we are in local format.
> This is what happens with the attribute fork. I think that is where
> we need something like:
>
> if ((ip->i_d.di_mode & S_IFMT) == S_IFDIR &&
> ip->i_d.di_nextents == 0)
> xfs_idestroy_fork(ip, XFS_DATA_FORK);
Why would we special case directories?
> > Might also need something like:
> >
> > @@ -2445,6 +2447,7 @@ xfs_idestroy_fork(
> > kmem_free(ifp->if_u1.if_data);
> > ifp->if_u1.if_data = NULL;
> > ifp->if_real_bytes = 0;
> > + ifp->if_bytes = 0;
> > }
> > } else if ((ifp->if_flags & XFS_IFEXTENTS) &&
> > ((ifp->if_flags & XFS_IFEXTIREC) ||
>
> Looking at that, the whole if (local) {} else if (extent/btree)
> code could probably be replaced with a single call to
> xfs_iext_destroy() as it does the cleanup correctly in both cases,
> anyway....
We could, but with the way the function name, comments and how the
unions are set up it would be very confusing to the user.
Btw, I can't reproduce this issue with the extent.c program and the
invocation from the next patch. Does it need other parameters to
reproduce?
|