Received: by 2002:a05:6a10:8a4d:0:0:0:0 with SMTP id dn13csp1272909pxb; Fri, 13 Aug 2021 19:15:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNLQnEJLKI1UDx3gpPuNWPc6zqQZ7ytbDP2ZknaDxyikpiPtQovkblVtbfa0OteM+ElNjU X-Received: by 2002:a92:360e:: with SMTP id d14mr3691088ila.171.1628907331570; Fri, 13 Aug 2021 19:15:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628907331; cv=none; d=google.com; s=arc-20160816; b=0bm4NrO7oY67ljetdpme5tZn1zaN+MvimYoKToP6ff0QPURdT6i3WEz+5DuvxCR0kG ZZKzQ/6xA2i+fhNuvQWpSz2ymWSRNCSIYaVQVkir26HaNUcu3cQQVr8Pg2qGZ5FK41vY LYzBDp+Gf/RiRd5xHtVHzpKQxdW7RLZPQAcFpH3wNwUkMdS+bax34H23YqQYDx5P7+8H ODVJVSDA2rFyGi69Ivb77dRMnK9V4wJOZcH4Nf3CAj/fykcEaWO4lreZddp6TG7JxSEC fim6BLUsnUYXPs7pLYv0C6+1q+S67CUs4KGY8p8TfSalBwTJbaARD18ajZ6scqoq9k4C oruw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=aWvonCw2yo2vd2q+b1dQxVkv3cl3/j40oM7U3bneRG8=; b=g5Z+/Wu3hKfpSVcuy40T9msqKOnLRJJI/KbZrk90y08LzajwkRPHlL4LMlnezwZcP1 B6t8M4FxtpW9YIwCV8JO08rxe82rW6F3cbXH1tZ49Ne44zch3CqSqn5L2maGuv1IW9TU QeKNuxUDmpaQ46O05iqhe044/Rn8Iyma8/0m059NSSdGkc/0YSTwUX8gRrKeWcTjt61G EDKkQqaMczujCJvLFeTUgGLZD7qvLSP+ha/No5CwaTk9bHqA/xuh1VrzOJm0+LQ9Csxw of3UqCsCLeCx4bpf7ZwtxEiRXkpaVYVBPM1NBP0lIVdoh6akZc+rFHTJB3MsV9NAtw3A 9N+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n16si3128641jap.23.2021.08.13.19.15.15; Fri, 13 Aug 2021 19:15:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236327AbhHNCPl (ORCPT + 99 others); Fri, 13 Aug 2021 22:15:41 -0400 Received: from szxga03-in.huawei.com ([45.249.212.189]:13315 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232651AbhHNCPl (ORCPT ); Fri, 13 Aug 2021 22:15:41 -0400 Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4GmkXX5NtVz85dS; Sat, 14 Aug 2021 10:15:08 +0800 (CST) Received: from dggema766-chm.china.huawei.com (10.1.198.208) by dggemv711-chm.china.huawei.com (10.1.198.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Sat, 14 Aug 2021 10:15:11 +0800 Received: from [10.174.177.210] (10.174.177.210) by dggema766-chm.china.huawei.com (10.1.198.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Sat, 14 Aug 2021 10:15:11 +0800 Subject: Re: [PATCH] ext4: if zeroout fails fall back to splitting the extent node To: Theodore Ts'o , Ext4 Developers List CC: References: <20210813212701.366447-1-tytso@mit.edu> From: yangerkun Message-ID: <2714202a-872e-aa75-7033-fb06a47b9241@huawei.com> Date: Sat, 14 Aug 2021 10:15:11 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <20210813212701.366447-1-tytso@mit.edu> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.210] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggema766-chm.china.huawei.com (10.1.198.208) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org 在 2021/8/14 5:27, Theodore Ts'o 写道: > If the underlying storage device is using thin-provisioning, it's > possible for a zeroout operation to return ENOSPC. > > Commit df22291ff0fd ("ext4: Retry block allocation if we have free blocks > left") added logic to retry block allocation since we might get free block > after we commit a transaction. But the ENOSPC from thin-provisioning > will confuse ext4, and lead to an infinite loop. > > Since using zeroout instead of splitting the extent node is an > optimization, if it fails, we might as well fall back to splitting the > extent node. > > Reported-by: yangerkun > Signed-off-by: Theodore Ts'o > --- > > I've run this through my battery of tests, and it doesn't cause any > regressions. Yangerkun, can you test this and see if this works for > you? Will do it. > > fs/ext4/extents.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c > index 92ad64b89d9b..501516cadc1b 100644 > --- a/fs/ext4/extents.c > +++ b/fs/ext4/extents.c > @@ -3569,7 +3569,7 @@ static int ext4_ext_convert_to_initialized(handle_t *handle, > split_map.m_len - ee_block); > err = ext4_ext_zeroout(inode, &zero_ex1); > if (err) > - goto out; > + goto fallback; > split_map.m_len = allocated; > } > if (split_map.m_lblk - ee_block + split_map.m_len < > @@ -3583,7 +3583,7 @@ static int ext4_ext_convert_to_initialized(handle_t *handle, > ext4_ext_pblock(ex)); > err = ext4_ext_zeroout(inode, &zero_ex2); > if (err) > - goto out; > + goto fallback; > } > > split_map.m_len += split_map.m_lblk - ee_block; > @@ -3592,6 +3592,7 @@ static int ext4_ext_convert_to_initialized(handle_t *handle, > } > } > > +fallback: > err = ext4_split_extent(handle, inode, ppath, &split_map, split_flag, > flags); > if (err > 0) >