From: yebin <yebin10@huawei.com>
To: Jan Kara <jack@suse.cz>
Cc: <tytso@mit.edu>, <adilger.kernel@dilger.ca>,
<linux-ext4@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -next v2 2/6] ext4: introduce last_check_time record previous check time
Date: Fri, 8 Oct 2021 10:38:31 +0800 [thread overview]
Message-ID: <615FAF27.8070000@huawei.com> (raw)
In-Reply-To: <615FA55B.5070404@huawei.com>
On 2021/10/8 9:56, yebin wrote:
>
>
> On 2021/10/7 20:31, Jan Kara wrote:
>> 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 <yebin10@huawei.com>
>> 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
> I'm sorry, I didn't understand the detection mechanism here before.
> Now I understand
> the detection mechanism here.
> As you said, it's just an abnormal protection. There's really no problem.
>
Yeah, i did test as following steps
hostA hostB
mount
ext4_multi_mount_protect -> seq == EXT4_MMP_SEQ_CLEAN
delay 5s after label "skip" so hostB will see seq is
EXT4_MMP_SEQ_CLEAN
mount
ext4_multi_mount_protect -> seq ==
EXT4_MMP_SEQ_CLEAN
run kmmpd
run kmmpd
Actually,in this situation kmmpd will not detect confliction.
In ext4_multi_mount_protect function we write mmp data fisrt and wait
'wait_time * HZ' seconds,
read mmp data do check.Most of the time, If 'wait_time' is zero, it can
pass check.
>>> ---
>>> 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
>>>
>
next prev parent reply other threads:[~2021-10-08 2:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-11 9:00 [PATCH -next v2 0/6] Fix some issues about mmp Ye Bin
2021-09-11 9:00 ` [PATCH -next v2 1/6] ext4: init seq with random value in kmmpd Ye Bin
2021-10-07 12:26 ` Jan Kara
2021-10-08 1:50 ` yebin
2021-09-11 9:00 ` [PATCH -next v2 2/6] ext4: introduce last_check_time record previous check time Ye Bin
2021-10-07 12:31 ` Jan Kara
2021-10-08 1:56 ` yebin
2021-10-08 2:38 ` yebin [this message]
2021-10-12 8:47 ` Jan Kara
2021-10-12 11:46 ` yebin
2021-10-13 9:38 ` Jan Kara
2021-10-13 12:33 ` yebin
2021-10-13 21:41 ` Theodore Ts'o
2021-10-15 3:21 ` Andreas Dilger
2021-10-15 3:21 ` Andreas Dilger
2021-09-11 9:00 ` [PATCH -next v2 3/6] ext4: compare to local seq and nodename when check conflict Ye Bin
2021-10-07 12:36 ` Jan Kara
2021-09-11 9:00 ` [PATCH -next v2 4/6] ext4: avoid to re-read mmp check data get from page cache Ye Bin
2021-10-07 12:44 ` Jan Kara
2021-10-08 3:52 ` yebin
2021-09-11 9:00 ` [PATCH -next v2 5/6] ext4: avoid to double free s_mmp_bh Ye Bin
2021-09-11 9:00 ` [PATCH -next v2 6/6] ext4: fix possible store wrong check interval value in disk when umount Ye Bin
2021-10-07 13:12 ` Jan Kara
2021-10-08 3:49 ` yebin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=615FAF27.8070000@huawei.com \
--to=yebin10@huawei.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.