Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3741082pxk; Tue, 29 Sep 2020 05:15:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyrafwgHj1z2ZT9ZJMukNHgHlIbeE/bFlcEwZyDgZaAMZh03PsjE1ROEPGw9x/VVvGU9hRx X-Received: by 2002:a50:fa81:: with SMTP id w1mr2855900edr.122.1601381723422; Tue, 29 Sep 2020 05:15:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601381723; cv=none; d=google.com; s=arc-20160816; b=dbpMn/hPAA6R7QebUmbZiLVeOso+HQRedcRdC7BM9L4vdodmvDJFxry8HpsvWM4DaE 5Gkf14BESFM4bAun8+rTyfFURvW51Vp+Gcu6PgQgRJ4M7ARKgUKk6R6IGWm2020rNuKm 4RwGXq+QNV3ummNBH7D0bRXd4IiGbdxyL0dyDjaUJ3al7Vhv2TDUgRUPAoK3u80qCszk qLNq4TJQZlGs5KPTNjiLGAarmGCyM5knqCCaRZESnw39UtZ5MRoSiHN7PEIt41yYYbq2 SynwpCFwQSoLi2gRJDiJR2CB9BVyt25MLmVB2tbg22AUwnGngVOxogkDJtPM8rkEpXS4 0oRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=bWFKZPPYD3oUnPS3uswhctCS4EKWrVyL8D5+jelEdpc=; b=Y5imF9WXDca0d6fccxDo9t0YiHvo3pZ6BIY447huYt50Myhn/+oBuFt7p3oC+WPp8i fLUbU+Xaw+W331yfnqAwadY/0/cJJFGyis6jfHpcIma0qrIGrkZmBsUSlOi9JpUfHQhe g/sHwNVVLtd1N9QezFrJkfjtAVY0uMrNbY0bNO9f/Ie3B+p9WXXEVRpKIReL9IOnoITd BfBnM25x7vliw8Z6SulWR1YVO0WP42d6/OQxacesCxDx/NsuIi06zIELmbyin03EYNGq REdYfkKhW6ieZotEcRSoUzb9bA/yMxEKBNuAJ1jWEB4JNj9hjQ1pW8A1xqqOQHfGcRee 4Amw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n23si2604169edv.598.2020.09.29.05.14.58; Tue, 29 Sep 2020 05:15:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732066AbgI2MNq (ORCPT + 99 others); Tue, 29 Sep 2020 08:13:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:46496 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730095AbgI2Lh3 (ORCPT ); Tue, 29 Sep 2020 07:37:29 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 71063B208; Tue, 29 Sep 2020 11:37:27 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 238411E12E9; Tue, 29 Sep 2020 13:37:27 +0200 (CEST) Date: Tue, 29 Sep 2020 13:37:27 +0200 From: Jan Kara To: Mauricio Faria de Oliveira Cc: Jan Kara , linux-ext4@vger.kernel.org, dann frazier Subject: Re: [RFC PATCH v4 0/4] ext4/jbd2: data=journal: write-protect pages on transaction commit Message-ID: <20200929113727.GK10896@quack2.suse.cz> References: <20200928194103.244692-1-mfo@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200928194103.244692-1-mfo@canonical.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Mon 28-09-20 16:40:59, Mauricio Faria de Oliveira wrote: > Hey Jan, > > This series implements your suggestions for the RFC PATCH v3 set [1]. > > That addressed the issue you confirmed with block_page_mkwrite() [2]. > There's no "JBD2: Spotted dirty metadata buffer" message in over 72h > runs across 3 VMs (it used to happen within a few hours.) *Thanks!* > > I added Reviewed-by: tags for the patches/changes you mentioned. > The only changes from v3 are patch 3 which is new, and contains > the 2 fixes to ext4_page_mkwrite(); and patch 4 changed 'struct > writeback_control.nr_to_write' from ~0ULL to LONG_MAX, since it > is signed long (~0ULL overflows to -1; kudos, kernel test robot!) > > It looks almost good on fstests: zero regressions on data=ordered, > and two apparently flaky tests data=journal (generic/347 _passed_ > 1/6 times with the patch, and generic/547 failed 1/6 times.) Cool. Neither of these tests has anything to do with mmap. The first test checks what happens when thin provisioned storage runs out of space (and that fs remains consistent), the second tests that fsync flushed properly all data and that it can be seen after a crash. So I'm reasonably confident that it isn't caused by your patches. It still might be a bug in data=journal implementation though but that would be something for another patch series :). I'll have a look at the remaining patches. Honza -- Jan Kara SUSE Labs, CR