Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Wed, 15 Nov 2023 16:30:51 +0100
From:   Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To:     junxiao.bi@oracle.com, Song Liu <song@kernel.org>
Cc:     Tejun Heo <tj@kernel.org>, linux-kernel@vger.kernel.org,
        linux-raid@vger.kernel.org, gregkh@linuxfoundation.org
Subject: Re: [PATCH] kernfs: support kernfs notify in memory recliam context
Message-ID: <20231115162915.000064f8@linux.intel.com>
In-Reply-To: <443775e1-ed94-452e-8f06-eadb777bede4@oracle.com>
References: <20231114185947.42829-1-junxiao.bi@oracle.com>
 <ZVPFMzHAx9JVz2ak@slm.duckdns.org>
 <c71f1cb7-14d6-45e4-9df1-dc9bc82deda8@oracle.com>
 <ZVPXd-3TshjeScek@slm.duckdns.org>
 <443775e1-ed94-452e-8f06-eadb777bede4@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, 14 Nov 2023 15:53:47 -0800
junxiao.bi@oracle.com wrote:

> Understood, thanks. Sound like depending on Userspace on memory reclaim=20
> path is really bad idea and the only option for fixing it is to remove=20
> that dependency, but i am not sure that is possible without breaking the=
=20
> consistency of metadata.
>=20
> Thanks,
>=20
> Junxiao.

Indeed the project of external metadata management if fragile. You cares ab=
out
IMSM here (same as me) so ideally we should implement metadata management in
kernel- I think that IMSM deserved that after 10 years on the market. There=
 is
no better option, other options are just "workarounds" for the lack of meta=
data
management in kernel.

Song, any comments here?

=46rom the second hand, there is native raid which should just work, so maybe=
 you
can switch to the native raid?

Thanks,
Mariusz