[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200624131908.GE13061@mtj.duckdns.org>
Date: Wed, 24 Jun 2020 09:19:08 -0400
From: Tejun Heo <tj@...nel.org>
To: Rick Lindsley <ricklind@...ux.vnet.ibm.com>
Cc: Ian Kent <raven@...maw.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Andrew Morton <akpm@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
David Howells <dhowells@...hat.com>,
Miklos Szeredi <miklos@...redi.hu>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency
improvement
Hello, Rick.
On Wed, Jun 24, 2020 at 02:04:15AM -0700, Rick Lindsley wrote:
> In contrast, the provided patch fixes the observed problem with no ripple
> effect to other subsystems or utilities.
>
> Greg had suggested
> Treat the system as a whole please, don't go for a short-term
> fix that we all know is not solving the real problem here.
>
> Your solution affects multiple subsystems; this one affects one. Which is
> the whole system approach in terms of risk? You mentioned you support 30k
> scsi disks but only because they are slow so the inefficiencies of kernfs
> don't show. That doesn't bother you?
I suggest putting honest thoughts into finding a long term solution instead
of these rhetorical retorts. If you really can't see how ill-suited the
current use of interface and proposed solution is, I'm not sure how better
to communicate them to you.
Thanks.
--
tejun
Powered by blists - more mailing lists