Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp431426ybl; Wed, 11 Dec 2019 02:05:48 -0800 (PST) X-Google-Smtp-Source: APXvYqzrK5SaF+cuUpxzlXaBOgbmfCgBOEATT3O2DQqzJRj17oSbVayGrSpDHss/meLq2D1tb1m5 X-Received: by 2002:a9d:27c4:: with SMTP id c62mr1741877otb.292.1576058748554; Wed, 11 Dec 2019 02:05:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576058748; cv=none; d=google.com; s=arc-20160816; b=TdOc0GQ7gEqFa0WPElzJk384AwuFogOSxvYe2jDKZLFBJyPdnbrqG6M5FwtMvYRyp+ Z2WA3Rp2OpA00Y/jxMlO6WgeAUGjSpGoaADRou5m4Y3cyeR4mxvqPsm6gYnWkFdUKeq9 VGJuNFa5+XNEqWutkoilk9Zu+8M2YvKSjPATa+PLUYRxoP+2p4qjh02qQSbZu+qUPnU7 H2SJ5M7MJ1cEF09P4+6OpMexH7XVOsnzqUtTpSyb5DGbjHlELaw7U7vbXHYumkyzUn6Q EeaZnh5fGxXmpkJfOhswYH+mbuTusfF8VzICkKSU4sWGuvD8hEQ4t0y7rCN3vHF4HOKJ MiWA== 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:mime-version :message-id:date:subject:cc:to:from; bh=fVWszYucLou8/AZDDVtUsrQECSdLrmMcz4KIXPl5UFo=; b=BZpGidx1T1taUOf6AUY9g7E4vZrgKsm0xOGYBVgLN5ICfwCPpN5uAO3TpdKdxKstmf UU9fkobivgOt7tvRwBHfTxVMhii6eeZWWHsOoR+VDxZuXZqd07hWrYsnllkNzp3ak2an NH7tlzUYTvBIvZX1DmQ+oqh9tjIiXYAQ9sIKVrOFlMvbsMauE+Lrkf1pzteqU4fjlxvX 0fmxdkaTnsCwiMULZ0It+fc3dMSJ2gzrwjBU7EaBfJTCIXGrpzmdPYwnh70Z7mK3fF8q 3srXkUUSDr1Hip+L14xPG9sRZWNJHTzbhOzPIMueCUpTyVfQgkDA8KNnnIHV9xi+R7cr yJMA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 185si834815oie.52.2019.12.11.02.05.36; Wed, 11 Dec 2019 02:05:48 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728519AbfLKKE5 (ORCPT + 99 others); Wed, 11 Dec 2019 05:04:57 -0500 Received: from smtp.h3c.com ([60.191.123.56]:50804 "EHLO h3cspam01-ex.h3c.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727829AbfLKKE5 (ORCPT ); Wed, 11 Dec 2019 05:04:57 -0500 Received: from DAG2EX09-IDC.srv.huawei-3com.com ([10.8.0.72]) by h3cspam01-ex.h3c.com with ESMTPS id xBBA3w0v017487 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Dec 2019 18:03:58 +0800 (GMT-8) (envelope-from li.kai4@h3c.com) Received: from DAG2EX09-IDC.srv.huawei-3com.com (10.8.0.72) by DAG2EX09-IDC.srv.huawei-3com.com (10.8.0.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 11 Dec 2019 18:04:01 +0800 Received: from BJHUB01-EX.srv.huawei-3com.com (10.63.20.169) by DAG2EX09-IDC.srv.huawei-3com.com (10.8.0.72) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Wed, 11 Dec 2019 18:04:01 +0800 Received: from RDVDI-L14391V.h3c.huawei-3com.com (10.125.108.72) by rndsmtp.h3c.com (10.63.20.174) with Microsoft SMTP Server id 14.3.408.0; Wed, 11 Dec 2019 18:03:48 +0800 From: Kai Li To: , , , CC: , , Kai Li Subject: [PATCH] ocfs2: call journal flush to mark journal as empty after journal recovery when mount Date: Wed, 11 Dec 2019 18:03:38 +0800 Message-ID: <20191211100338.510-1-li.kai4@h3c.com> X-Mailer: git-send-email 2.24.0.windows.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.125.108.72] X-DNSRBL: X-MAIL: h3cspam01-ex.h3c.com xBBA3w0v017487 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If journal is dirty when mount, it will be replayed but jbd2 sb log tail cannot be updated to mark a new start because journal->j_flag has already been set with JBD2_ABORT first in journal_init_common. When a new transaction is committed, it will be recored in block 1 first(journal->j_tail is set to 1 in journal_reset). If emergency restart happens again before journal super block is updated unfortunately, the new recorded trans will not be replayed in the next mount. This exception happens when this lun is used by only one node. If it is used by multi-nodes, other node will replay its journal and its journal sb block will be updated after recovery. To fix this problem, use jbd2_journal_flush to mark journal as empty as ocfs2_replay_journal has done. The following jbd2 journal can be generated by touching a new file after journal is replayed, and seq 15 is the first valid commit, but first seq is 13 in journal super block. logdump: Block 0: Journal Superblock Seq: 0 Type: 4 (JBD2_SUPERBLOCK_V2) Blocksize: 4096 Total Blocks: 32768 First Block: 1 First Commit ID: 13 Start Log Blknum: 1 Error: 0 Feature Compat: 0 Feature Incompat: 2 block64 Feature RO compat: 0 Journal UUID: 4ED3822C54294467A4F8E87D2BA4BC36 FS Share Cnt: 1 Dynamic Superblk Blknum: 0 Per Txn Block Limit Journal: 0 Data: 0 Block 1: Journal Commit Block Seq: 14 Type: 2 (JBD2_COMMIT_BLOCK) Block 2: Journal Descriptor Seq: 15 Type: 1 (JBD2_DESCRIPTOR_BLOCK) No. Blocknum Flags 0. 587 none UUID: 00000000000000000000000000000000 1. 8257792 JBD2_FLAG_SAME_UUID 2. 619 JBD2_FLAG_SAME_UUID 3. 24772864 JBD2_FLAG_SAME_UUID 4. 8257802 JBD2_FLAG_SAME_UUID 5. 513 JBD2_FLAG_SAME_UUID JBD2_FLAG_LAST_TAG ... Block 7: Inode Inode: 8257802 Mode: 0640 Generation: 57157641 (0x3682809) FS Generation: 2839773110 (0xa9437fb6) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x1) InlineData User: 0 (root) Group: 0 (root) Size: 7 Links: 1 Clusters: 0 ctime: 0x5de5d870 0x11104c61 -- Tue Dec 3 11:37:20.286280801 2019 atime: 0x5de5d870 0x113181a1 -- Tue Dec 3 11:37:20.288457121 2019 mtime: 0x5de5d870 0x11104c61 -- Tue Dec 3 11:37:20.286280801 2019 dtime: 0x0 -- Thu Jan 1 08:00:00 1970 ... Block 9: Journal Commit Block Seq: 15 Type: 2 (JBD2_COMMIT_BLOCK) The following is jouranl recovery log when recovering the upper jbd2 journal when mount again. syslog: [ 2265.648622] ocfs2: File system on device (252,1) was not unmounted cleanly, recovering it. [ 2265.649695] fs/jbd2/recovery.c:(do_one_pass, 449): Starting recovery pass 0 [ 2265.650407] fs/jbd2/recovery.c:(do_one_pass, 449): Starting recovery pass 1 [ 2265.650409] fs/jbd2/recovery.c:(do_one_pass, 449): Starting recovery pass 2 [ 2265.650410] fs/jbd2/recovery.c:(jbd2_journal_recover, 278): JBD2: recovery, exit status 0, recovered transactions 13 to 13 Due to first commit seq 13 recorded in journal super is not consistent with the value recorded in block 1(seq is 14), journal recovery will be terminated before seq 15 even though it is an unbroken commit, inode 8257802 is a new file and it will be lost. Signed-off-by: Kai Li --- fs/ocfs2/journal.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/ocfs2/journal.c b/fs/ocfs2/journal.c index 1afe57f425a0..b8b9d26fa731 100644 --- a/fs/ocfs2/journal.c +++ b/fs/ocfs2/journal.c @@ -1066,6 +1066,14 @@ int ocfs2_journal_load(struct ocfs2_journal *journal, int local, int replayed) ocfs2_clear_journal_error(osb->sb, journal->j_journal, osb->slot_num); + if (replayed) { + /* wipe the journal */ + jbd2_journal_lock_updates(journal->j_journal); + status = jbd2_journal_flush(journal->j_journal); + jbd2_journal_unlock_updates(journal->j_journal); + mlog(ML_NOTICE, "journal recovery complete, status=%d", status); + } + status = ocfs2_journal_toggle_dirty(osb, 1, replayed); if (status < 0) { mlog_errno(status); -- 2.24.0.windows.2