Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp5920721ybv; Wed, 12 Feb 2020 02:46:17 -0800 (PST) X-Google-Smtp-Source: APXvYqwdgQOwuAEnf32rX4BNCAptpJSuuvDpZvWlq5I+J/TY8oM8ybj5Azz4VdIBJXPhI3sLyBmX X-Received: by 2002:a9d:2dea:: with SMTP id g97mr8825674otb.33.1581504377505; Wed, 12 Feb 2020 02:46:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581504377; cv=none; d=google.com; s=arc-20160816; b=ReDPdFgtyfxEMkCpWkxuF1ziNgpb5rbQGjCeGGL8c17kCOI2ZHPP2iYEwMxNwzDQmt rtxp3tDFPCbS1UJy6LKpyd98FjCKBrTdMG1nHTqHMZnkl/zADEaZU55LXSZiUGY8g2/3 HD01Jzx5ROVJVM12jSCLjlDRpRMvw4hajrkJgemplp0UUZ1BdcVOv1K3oS6/GMPHrvTZ R0IXUaZ2r76Mfddy0gtJGD35AIRS2AJbLgaxEV+74tZR5hALhc8WvZ9H5eSI32D7UcoT 31KCCH9ghr+gZi6JGAK6cipOD9STJdj0fhjJdXGZm0h1wHdttoqHP989CBDyOOVqDSRu KkzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=I2lkCNxcBoMTtLkieIUtBjsn1tM5/md2+dxYl2dN3cQ=; b=XvcUJSnSynTjeIeZ0PkwRuRfwFt5v8ahd6Pgrpbnho4g691WkN7dzuT/kvoVDeaMnf qpEhZzX5p87KW2Le3DTfrili4jgL6MPgWSNuYVYW/4eoGEGiTY7Xv3wawaM50wA/t6Zb dICjwtRUHfWhaZd/sE+sXrCf6lUFvKnm46kgt5GUDzEe0EywIGnewn4n6HN6WQdYkHRT PNcnMvHHwUNX0MEsix7NsVmcIYOGl4t1S7ZqwozlBBThRHZi9GxmkMJYGbqqTnDCLh8D +4QzA0AOt4Ijf4WLU6iVCKMhT3ucxzoCBCPrra6GrGq2LAtjyj7bnlXk2xz70z/ZSm5m E5lQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o20si35924otl.60.2020.02.12.02.45.56; Wed, 12 Feb 2020 02:46:17 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727933AbgBLKpz (ORCPT + 99 others); Wed, 12 Feb 2020 05:45:55 -0500 Received: from mx2.suse.de ([195.135.220.15]:60818 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727535AbgBLKpz (ORCPT ); Wed, 12 Feb 2020 05:45:55 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 6B181ADC8; Wed, 12 Feb 2020 10:45:52 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 551D01E0E01; Wed, 12 Feb 2020 11:45:51 +0100 (CET) Date: Wed, 12 Feb 2020 11:45:51 +0100 From: Jan Kara To: "zhangyi (F)" Cc: linux-ext4@vger.kernel.org, jack@suse.cz, tytso@mit.edu, luoshijie1@huawei.com, zhangxiaoxu5@huawei.com Subject: Re: [PATCH v2 1/2] jbd2: move the clearing of b_modified flag to the journal_unmap_buffer() Message-ID: <20200212104551.GF25573@quack2.suse.cz> References: <20200211135500.40524-1-yi.zhang@huawei.com> <20200211135500.40524-2-yi.zhang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200211135500.40524-2-yi.zhang@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue 11-02-20 21:54:59, zhangyi (F) wrote: > There is no need to delay the clearing of b_modified flag to the > transaction committing time when unmapping the journalled buffer, so > just move it to the journal_unmap_buffer(). > > Signed-off-by: zhangyi (F) The patch looks good to me. You can add: Reviewed-by: Jan Kara Honza > --- > fs/jbd2/commit.c | 43 +++++++++++++++---------------------------- > fs/jbd2/transaction.c | 10 ++++++---- > 2 files changed, 21 insertions(+), 32 deletions(-) > > diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c > index 7f0b362b3842..ecc2ea5f1b59 100644 > --- a/fs/jbd2/commit.c > +++ b/fs/jbd2/commit.c > @@ -976,34 +976,21 @@ void jbd2_journal_commit_transaction(journal_t *journal) > * it. */ > > /* > - * A buffer which has been freed while still being journaled by > - * a previous transaction. > - */ > - if (buffer_freed(bh)) { > - /* > - * If the running transaction is the one containing > - * "add to orphan" operation (b_next_transaction != > - * NULL), we have to wait for that transaction to > - * commit before we can really get rid of the buffer. > - * So just clear b_modified to not confuse transaction > - * credit accounting and refile the buffer to > - * BJ_Forget of the running transaction. If the just > - * committed transaction contains "add to orphan" > - * operation, we can completely invalidate the buffer > - * now. We are rather through in that since the > - * buffer may be still accessible when blocksize < > - * pagesize and it is attached to the last partial > - * page. > - */ > - jh->b_modified = 0; > - if (!jh->b_next_transaction) { > - clear_buffer_freed(bh); > - clear_buffer_jbddirty(bh); > - clear_buffer_mapped(bh); > - clear_buffer_new(bh); > - clear_buffer_req(bh); > - bh->b_bdev = NULL; > - } > + * A buffer which has been freed while still being journaled > + * by a previous transaction, refile the buffer to BJ_Forget of > + * the running transaction. If the just committed transaction > + * contains "add to orphan" operation, we can completely > + * invalidate the buffer now. We are rather through in that > + * since the buffer may be still accessible when blocksize < > + * pagesize and it is attached to the last partial page. > + */ > + if (buffer_freed(bh) && !jh->b_next_transaction) { > + clear_buffer_freed(bh); > + clear_buffer_jbddirty(bh); > + clear_buffer_mapped(bh); > + clear_buffer_new(bh); > + clear_buffer_req(bh); > + bh->b_bdev = NULL; > } > > if (buffer_jbddirty(bh)) { > diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c > index 27b9f9dee434..0603dfa9ad90 100644 > --- a/fs/jbd2/transaction.c > +++ b/fs/jbd2/transaction.c > @@ -2329,14 +2329,16 @@ static int journal_unmap_buffer(journal_t *journal, struct buffer_head *bh, > return -EBUSY; > } > /* > - * OK, buffer won't be reachable after truncate. We just set > - * j_next_transaction to the running transaction (if there is > - * one) and mark buffer as freed so that commit code knows it > - * should clear dirty bits when it is done with the buffer. > + * OK, buffer won't be reachable after truncate. We just clear > + * b_modified to not confuse transaction credit accounting, and > + * set j_next_transaction to the running transaction (if there > + * is one) and mark buffer as freed so that commit code knows > + * it should clear dirty bits when it is done with the buffer. > */ > set_buffer_freed(bh); > if (journal->j_running_transaction && buffer_jbddirty(bh)) > jh->b_next_transaction = journal->j_running_transaction; > + jh->b_modified = 0; > spin_unlock(&journal->j_list_lock); > spin_unlock(&jh->b_state_lock); > write_unlock(&journal->j_state_lock); > -- > 2.17.2 > -- Jan Kara SUSE Labs, CR