Here's a drop of what I'm testing over the weekend. It passes some quick tests, but only lightly tested so far. My biggest question at this point is whether there is any risk to the shift of the post-eof extent if the subsequent truncate happens to fail. If it's not worth dealing with that, we could just drop patch 3 and leave the eofblocks trim permanently. In fact, it might even be a good idea to go back to the original [start,-1] writeback in collapse range given that the free file space helper could change at some point to only write and punch out the range being freed... and then we're left shifting a bunch of extents after the freed range that could have dirty data in pagecache, which sounds bad. Thoughts? Brian Brian Foster (4): xfs: track collapse via file offset rather than extent index xfs: refactor xfs_bmap_shift_extents() into multiple functions xfs: allow collapse to handle delalloc extents xfs: remove file writeback and eofblocks trim from collapse range fs/xfs/libxfs/xfs_bmap.c | 302 ++++++++++++++++++++++++++++++++--------------- fs/xfs/libxfs/xfs_bmap.h | 7 +- fs/xfs/xfs_bmap_util.c | 32 +---- 3 files changed, 214 insertions(+), 127 deletions(-) -- 1.8.3.1 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
