Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1680255pxj; Wed, 19 May 2021 11:18:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3yam2ZuKCAucuReKr1WQPhNV2BgvHRqAR9Bw+bSm0ViK1Th1mMB5MBaFnqRFU3AB5jEEA X-Received: by 2002:a05:6402:2789:: with SMTP id b9mr397562ede.122.1621448312626; Wed, 19 May 2021 11:18:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621448312; cv=none; d=google.com; s=arc-20160816; b=cLhijRA2T/eoJqyRJDG2OUd7O/RXs+MfK4lSqJfIJG+FGOqiBk8dN/5sxnFPHhzPP4 MzBbtg7swTV7QpS8OBDlns6Y6dCn9g6Nj3LOyTObdO4zXHfVTdY0IE+VmLPmHU87Ord/ KmupEAD4EIsTHCCW7simfitnOdbqxhthplk0SPz7Z7apMSVY0Xzkmwb5A8B+HmQNWOo+ FnlKotChBLEtvxVOK+rczCMK/hGmU3geY2MR7d5YfjBEBSYxBPSeNQthUw6QXRhOhp32 uNdwQn/dRbmXFUduChfcMDJANGFsUa/uVHemrzMjRmMaAYqb5UN+BuUhZ27qgwpHh8SV CrJg== 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=7fPyGIk1AXjSH7d862yedxUF93u+eT4Q583rZJoCTTs=; b=mSY1iALUtOk/+2YwIV1IWIE1VpBEU7EUQBiiiX3H8Ux/d15Bbb6oiTDe+o00jhPLwU 3edFxiRr1BN1/OWAJmQ0fZB8Vrl5/42uQvbl6X49xses1zuTJR+kqU1XMw45PX1+YbpR l0N3GWv1EaPXMTDOrDTb+bLPmHNa2eBMcU3KhCZ6Lvg2xagVFrTGYO2YmlPZtvp7mE5p 6ZjjsIpqvQDeAw+WCYXdFGGIOM3yMU3rMzDmysASgrdkxs0SuDP5wFUeSVyuZPKj4ncN hrO1pr1TDQ5LhLNbogItuEsmkqwQL98sSf7dWzJR2VPhBF8XpCCIhcF6YDD5SB4VXpiG awDg== 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 w26si84215edl.479.2021.05.19.11.17.52; Wed, 19 May 2021 11:18:32 -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 S245033AbhERO7Q (ORCPT + 99 others); Tue, 18 May 2021 10:59:16 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:46697 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1344163AbhERO7K (ORCPT ); Tue, 18 May 2021 10:59:10 -0400 Received: from callcc.thunk.org (c-73-8-226-230.hsd1.il.comcast.net [73.8.226.230]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14IEvinR005090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 May 2021 10:57:46 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 2C8E6420119; Tue, 18 May 2021 10:57:44 -0400 (EDT) Date: Tue, 18 May 2021 10:57:44 -0400 From: "Theodore Y. Ts'o" To: Wang Jianchao Cc: Andreas Dilger , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ext4: get discard out of jbd2 commit kthread Message-ID: References: <53146e54-af36-0c32-cad8-433460461237@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, May 18, 2021 at 09:19:13AM +0800, Wang Jianchao wrote: > > That way we don't need to move all of this to a kworker context. > > The submit_bio also needs to be out of jbd2 commit kthread as it may be > blocked due to blk-wbt or no enough request tag. ;) Actually, there's a bigger deal that I hadn't realized, about why we is why are currently using submit_bio_wait(). We *must* wait until discard has completed before we call ext4_free_data_in_buddy(), which is what allows those blocks to be reused by the block allocator. If the discard happens after we reallocate the block, there is a good chance that we will end up corrupting a data or metadata block, leading to user data loss. There's another corollary to this; if you use blk-wbt, and you are doing lots of deletes, and we move this all to a writeback thread, this *significantly* increases the chance that the user will see ENOSPC errors in the case where they are with a very full (close to 100% used) file system. I'd argue that this is a *really* good reason why using mount -o discard is Just A Bad Idea if you are running with blk-wbt. If discards are slow, using fstrim is a much better choice. It's also the case that for most SSD's and workloads, doing frequent discards doesn't actually help that much. The write endurance of the device is not compromised that much if you only run fs-trim and discard unused blocks once a day, or even once a week --- I only recommend use of mount -o discard in cases where the discard operation is effectively free. (e.g., in cases where the FTL is implemented on the Host OS, or you are running with super-fast flash which is PCIe or NVMe attached.) Cheers, - Ted