Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1317487pxb; Thu, 7 Oct 2021 05:31:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwzvvG3C6C93oykCsnjVUhwnOEKwNHiN7S3mqUqTkTRk3OvQ0pe9+4A8o/lKVgl8UFAYgKs X-Received: by 2002:a17:906:9742:: with SMTP id o2mr5351598ejy.532.1633609896208; Thu, 07 Oct 2021 05:31:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633609896; cv=none; d=google.com; s=arc-20160816; b=EwuO9vymb6sTsSdSuOcqWtETvadUs9Sp0nnVy5+0Le0EBHpm4yFcp7oYk3cgR+U4AK BkJY28b9EAiJy/6rwxahcUmKFFdF3ZZTdTREBWTxjPxrPUFV0sYpnWAeEAh/6cjuAzu4 LldHMREhGT6Ks0lFUd8X+QLs1icD3BoUSL0koE/N+mvjJivWKwWQ5aU3HxCGfTEDq2zn SD1FBGaBBAJZNuP6b87G0hyJTtFke+E4JS0eirYYfXfCj1AcjxAd83Z7pnXq9FsaS3YV ag8/1hcAUVX2NsFuLD4q/bUSdGSylBC4bZ+SXkiIzxrh9AGGkGj9WEUyzhSe+GjmUUP8 W7cQ== 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 :dkim-signature:dkim-signature; bh=QqTBeTOLXh63TdbL8mtx0+7eTpit6RF97QgRBdN8vW0=; b=XKEJOBHXUIwVqjVEZy6kZMche1r2rKgGqQ1ojatD2b9NhFOOTF+snVivGQBGwkB9HV 73d88bh6X8t57Cvybka8wegmKzmV9fk/ZaAY+O8hBG78cmnk3CkbvqUjtEdy5t1frr5H +FnPgBfLEoTWc74mH5BmiANjmWoSL+YZ3MU4M3OKk78LSuUsEwI4t2szj3c7CFUlrwN4 sDtkEFHqMtVWcj2Y7wU503c/STcMDF50uFzUZZQtvyLYosfkjHAHjXB26CiD/f0Q5c7/ ITnYkzsESIpWEcciXfn4gvlatg7nm3niVtVPziRmtz6RWsuX6NJ59ydCfH+o3SygnpIH 2cIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=TYcZyGM6; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=wy3U7YQm; 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 b16si19473842eja.239.2021.10.07.05.31.09; Thu, 07 Oct 2021 05:31:36 -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; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=TYcZyGM6; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=wy3U7YQm; 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 S241308AbhJGMcz (ORCPT + 99 others); Thu, 7 Oct 2021 08:32:55 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:59378 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241261AbhJGMcz (ORCPT ); Thu, 7 Oct 2021 08:32:55 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 89AFC224B8; Thu, 7 Oct 2021 12:31:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1633609860; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QqTBeTOLXh63TdbL8mtx0+7eTpit6RF97QgRBdN8vW0=; b=TYcZyGM6Ri1W/rO+n037uidWhkcJU2ItEow+bpzHwW0KbQGPBoDo2kz6enohP2dTOtJa0O knwFRdyXCWHhnMLYA0W0e22AGm558SSMBfbumeCnjdaf3jxc/YUExLw/9oB3msV9k3OF3S N1HRgOz6ysvATX2MsqElT2g62rnrtYI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1633609860; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QqTBeTOLXh63TdbL8mtx0+7eTpit6RF97QgRBdN8vW0=; b=wy3U7YQmfuke6i/OE5U17gI8qoAbb9s9gYkHwOBnwiycVPVYAgGpUhplk0zbVFLJgZxXZ9 z7J+2e82lRt3L4CA== Received: from quack2.suse.cz (unknown [10.100.224.230]) by relay2.suse.de (Postfix) with ESMTP id 78BA0A3B83; Thu, 7 Oct 2021 12:31:00 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 5FBC11F2C96; Thu, 7 Oct 2021 14:31:00 +0200 (CEST) Date: Thu, 7 Oct 2021 14:31:00 +0200 From: Jan Kara To: Ye Bin Cc: tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, jack@suse.cz Subject: Re: [PATCH -next v2 2/6] ext4: introduce last_check_time record previous check time Message-ID: <20211007123100.GG12712@quack2.suse.cz> References: <20210911090059.1876456-1-yebin10@huawei.com> <20210911090059.1876456-3-yebin10@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210911090059.1876456-3-yebin10@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Sat 11-09-21 17:00:55, Ye Bin wrote: > kmmpd: > ... > diff = jiffies - last_update_time; > if (diff > mmp_check_interval * HZ) { > ... > As "mmp_check_interval = 2 * mmp_update_interval", 'diff' always little > than 'mmp_update_interval', so there will never trigger detection. > Introduce last_check_time record previous check time. > > Signed-off-by: Ye Bin I think the check is there only for the case where write_mmp_block() + sleep took longer than mmp_check_interval. I agree that should rarely happen but on a really busy system it is possible and in that case we would miss updating mmp block for too long and so another node could have started using the filesystem. I actually don't see a reason why kmmpd should be checking the block each mmp_check_interval as you do - mmp_check_interval is just for ext4_multi_mount_protect() to know how long it should wait before considering mmp block stale... Am I missing something? Honza > --- > fs/ext4/mmp.c | 14 +++++++++----- > 1 file changed, 9 insertions(+), 5 deletions(-) > > diff --git a/fs/ext4/mmp.c b/fs/ext4/mmp.c > index 12af6dc8457b..c781b09a78c9 100644 > --- a/fs/ext4/mmp.c > +++ b/fs/ext4/mmp.c > @@ -152,6 +152,7 @@ static int kmmpd(void *data) > int mmp_update_interval = le16_to_cpu(es->s_mmp_update_interval); > unsigned mmp_check_interval; > unsigned long last_update_time; > + unsigned long last_check_time; > unsigned long diff; > int retval = 0; > > @@ -170,6 +171,7 @@ static int kmmpd(void *data) > > memcpy(mmp->mmp_nodename, init_utsname()->nodename, > sizeof(mmp->mmp_nodename)); > + last_check_time = jiffies; > > while (!kthread_should_stop() && !sb_rdonly(sb)) { > if (!ext4_has_feature_mmp(sb)) { > @@ -198,17 +200,18 @@ static int kmmpd(void *data) > } > > diff = jiffies - last_update_time; > - if (diff < mmp_update_interval * HZ) > + if (diff < mmp_update_interval * HZ) { > schedule_timeout_interruptible(mmp_update_interval * > HZ - diff); > + diff = jiffies - last_update_time; > + } > > /* > * We need to make sure that more than mmp_check_interval > - * seconds have not passed since writing. If that has happened > - * we need to check if the MMP block is as we left it. > + * seconds have not passed since check. If that has happened > + * we need to check if the MMP block is as we write it. > */ > - diff = jiffies - last_update_time; > - if (diff > mmp_check_interval * HZ) { > + if (jiffies - last_check_time > mmp_check_interval * HZ) { > struct buffer_head *bh_check = NULL; > struct mmp_struct *mmp_check; > > @@ -234,6 +237,7 @@ static int kmmpd(void *data) > goto wait_to_exit; > } > put_bh(bh_check); > + last_check_time = jiffies; > } > > /* > -- > 2.31.1 > -- Jan Kara SUSE Labs, CR