On Fri, Aug 29, 2014 at 04:29:34PM -0400, Brian Foster wrote:
> Here's a drop of what I'm testing over the weekend. It passes some quick
> tests, but only lightly tested so far.
fsx has been running for over 3 days without a failure and I've kicked
off a parallel fsstress today that so far hasn't caused any problems.
Given that, I think the patches here help reduce the likelihood of
errors from collapse.
> 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.
That said, a test to skip the post-collapse truncate confirms that the
behavior of patch 3 is potentially problematic in the event of failure.
E.g., there is no behavior analogous to the zeroing of prealloc space
for extending truncates.
I think the right thing to do here might be for the collapse to
writeback and invalidate the range following the space that was freed to
EOF and to retain the eofblocks trim.
> 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.
> 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(-)
> xfs mailing list