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)..? *nod* > 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 memory. 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). Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
