[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=witahEb8eXvRHGUGDQPj5u0uTBW+W=AwznWRf3=9GhzxQ@mail.gmail.com>
Date: Fri, 26 Jan 2024 13:31:01 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Linux Trace Devel <linux-trace-devel@...r.kernel.org>, Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Christian Brauner <brauner@...nel.org>,
Ajay Kaher <ajay.kaher@...adcom.com>, Geert Uytterhoeven <geert@...ux-m68k.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] eventfs: Have inodes have unique inode numbers
On Fri, 26 Jan 2024 at 13:26, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> So we keep the same inode number until something breaks with it, even
> though, using unique ones is not that complicated?
Using unique ones for directories was a trivial cleanup.
The file case is clearly different. I thought it would be the same
trivial one-liner, but nope.
When you have to add 30 lines of code just to get unique inode numbers
that nobody has shown any interest in, it's 30 lines too much.
And when it happens in a filesystem that has a history of copying code
from the VFS layer and having nasty bugs, it's *definitely* too much.
Simplify. If you can clean things up and we have a few release of
not-horrendous-bugs every other day, I may change my mind.
As it is, I feel like I have to waste my time checking all your
patches, and I'm saying "it's not worth it".
Linus
Powered by blists - more mailing lists