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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C321AC6FD1D for ; Tue, 4 Apr 2023 16:20:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235350AbjDDQUd (ORCPT ); Tue, 4 Apr 2023 12:20:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234131AbjDDQUc (ORCPT ); Tue, 4 Apr 2023 12:20:32 -0400 Received: from len.romanrm.net (len.romanrm.net [IPv6:2001:41d0:1:8b3b::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 650BD40F1 for ; Tue, 4 Apr 2023 09:20:31 -0700 (PDT) Received: from nvm (nvm.home.romanrm.net [IPv6:fd39::101]) by len.romanrm.net (Postfix) with SMTP id 33FCF40220; Tue, 4 Apr 2023 16:20:28 +0000 (UTC) Date: Tue, 4 Apr 2023 21:20:27 +0500 From: Roman Mamedov To: Christoph Hellwig Cc: Linux regressions mailing list , Sergei Trofimovich , Josef Bacik , Christopher Price , anand.jain@oracle.com, boris@bur.io, clm@fb.com, dsterba@suse.com, linux-btrfs@vger.kernel.org Subject: Re: [6.2 regression][bisected]discard storm on idle since v6.1-rc8-59-g63a7cb130718 discard=async Message-ID: <20230404212027.3730905d@nvm> In-Reply-To: References: <20230323222606.20d10de2@nz> <20d85dc4-b6c2-dac1-fdc6-94e44b43692a@leemhuis.info> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Tue, 4 Apr 2023 09:04:03 -0700 Christoph Hellwig wrote: > > I also heard people saying these discard storms might reduce the life > > time of some devices - is that true? > > Also very much possible. There are various SSDs that treat a discard > as a write zeroes and always return zeroes from all discarded blocks. > If the discards are smaller than or not aligned to the internal erase > (super)blocks, this will actually cause additional writes. SSDs do not physically erase blocks on discard, that would be very slow. Instead they nuke corresponding records in the Flash translation layer (FTL) tables, so that the discarded areas point "nowhere" instead of the actual stored blocks. And when facing such pointers on trying to resolve read requests, the controller knows to just return zeroes. Of course there can be varying behaviors per SSD, e.g. I know of some that return random garbage instead of zeroes, and some which for a puzzling reason prefer to return the byte FF instead. But I think the 1st point above should be universal, pretty certain there are none where a discard/TRIM would take comparable time to "dd if=/dev/zero of=/dev/ssd" (making it unusable in practice). -- With respect, Roman