Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp635570rwb; Wed, 16 Nov 2022 05:52:05 -0800 (PST) X-Google-Smtp-Source: AA0mqf7QnmMc6ToRjA+gKz/qs+d9V/VSzzFDfZ6R14hqObOV+UiIwoG7qY8+hOTsztyRNAJhJdG+ X-Received: by 2002:a17:907:674b:b0:7a2:b352:a0d3 with SMTP id qm11-20020a170907674b00b007a2b352a0d3mr17438847ejc.399.1668606724790; Wed, 16 Nov 2022 05:52:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668606724; cv=none; d=google.com; s=arc-20160816; b=qj7wIo1/wR7oS2hK9VvzQk0uMqTL+q+V7A6BC0VjIPpW57FnBe/0RCPBjt0gGs6V1I HOxmY+eNTZsLurePJEuPQJDynSI9sEiZEyo2imGwL9ow35S0OgKO/0UIOFjxjNjafeNO kFzXRMbY/Go1xxGjPSoJyiDJLF6zhA9Xbb4le+5G64m8BX08AoaFzdNA9uCaRUkrTiHH l9aTTAAhsXDcMs9SJvrp5HiERbYPuOw8pzfXxvRV2Z4U3HPeyMMni8tGBt1riTUcJ7+T nAMPvNfsCSY5UZbXkLAIf7QOKloeEfQedoQ3t6g3qI+VPmUmnJGFdSp8sB0ikSTjzMW/ SRbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:content-disposition:mime-version :message-id:subject:cc:to:from:date; bh=I58ePTtRZaKKm++mQe8kpborp6qhIyVl3mb3ixOsGcA=; b=dBgsuhKzYa2PnA80ELL/IvdV3emJ3S7LEEb68jjJdTTGq8bzr55kwRJIUzlYt0FEMt nGluLVDkxa9w1zdaprETMJ/ptcktnHU5yAVh4zlpnyPOjWKZdqt71e5Pt9ynxNgXhyD1 WlVS+yNoBh0Kpc+jVUqIW77y6+o7TqALd9nrzvyLh0YoHPu+KtnsYY9WlIH9D6h5Ygjy kdonhH+u4lAz3RnkTKp8yCZzNbfZekfzmH6PA3QEwQRzXcdZRB8IP4TORdo6iNxMpbCH VsPWzr1GOpm96i44Yus6UEB0IiyaxwZuXX0EvQ1PDG3XyDj+EbPAsdUT2vzgmqYg3rXF YFWQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gn1-20020a1709070d0100b0078a3ef9f092si15665099ejc.998.2022.11.16.05.51.37; Wed, 16 Nov 2022 05:52:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229942AbiKPNuY (ORCPT + 99 others); Wed, 16 Nov 2022 08:50:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232575AbiKPNuX (ORCPT ); Wed, 16 Nov 2022 08:50:23 -0500 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B15FBF7D; Wed, 16 Nov 2022 05:50:21 -0800 (PST) Received: by verein.lst.de (Postfix, from userid 2407) id 1C0E468AA6; Wed, 16 Nov 2022 14:50:17 +0100 (CET) Date: Wed, 16 Nov 2022 14:50:16 +0100 From: Christoph Hellwig To: Theodore Ts'o , Jan Kara , "Aneesh Kumar K.V" , Mingming Cao Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, ocfs2-devel@oss.oracle.com, linux-mm@kvack.org Subject: generic_writepages & jbd2 and ext4 Message-ID: <20221116135016.GA9713@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hi all, I've recently started looking into killing off the ->writepage method, and as an initial subproject kill of external uses of generic_writepages. One of the two remaining callers s in jbd2 and I'm a bit confused about it. jbd2_journal_submit_inode_data_buffers has two comments that explicitly ask for ->writepages as that doesn't allocate data: /* * write the filemap data using writepage() address_space_operations. * We don't do block allocation here even for delalloc. We don't * use writepages() because with delayed allocation we may be doing * block allocation in writepages(). */ /* * submit the inode data buffers. We use writepage * instead of writepages. Because writepages can do * block allocation with delalloc. We need to write * only allocated blocks here. */ and these look really stange to me. ->writepage and ->writepages per their document VM/VFS semantics don't different on what they allocate, so this seems to reverse engineer ext4 internal behavior in some way. Either way looping over ->writepage just for that is rather inefficient. If jbd2 really wants a way to skip delalloc conversion can we come up with a flag in struct writeback_control for that? Is there anyone familiar enough with this code who would be willing to give it a try?