drastic changes to allocsize semantics in or around 2.6.38?

[Dave Chinner]

On Mon, May 23, 2011 at 05:01:44AM -0400, Christoph Hellwig wrote:
> On Mon, May 23, 2011 at 11:20:34AM +1000, Dave Chinner wrote:
> > 
> > The state used to track dirty inode release calls is not reset when
> > an inode is reallocated and reused from the reclaimable state. This
> > leads to specualtive preallocation not being truncated away in the
> > expected manner for local files until the inode is subsequently
> > truncated, freed or cycles out of the cache.
> > 
> > Signed-off-by: Dave Chinner <dchinner at redhat.com>
> > ---
> >  fs/xfs/xfs_iget.c |    7 +++++++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> > 
> > diff --git a/fs/xfs/xfs_iget.c b/fs/xfs/xfs_iget.c
> > index cb9b6d1..e75e757 100644
> > --- a/fs/xfs/xfs_iget.c
> > +++ b/fs/xfs/xfs_iget.c
> > @@ -241,6 +241,13 @@ xfs_iget_cache_hit(
> >  		 */
> >  		ip->i_flags |= XFS_IRECLAIM;
> >  
> > +		/*
> > +		 * clear the dirty release state as we are now effectively a
> > +		 * new inode and so we need to treat speculative preallocation
> > +		 * accordingly.
> > +		 */
> > +		ip->i_flags &= ~XFS_IDIRTY_RELEASE;
> 
> Btw, don't we need to clear even more flags here?  To me it seems we
> need to clear XFS_ISTALE, XFS_IFILESTREAM and XFS_ITRUNCATED as well.

XFS_ISTALE is cleared unconditionally at the end of the function,
which means that any lookup on a stale inode will clear it. I'm not
absolutely sure this is right now that I think about it but that's a
different issue.

XFS_ITRUNCATED is mostly harmless, so it isn't a but issue, but we
probably should clear it. I'm not sure what the end result of not
clearing XFS_IFILESTREAM is, but you are right in that it should not
pass through here, either. I'll respin the patch to clear all the
state flags that hold sub-lifecycle state.

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com