On Sun, Jan 03, 2016 at 01:07:53PM +0100, Christoph Hellwig wrote:
> Otherwise we leak COW allocations done earlier in writepage. This
> can be reproduced fairly easily when we hit the non-blocking writeback
> EAGAIN case.
>
> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
> ---
> fs/xfs/xfs_aops.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
> index 185415a..9c69dc3 100644
> --- a/fs/xfs/xfs_aops.c
> +++ b/fs/xfs/xfs_aops.c
> @@ -588,6 +588,7 @@ xfs_cancel_ioend(
> {
> xfs_ioend_t *next;
> struct buffer_head *bh, *next_bh;
> + int error;
>
> do {
> next = ioend->io_list;
> @@ -605,6 +606,12 @@ xfs_cancel_ioend(
> unlock_buffer(bh);
> } while ((bh = next_bh) != NULL);
>
> + if (ioend->io_flags & XFS_IOEND_COW) {
> + error = xfs_reflink_end_cow_failed(
> + XFS_I(ioend->io_inode),
> + ioend->io_offset, ioend->io_size);
> + WARN_ON_ONCE(error);
> + }
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.
Good catch, in any case. Thank you for the testing and patches! :)
--D
> mempool_free(ioend, xfs_ioend_pool);
> } while ((ioend = next) != NULL);
> }
> --
> 1.9.1
>
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
|