Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1646229ybv; Thu, 6 Feb 2020 07:28:34 -0800 (PST) X-Google-Smtp-Source: APXvYqzvAmjl8GQTpI/8VP9rqwoY/yyLR/yf9XAXSjyRtddNkkSf9HVFTFaRFSHM3kRcSRGbJv0T X-Received: by 2002:a54:4e8d:: with SMTP id c13mr7231068oiy.27.1581002914165; Thu, 06 Feb 2020 07:28:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581002914; cv=none; d=google.com; s=arc-20160816; b=rBOXVzqyQ6aEPIeBcp6usSLxUwJ+fngj67fQOu5HsrVje3iuC+blwSOkdOWx6T4Urb 7J51OAl9wmJ2RmzcmKyv3kFga8NnD6LEtN9mbzRtBilVyJ6B5spFlmhFkF3bNmR37eWV +9fLhVKogtALlf0CQTaQs6w6fVunGUz6vwJdHoCLG0FZVBVI3nOcEUVXEkmsV0x/saWL m8MMnRocJcMhx0autpO1UJinFljU9U7721zn4bgOS54ooVh3+ksf4eNMjDgew99OznvU B2WG2EmIx0Ya4t/aJjFs1nZfaQvRBhN9AB/3QKo6NBxqhWR/4uwqxucK5wkNElC/f4vK MThA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=MnqFcJTE6AUiU1pbDpkma3l73nvdOiO9Xq2vVGunGFw=; b=XVCyhzpY24+QPCqQjujnTZ9Tpr7UyEReq1XeUgYe5+e6oBOVXFZqh+Z1IkGNeixWDp L3gJdQIEIIRvrnuZ5HfBjbOEGeZvZ2xX/+CaTXkY6Rr3uBozrkFRDIin1bcz4TdgoxQl KBNozAd2q1PnO48EfpBZOpXdo6Cqvgd1JkKRx2jIM+54O79jg1cCkCS5PCGlupqehb31 K4Gd8YQy0Rlzr7ddTSlSLAw32ld9gO+tmhnk9OosOh9exW16VU8YsCYJsaqhg7RE9a+3 IGqDSLRhmaNcClvq/N/PQwP0aqz+QQwB4l7SQh+RJa+1GGsxR7WBaVUdDjle9Y0cBTXh b5Gg== 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 s5si2003249otd.141.2020.02.06.07.28.17; Thu, 06 Feb 2020 07:28:34 -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 S1727398AbgBFP2P (ORCPT + 99 others); Thu, 6 Feb 2020 10:28:15 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:10164 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727325AbgBFP2P (ORCPT ); Thu, 6 Feb 2020 10:28:15 -0500 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id C940644224E036578578; Thu, 6 Feb 2020 23:28:09 +0800 (CST) Received: from [127.0.0.1] (10.173.220.179) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.439.0; Thu, 6 Feb 2020 23:28:01 +0800 Subject: Re: [PATCH 2/2] jbd2: do not clear the BH_Mapped flag when forgetting a metadata buffer To: Jan Kara CC: , , , References: <20200203140458.37397-1-yi.zhang@huawei.com> <20200203140458.37397-3-yi.zhang@huawei.com> <20200206114647.GB3994@quack2.suse.cz> From: "zhangyi (F)" Message-ID: <6c03b515-d128-06be-2e38-56a01ee63263@huawei.com> Date: Thu, 6 Feb 2020 23:28:01 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: <20200206114647.GB3994@quack2.suse.cz> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.173.220.179] X-CFilter-Loop: Reflected Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Thanks for the comments. On 2020/2/6 19:46, Jan Kara wrote: > On Mon 03-02-20 22:04:58, zhangyi (F) wrote: [..] >> diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c >> index 6396fe70085b..a649cdd1c5e5 100644 >> --- a/fs/jbd2/commit.c >> +++ b/fs/jbd2/commit.c >> @@ -987,10 +987,13 @@ void jbd2_journal_commit_transaction(journal_t *journal) >> 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_unmap(bh)) { >> + clear_buffer_unmap(bh); >> + clear_buffer_mapped(bh); >> + clear_buffer_new(bh); >> + clear_buffer_req(bh); >> + bh->b_bdev = NULL; >> + } > > Any reason why you don't want to clear buffer_req and buffer_new flags for > all buffers as well? I agree that b_bdev setting and buffer_mapped need > special treatment. > IIUC, for the buffer coming from jbd2_journal_forget() is always 'block device backed' metadata buffer (not pretty sure), and for these metadata buffer, buffer_new flag will not be set. At the same time, since it's always mapped, so it's fine to keep the buffer_req flag even it's freed by the filesystem now, because it means the block device has committed this buffer, and it seems that it does not affect we reuse this buffer. Am I missing something ? > Also rather than introducing this new buffer_unmap bit, I'd use the fact > this special treatment is needed only for buffers coming from the block device > mapping. And we can check for that like: > > /* > * We can (and need to) unmap buffer only for normal mappings. > * Block device buffers need to stay mapped all the time. > * We need to be careful about the check because the page > * mapping can get cleared under our hands. > */ > mapping = READ_ONCE(bh->b_page->mapping); > if (mapping && !sb_is_blkdev_sb(mapping->host->i_sb)) { > ... > } > It looks better, I will use this checking in the next iteration. > Longer term, we might want to rework how the handling of truncated buffers > works with JDB2. There's lots of duplication between jbd2_journal_forget() > and jbd2_journal_unmap_buffer(), the dirtiness is tracked in jh->b_modified > as well as buffer_jbddirty() and it is further redundant with the journal > list the buffer is currently on. So I suspect it could all be simplified if > we took a fresh look at things. > Indeed, it is tricky and not pretty easy to understand now, refactoring these is awesome int the future. Thanks, Yi.