Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp2063763pxv; Fri, 2 Jul 2021 21:18:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZjMvveTZ0/eJmiisxKLRVzFQpzzu+V/BaICcR9jaYxBEY4LQpcaJ23PM6h1s8M8FXh9Q3 X-Received: by 2002:a17:907:2da6:: with SMTP id gt38mr3043297ejc.528.1625285902920; Fri, 02 Jul 2021 21:18:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625285902; cv=none; d=google.com; s=arc-20160816; b=El00NJvpSRK4ovdEWXX16u6KkVozbalTaWbga9KE0wpmLTKKE/ZdbNgIDvQRuhiPeF D4Mhen7zy8yP1Xpkvh+NMaqmLPLUCcBK54Dgl1eQJkOhAuGXeM8yr1uhjXVTg/smjjni iUDfG9rsbJHF4BGlF1rQywaKMX/wkb9ICyejGaJ0XO7zfvqrHCnrsdckkGzEwVl+1XG9 qqrWwf0g3rm3FtgorBS1T63rtygRzxHMBsYFjSk8HMWYZfW4/JssMCNQOW1rGuDcV5pk SThJlHHt2wu9YaBPn7Y7l1rKy9G/CkCsUvEnw1FsFAZy0lbds5cMpB4ZChqvyTOsrU94 oPRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=a2SKs8TDJGC/jAvko6pI1i63yHiMJqD2ZflSUVJBFvE=; b=cZ+V9TgX3GY2SssobwJNSPw+VoVJy2hI8aXtWWeJDAZhTcFsKFqErkGzypI6gsSfxm 9TfGnYrDQGosQ3+RTxB1ufulQBJmXToE7MUq3kez9+kZ2pbQIb031H5/sYw6DqgV9tDK CVfX/e3tqiIjOrP4slJSVIKUbtjoOjsBiPVkuOtdjVlISCB4LDbKtaynS0NVj6bhwZb+ AwTXk9Z8pOfzMmp5StPqgwqpihhbfotBnFizV9BBuBdCWlQIM249sV1WBDSH/5z98y9t or/bQ8lWvrolM6LTyJOM6QXB70F+lVeTeZNd8UbgbE3SStPrYX9bCNjSRuY/jbBcna9y fXGg== 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 ml13si5309758ejb.227.2021.07.02.21.17.43; Fri, 02 Jul 2021 21:18:22 -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 S230174AbhGCDzA (ORCPT + 99 others); Fri, 2 Jul 2021 23:55:00 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:42845 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S230176AbhGCDzA (ORCPT ); Fri, 2 Jul 2021 23:55:00 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1633q4h8012116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 2 Jul 2021 23:52:06 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id CA34B15C3CE6; Fri, 2 Jul 2021 23:52:04 -0400 (EDT) Date: Fri, 2 Jul 2021 23:52:04 -0400 From: "Theodore Ts'o" To: Zhang Yi Cc: Jan Kara , linuxppc-dev@lists.ozlabs.org, Guoqing Jiang , Sachin Sant , Ext4 Developers List , "linux-fsdevel@vger.kernel.org" Subject: Re: [powerpc][5.13.0-next-20210701] Kernel crash while running ltp(chdir01) tests Message-ID: References: <26ACA75D-E13D-405B-9BFC-691B5FB64243@linux.vnet.ibm.com> <4cc87ab3-aaa6-ed87-b690-5e5b99de8380@huawei.com> <03f734bd-f36e-f55b-0448-485b8a0d5b75@huawei.com> <9b81eb4e-9adb-991f-31be-f5ef0092c4b3@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b81eb4e-9adb-991f-31be-f5ef0092c4b3@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Sat, Jul 03, 2021 at 11:37:07AM +0800, Zhang Yi wrote: > I check the ocfs2 code, if we register shrinker here, __ocfs2_recovery_thread()-> > ocfs2_recover_node() seems will register and unregister a lot of unnecessary > shrinkers. It depends on the lifetime of the shrinker and the journal, because of > the jbd2_journal_destroy() destroy everything, it not a simple undo of > jbd2_load_journal(), so it's not easy to add shrinker properly. But it doesn't > seems like a real problem, just curious. ocfs2_recover_node() only gets called for nodes that need recovery --- that is, when an ocfs2 server has crashed, then it becomes necessary to replay that node's journal before that node's responsibilities can be taken over by another server. So it doesn't get called that frequently --- and when it is needed, the fact that we need to read the journal, and replay its entries, the cost in comparison for registering and unregistering the shrinker is going to be quite cheap. Cheers, - Ted