From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cn.fujitsu.com ([59.151.112.132]:43414 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1758889AbaGYCQl (ORCPT ); Thu, 24 Jul 2014 22:16:41 -0400 Message-ID: <53D1BCC9.9030808@cn.fujitsu.com> Date: Fri, 25 Jul 2014 10:11:21 +0800 From: Wang Shilong MIME-Version: 1.0 To: CC: linux-btrfs Subject: Re: [PATCH] Btrfs: fix compressed write corruption on enospc References: <1406213285-19607-1-git-send-email-bo.li.liu@oracle.com> <53D1B8A7.6070302@cn.fujitsu.com> <20140725020824.GB25859@localhost.localdomain> In-Reply-To: <20140725020824.GB25859@localhost.localdomain> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 07/25/2014 10:08 AM, Liu Bo wrote: > On Fri, Jul 25, 2014 at 09:53:43AM +0800, Wang Shilong wrote: >> On 07/24/2014 10:48 PM, Liu Bo wrote: >>> When failing to allocate space for the whole compressed extent, we'll >>> fallback to uncompressed IO, but we've forgotten to redirty the pages >>> which belong to this compressed extent, and these 'clean' pages will >>> simply skip 'submit' part and go to endio directly, at last we got data >>> corruption as we write nothing. >>> >>> Signed-off-by: Liu Bo >>> --- >>> fs/btrfs/inode.c | 12 ++++++++++++ >>> 1 file changed, 12 insertions(+) >>> >>> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c >>> index 3668048..8ea7610 100644 >>> --- a/fs/btrfs/inode.c >>> +++ b/fs/btrfs/inode.c >>> @@ -709,6 +709,18 @@ retry: >>> unlock_extent(io_tree, async_extent->start, >>> async_extent->start + >>> async_extent->ram_size - 1); >>> + >>> + /* >>> + * we need to redirty the pages if we decide to >>> + * fallback to uncompressed IO, otherwise we >>> + * will not submit these pages down to lower >>> + * layers. >>> + */ >>> + extent_range_redirty_for_io(inode, >>> + async_extent->start, >>> + async_extent->start + >>> + async_extent->ram_size - 1); >>> + >>> goto retry; >> BTW, if such ENOSPC happens, it means we could not reserve compressed space. >> So we retry with nocompression codes, it will try to reserve more >> space. Any reason >> we do such things? > Compressed extents needs continuous space while uncompressed extents can have > more choices. Yeah, that is reasonable. Thanks for your answer.^_^ > > thanks, > -liubo > >> Thanks, >> Wang >>> } >>> goto out_free; > . >