Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp345437ybl; Wed, 11 Dec 2019 19:48:05 -0800 (PST) X-Google-Smtp-Source: APXvYqzlEVgKiQfT8QZvFgqFcUD4s0WTxVpyoX9eQL7ZroMfNrBXDJWUJOtZyP54cJDPcqokzwQM X-Received: by 2002:a9d:6f07:: with SMTP id n7mr5595707otq.112.1576122485890; Wed, 11 Dec 2019 19:48:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576122485; cv=none; d=google.com; s=arc-20160816; b=zTgMaDhnKitNwJRlyg7+fA/9WRRvIs9jB/wmSEgUdwcsWVhDnVlrEAtrA3JP0SOCSE ZV/6EWr/HVn9Qbrey2RQEojFq9qpx0GZc8gSf3PbmrJsLDvYt2sxfYJDM1hXIIRhcAxf SYnxap3aRh5xlsmrFGOhp6K36dlnOdPg9pDqAbiDpXGhbQYepG4pyJc+YGQgU27qmGyv 8vX7P5gRJMWXTj92q50rTDDW+tjQmYEoJaeo5iyOU4VVDLNj+RkdZzckcrr8YNFrx7CL oXr8sWfQ+IxOM60jtzvHzQ8hk9EyKGadG2xMWjicylkrt70XUhKCUonx0yqMDElemisz vOOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:references:message-id:date :thread-index:thread-topic:subject:cc:to:from; bh=vLz/sENmrnhyQD1RVzFIDfLrtKKFtwRqX6/lEIg3Vmk=; b=xfDLckzFW4RZZ9t/13p7G/7M4H878Gg9cU1LWD8FqJup1U1tmkH3pCJrAu/oUi0nd2 kzs6a3EQQHeeqEZojt/098D9jf60qLan1+W6TyVCyflRdHUI95dlwSMe5qLjgu/CaX2g PDuItvebkL7LYxZ7UKTmmrG0Re4arANitzr+MKnnPnbhbhnGWW5pyxr0a4582cklKMfm PRMALlxxXjUIM/H0k9N9cKm8KBUisS/NY46B67Swev2ljS5Iv5mMddTw5lQ7vvfCiNya OQ2AVb849fLH8TVv6zT7OBhrIbgNA+xYBAax7JNPp24pBSyh+IDoAxN08iHwbpLk1p/Y 4otw== 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 65si2388481otw.204.2019.12.11.19.47.54; Wed, 11 Dec 2019 19:48:05 -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 S1727777AbfLLDp6 convert rfc822-to-8bit (ORCPT + 99 others); Wed, 11 Dec 2019 22:45:58 -0500 Received: from smtp.h3c.com ([60.191.123.56]:56748 "EHLO h3cspam01-ex.h3c.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727181AbfLLDp4 (ORCPT ); Wed, 11 Dec 2019 22:45:56 -0500 Received: from DAG2EX09-IDC.srv.huawei-3com.com ([10.8.0.72]) by h3cspam01-ex.h3c.com with ESMTPS id xBC3hlk4029032 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 12 Dec 2019 11:43:47 +0800 (GMT-8) (envelope-from li.kai4@h3c.com) Received: from DAG2EX07-IDC.srv.huawei-3com.com (10.8.0.70) 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; Thu, 12 Dec 2019 11:43:49 +0800 Received: from DAG2EX07-IDC.srv.huawei-3com.com ([::1]) by DAG2EX07-IDC.srv.huawei-3com.com ([fe80::c439:37f7:8e24:31c4%9]) with mapi id 15.01.1713.004; Thu, 12 Dec 2019 11:43:49 +0800 From: Likai To: Joseph Qi , "mark@fasheh.com" , "jlbec@evilplan.org" , "chge@linux.alibaba.com" CC: "ocfs2-devel@oss.oracle.com" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] ocfs2: call journal flush to mark journal as empty after journal recovery when mount Thread-Topic: [PATCH] ocfs2: call journal flush to mark journal as empty after journal recovery when mount Thread-Index: AQHVsApQjv9leuKFH0CaG26YADPZnQ== Date: Thu, 12 Dec 2019 03:43:49 +0000 Message-ID: References: <20191211100338.510-1-li.kai4@h3c.com> <76d8166c-afe9-fc63-98b2-5293e3956669@linux.alibaba.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.125.108.72] x-sender-location: DAG2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-DNSRBL: X-MAIL: h3cspam01-ex.h3c.com xBC3hlk4029032 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/12/11 21:17, Joseph Qi wrote: > > On 19/12/11 18:03, Kai Li wrote: >> 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. >> > I think I've finally understood the problem. But I don't think it has > been clearly described for reviewing. I strongly suggest you describe > the problem in the way of timeline, such as in which step, do what > operation, and what is the status, etc. ok, Joseph The following steps describe this procedure in detail. 1. mount and touch some files 2. these transactions are committed to journal area but not checkpointed 3. emergency restart 4. mount again and its journals are replayed 5. journal super block's first s_start is 1, but its s_seq is not updated 6. touch a new file and its trans is committed but not checkpointed 7. emergency restart again 8. mount and journal is dirty, but trans committed in 6 will not be replayed. It will be added later. thanks. > >> 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.> > Sounds reasonable. But IMO, it is really a corner use scenario, using > cluster filesystem in single node... > > Thanks, > Joseph > >> 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); >>