Received: by 2002:a05:6a10:8a4d:0:0:0:0 with SMTP id dn13csp883012pxb; Fri, 13 Aug 2021 08:22:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxtsw6ovpNI/iGS8ZE4e71Mw7aB6cQPLoJ+KcHwSAhlsFsP8mCJ6X18dAH5rKZqFRg5Ev+F X-Received: by 2002:a05:6e02:b28:: with SMTP id e8mr2097554ilu.7.1628868138298; Fri, 13 Aug 2021 08:22:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628868138; cv=none; d=google.com; s=arc-20160816; b=NevPGAEproCp0AOKQI31qfdZcw2S9mSu7C/IaM6QdO6Wu3iBTt4TrTJa8hHFTa7tXK t326R3VarXFAsfG0Q12Sal5Y7jxWdfokQMjdbjgB6rKdCu92QyhCGO/Z7GQTTk7zVQr8 SEFSOdIajs09oIp3StiFv6xcsB+t4K6o6o/TSRdZmYNkXIu0r04CywrFqLmsgiUpb5R4 9aY7U5IG5s9dZGiWvztuXRIvfMzersyYBrCje8Lqrzm5Mqm+FIFpzeAu7PSZdbepTb04 +vu1uU8l/i/P7BjaiaV36T1yG6qF59EyzDtbM3fB2uXW+WVgoCyJaYdKrOOV8z5PzO2k PfLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=dO7iRQ6ALG3bw1kcmWd0iMN1H026cdOGyJQHQfCAUus=; b=s98KAJNhxavBxHTPPX4oVlzCWnJH24OOhxW9x8i78RD5TECxFW6lvjr7X9ULKQUFEA geoPPzIAmpVDHO5wlrPxiTAkk9NmUSWxPVgc7sd2yqcVIMXSjiymT77OMdGdmwGndaCX JJrEB1XYWaOoLnTIxnRaOp6e/vEnLfHTHvYAiZnV7FbAHMkEG+KJ9eyZ5Uq9Ak6H8bwx RSZEQ3qIYcOj876TuOkCAKjt2picIce4ygjILfGoCxyIa8eigHQiztz17vyiBjYXZlkp URLL/hV9YCQHgOBn34iAD9nCXaPUAwFbyWKKZX8kHJ0XusXs0Akk/7xZH/JW/FLrOWqc ArwA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w24si1681826jal.110.2021.08.13.08.21.59; Fri, 13 Aug 2021 08:22:18 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241779AbhHMPVo (ORCPT + 99 others); Fri, 13 Aug 2021 11:21:44 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:57030 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S242717AbhHMPSp (ORCPT ); Fri, 13 Aug 2021 11:18:45 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 17DFI2NT022622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Aug 2021 11:18:02 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id E2F0415C37C1; Fri, 13 Aug 2021 11:18:01 -0400 (EDT) Date: Fri, 13 Aug 2021 11:18:01 -0400 From: "Theodore Ts'o" To: Jan Kara Cc: yangerkun , adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, yukuai3@huawei.com Subject: Re: [PATCH] ext4: stop return ENOSPC from ext4_issue_zeroout Message-ID: References: <20210804125044.2480435-1-yangerkun@huawei.com> <20210804133529.GE4578@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210804133529.GE4578@quack2.suse.cz> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, Aug 04, 2021 at 03:35:29PM +0200, Jan Kara wrote: > On Wed 04-08-21 20:50:44, yangerkun wrote: > > Our testcase(briefly described as fsstress on dm thin-provisioning which > > ext4 see volume size with 100G but actual size 10G) trigger a hungtask > > bug since ext4_writepages fall into a infinite loop: > > > > Got ENOSPC with follow stack: > > ... > > ext4_ext_map_blocks > > ext4_ext_convert_to_initialized > > ext4_ext_zeroout > > ext4_issue_zeroout > > ... > > submit_bio_wait <-- bio to thinpool will return ENOSPC > > > > Thanks for the patch. As a quick fix for the problem this is probably fine. > But longer term we might need to implement a configurable behavior for this > because just dropping data on the floor (which is what would happen here) > need not be what sysadmin wants and blocking until space is provisioned may be > actually a preferable behavior. Anyway for now feel free to add: > > Reviewed-by: Jan Kara Hmm, I wonder if this would be a better fix. (Not yet tested, may fry your file system, etc....) What do folks think? - Ted 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)