[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgcVh71g2G-cQQBV_65jM2WJ916oW6Bv0+=xppNtE6Fzw@mail.gmail.com>
Date: Wed, 3 Jan 2024 11:04:44 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Linux Trace Kernel <linux-trace-kernel@...r.kernel.org>, Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [PATCH] eventfs: Stop using dcache_readdir() for getdents()
On Wed, 3 Jan 2024 at 10:50, Steven Rostedt <rostedt@...dmis.org> wrote:
> I think these changes are a bit much for -rc8, don't you?
Oh, absolutely.
None of this is rc8 material apart from the oops fix in your pull
request (which my patch that then removes the whole function did *not*
have - so that patch won't apply as-is to your tree).
But let's aim for a tracefs that doesn't play games with the dcache.
Basically, the dcache is *much* too subtle for a filesystem to mess
with. You should either:
- be a fully virtual filesystem where the dcache just maintains
everything, and you don't mess with it because you don't need to (eg
tmpfs etc). Everything is in the dcache, and you don't need to touch
it, because you don't even care - the dcache is doing everything for
you.
- be a "normal" filesystem where the dcache is just a cache, and you
maintain your *own* file data structures, and just get normal lookup
etc ops, and you don't mess with the dcache because it is just doing
its caching thing that you as a filesystem don't care about.
and in both of those cases the filesystem just never has to really
delve into it. But tracefs had this abomination where it maintained
its own data structures, _and_ it tried to make them coherent with the
dcache that maintained part of it. That's the part I hated.
Linus
Powered by blists - more mailing lists