From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 700F7C77B61 for ; Mon, 1 May 2023 04:47:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0FB3900003; Mon, 1 May 2023 00:47:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9BE53900002; Mon, 1 May 2023 00:47:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8ACFE900003; Mon, 1 May 2023 00:47:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 78714900002 for ; Mon, 1 May 2023 00:47:51 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 43F66A0676 for ; Mon, 1 May 2023 04:47:51 +0000 (UTC) X-FDA: 80740453542.29.C9BE53E Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf10.hostedemail.com (Postfix) with ESMTP id 6E8BAC0014 for ; Mon, 1 May 2023 04:47:49 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; spf=none (imf10.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682916469; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XygpNDNEzFf/uqkXQgGAo8EqHQm7l4KRXtbBKrAsVFs=; b=ngxwTG+v+eRyXCpW1CoOW0E7Hm3TNZ4NJFIy3nBVGYJYvZL/9zMSJqvJzb9UuhdUx3QBDl QP0WGGgDm/xC6yeZxZ3Oefzf29pe5biCbVpmEKYGEHYNWI7rp5wxi7UKz7FX6ZmubtNQjL hpm1yYKsSNr8zZtQX/pua4pSXYbOxKM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; spf=none (imf10.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682916469; a=rsa-sha256; cv=none; b=32qIAZc5UqqqKyrwR3FK8wUJ00lHcbviXlTMq8lTrH7c/6FTlgni1UkPK16WvR9txShhMW s95VGXbJ1A2SQJxGaR/VxWbONGBNBxnZpBCpCCldvZNnzYf/rGQ3D+CfCoHc8fh2uKXxaD bxx+AtBaCtyOHkguvMIjJyDeacexzrU= Received: by verein.lst.de (Postfix, from userid 2407) id D5EBC68B05; Mon, 1 May 2023 06:47:44 +0200 (CEST) Date: Mon, 1 May 2023 06:47:44 +0200 From: Christoph Hellwig To: Ming Lei Cc: Christoph Hellwig , Theodore Ts'o , Baokun Li , Matthew Wilcox , linux-ext4@vger.kernel.org, Andreas Dilger , linux-block@vger.kernel.org, Andrew Morton , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Dave Chinner , Eric Sandeen , Zhang Yi , yangerkun Subject: Re: [ext4 io hang] buffered write io hang in balance_dirty_pages Message-ID: <20230501044744.GA20056@lst.de> References: <663b10eb-4b61-c445-c07c-90c99f629c74@huawei.com> <20230429044038.GA7561@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 84bcapw7nb3574oudw19h844iaw3cjhd X-Rspamd-Queue-Id: 6E8BAC0014 X-HE-Tag: 1682916469-987437 X-HE-Meta: U2FsdGVkX197Opnd36IpoquTYGBdbySrDDH/Zsa8iWmY8WEvyjXAI86sBDI5Z7QGTT3U6kn+DoerSwsG9sBLr8uNGALxk3Nh/QJrSbV5QG+2IQ+au5q2HvKEjRNSpmlnkCZC7sAr5kofyLigeuuR7zj2jBeqDPB81dtoqVlVf53wALm3iBk3XetmhJCzC4kMZjZEjaLgipZBCXygJ0lq/vBG6PqGJlAhsrcgN3WsN1ekIvrOLXHpK5Y6raf6ImYMFPhgjAOx46551YX/lFmB4stZeLuNf8STbWY3Pg0ifz1md+h+j3Sx/ByDw5xVRDzNrGp6XYJTmVsSG3vC2dE/yvYACtdGxXSO0x0l7PVrPEM05vIJ5LeMX08XjDOn5ts103zB+XPpi8xsTQ/75Zn+3NmnUAtLmBwOISDKUMo3qlevmXiDQe64oeswjlUIq+2EfAI4CdroNfnu9pCdkNp3yYMELJauv1M/b8Uv/NVtc8tJ1eFsW9kcluQ/8BiEVPvvWySlmQGqEoXsAS3TZ9aC/RMqdSVGCPQSw4N9B9Az0HRDMOFI8TPgIVxDThW+EpHkghh1TFFKs06I96mqohq8afWx3FZVD9FQEHfns/Uci2R4Fw5c0VFA92d+TikH3YJxRGtt/2AwrrlOsjaEcYumqxHM3rqlU9sQ4vfrRJWKOjttVdsd7K9zlesTOy8VQh5VxmKyBg7uX+PMdGlaIr7RmfKMvSzdBzok5MRGgspxBV1+oSt9FufedGo5E5jk5HwFK4v0U1hLgc8ouZ+wumouZOelCVROvxuYIAMCgGHr/UiWGzEzzQNk8UJFT+j5aAjnf7w4hX/d76h5licFN18+uzfnDILuqfv4R6iXn+YaoNE7AVosnAo7DpeumLf4bMV+aqL6zLWj2cqxEwPjOTwD3KiA9wSRlN9IpbMLwnknFKDej++78MGPrYOX+0lFbAhTRXFI0UGUUrNJvT7cCTY i7awBVEO HOklgmOA7rVCLOwYRq2Lml5Bjz+cb82s56Oa/7u5lkysiTy5spphGO+6KVLxV+JgM+XiBqA2dTUU+KHHdGBNINo7Lle7DbiY4S80AojcstU6i9uc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Apr 29, 2023 at 01:10:49PM +0800, Ming Lei wrote: > Not sure if it is needed for non s_bdev So you don't want to work this at all for btrfs? Or the XFS log device, or .. > , because FS is over stackable device > directly. Stackable device has its own logic for handling underlying disks dead > or deleted, then decide if its own disk needs to be deleted, such as, it is > fine for raid1 to work from user viewpoint if one underlying disk is deleted. We still need to propagate the even that device has been removed upwards. Right now some file systems (especially XFS) are good at just propagating it from an I/O error. And explicity call would be much better.