On Thu, Sep 11, 2014 at 11:20:13AM -0400, Brian Foster wrote:
> On Thu, Sep 11, 2014 at 02:42:43PM +1000, Dave Chinner wrote:
> > On Wed, Sep 10, 2014 at 09:20:26AM -0400, Brian Foster wrote:
> > > Hi all,
> > >
> > > Here's v2 of the collapse clean up. We refactor a bit more via the
> > > insertion of patch 3, otherwise it's similar to v1. This will see some
> > > continued testing, but it survived ~500m fsx operations overnight.
> > >
> > > Brian
> > I'm not sure about the invalidation patch now. On a 1k block size
> > filesystem, generic/127 fails with:
> > +ltp/fsx -q -l 262144 -o 65536 -S 191110531 -N 100000 -R -W
> > fsx_std_nommap
> > +collapse range: 1000 to 3000
> > +do_collapse_range: fallocate: Device or resource busy
> > which indicates we had an invalidation failure. This is probably
> > exposing some other bug, but I haven't had time to look into it yet
> > so I don't know.
> Yeah, I can reproduce this as well, thanks. I think you're referring to
> the xfs_free_file_space() patch (5/5)..?
> FWIW, I don't see the problem
> without that patch, so it appears that the full pagecache truncate is
> still covering up a problem somewhere. I'll try to dig into it...
It's likely that it is leaving a dirty buffer on the page beyond EOF
as a result of the truncate zeroing the remainder of the page in
If I get a chance I'll look at it this afternoon, as this patchset
also seems to be causing a marked increase in the number of fsstress
failures due to stray delalloc blocks in files even on 4k block size
filesystems (e.g. at unmount).