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 F2D67C6FD1D for ; Mon, 20 Mar 2023 06:26:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229842AbjCTG0F (ORCPT ); Mon, 20 Mar 2023 02:26:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229561AbjCTG0A (ORCPT ); Mon, 20 Mar 2023 02:26:00 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4336A191; Sun, 19 Mar 2023 23:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=owX/GSJ4ipiXhQOajVZWX1Me7Jms4t/oUWhAspmudyg=; b=wjYHwQ9oHIg64n/tU2CYNDk1Zf B7bfkHy204YrNVySBez8BG/2dfzFH5r6/tx2z+ZyH9qgRXPnzwwzz5slmLmD+56B5gQSsKcFdJMNz u9yCBHsn9cVyVcvrJXRPGNdKt6xqXgR4QOU1CGBvZr8wAIRU4AjgMOYOoJJ7JFtfLmOphcYmx4kNv IK8in1/PGXd2cMnRo00ioul6fHeaN1ue/xkapaWcuzGnbsXxEcNOiiBi4Qy6CFvqaQCMnmN1hr53s 2BFsh3wXFDXB+INaPNuKMWcyXbUCtilRXMMwzKnK+B5Fb3GIg0oQ2pyDJ9wxxf8+1f0hqiatc/hQv AU+xDsOQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1pe8xx-008E9B-0g; Mon, 20 Mar 2023 06:25:57 +0000 Date: Sun, 19 Mar 2023 23:25:57 -0700 From: Christoph Hellwig To: Adrian Hunter Cc: Christoph Hellwig , Ulf Hansson , linux-mmc@vger.kernel.org, Wenchao Chen , Avri Altman , Christian Lohle , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, Bean Huo Subject: Re: [PATCH] mmc: core: Allow to avoid REQ_FUA if the eMMC supports an internal cache Message-ID: References: <20230316164514.1615169-1-ulf.hansson@linaro.org> <522a5d01-e939-278a-3354-1bbfb1bd6557@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <522a5d01-e939-278a-3354-1bbfb1bd6557@intel.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 16, 2023 at 09:12:35PM +0200, Adrian Hunter wrote: > Historically file systems have assumed that sectors are updated > atomically i.e. there is never a sector with a mixture of > old and new data. Yes. Not just file systems, but also all kinds of applications. > The eMMC spec does not guarantee that, > except for the eMMC "reliable write" operation. Neither to ATA or SCSI, but applications and file systems always very much expected it, so withou it storage devices would be considered fault. Only NVMe actually finally made it part of the standard. > So the paragraph > above is informing the potential benefit of reliable write instead > of cache flush. But these are completely separate issue. Torn writes are completely unrelated to cache flushes. You can indeed work around torn writes by checksums, but not the lack of cache flushes or vice versa. > Note, it is not that eMMC cannot avoid torn sectors, it is that > the specification does not mandate that they do. If devices tear writes it will break not only various file systems, but more importantly applications, at least on file systems without data checksum (aka all except for btrfs, and even that has a nodatacsum option). > However, the issue has been raised that reliable write is not > needed to provide sufficient assurance of data integrity, and that > in fact, cache flush can be used instead and perform better. It does not.