On Tue, Jan 05, 2016 at 02:42:14AM -0800, Christoph Hellwig wrote: > On Mon, Jan 04, 2016 at 05:43:10PM -0800, Darrick J. Wong wrote: > > Hmm. This might be the cause of the occasional complaints I've been seeing > > where allocated blocks remain in the COW fork when the inode is being cleared > > out. That said, the xfs_reflink_end_cow_failed() is apparently missing a > > xfs_bunmapi_cow() to actually clean out the COW fork. > > I can still reproduce xfs_reflink_cancel_pending_cow tripping over > allocated blocks in the COW fork over NFS. generic/154 reproduces > it 100% over NFS, although when adding a delay before the cleanup > it disappears. I'm currently trying to figure out why. Ok. I spent a couple of days trying to find all the places where we need to delete CoW reservations (hole punch, truncate, etc.) and found some places where the code was leaving reservations behind in the CoW fork (most notable truncate). I also made the inode eviction code purge any CoW leftovers, so that should all go away. I also wrote some more xfstests that try to hit all the CoW-cancelling code paths (fpunch, fzero, fcollapse, finsert, truncate, -EIO) to smoke test all that. By the way, do you have a testcase handy for the "non-blocking writeback EAGAIN" case? I'm guessing that we could hit that pretty easily by lowering dirty_background_* and dirtying a lot of pages while reflinking? (Will push new code to github in a day or two.) --D _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
