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 A9BE9CCA47C for ; Wed, 29 Jun 2022 08:40:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232113AbiF2IkQ (ORCPT ); Wed, 29 Jun 2022 04:40:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229573AbiF2IkM (ORCPT ); Wed, 29 Jun 2022 04:40:12 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 023053BBC8; Wed, 29 Jun 2022 01:40:12 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id 1360F67373; Wed, 29 Jun 2022 10:40:09 +0200 (CEST) Date: Wed, 29 Jun 2022 10:40:08 +0200 From: Christoph Hellwig To: Qu Wenruo Cc: Chris Mason , Christoph Hellwig , Jan Kara , josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] btrfs: remove btrfs_writepage_cow_fixup Message-ID: <20220629084008.GA25536@lst.de> References: <20220624122334.80603-1-hch@lst.de> <7c30b6a4-e628-baea-be83-6557750f995a@gmx.com> <20220624125118.GA789@lst.de> <20220624130750.cu26nnm6hjrru4zd@quack3.lan> <20220625091143.GA23118@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) Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Wed, Jun 29, 2022 at 09:20:59AM +0800, Qu Wenruo wrote: > In fact, COW is not that special, even before btrfs or all the other > fses supporting COW, all those old fses has to do something like COW, > when they are writing into holes. > > What makes btrfs special is its csum, and in fact csum requires more > stable page status. > > If someone can modify a page without waiting for its writeback to > finish, btrfs csum can easily be stale and cause -EIO for future read. And the writepage time fixup does not help with this at all, as it just allocates the ordered extent at writepage time, long after the data has been modified.